* Re: linux-next: m68k build failure
From: David Miller @ 2008-12-09 8:00 UTC (permalink / raw)
To: sfr; +Cc: linux-next, geert, shemminger
In-Reply-To: <20081209174534.17ad7991.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 9 Dec 2008 17:45:34 +1100
> Hi Dave,
>
> The linux-next build (m68k defconfig) failed like this:
>
> drivers/net/hydra.c: In function 'hydra_init':
> /drivers/net/hydra.c:163: error: 'hydra_netdev_ops' undeclared (first use in this function)
>
> Caused by commit 5618f0d1193d6b051da9b59b0e32ad24397f06a4 ("hydra:
> convert to net_device_ops") which contains a typo in the net_device_ops
> structure naming (presumably cut and paste).
Sorry about that. I just pushed a fix for this to net-next-2.6
from Alexey D.
^ permalink raw reply
* Re: linux-next: manual merge of the staging tree
From: David Miller @ 2008-12-09 7:59 UTC (permalink / raw)
To: greg; +Cc: sfr, linux-next, wangchen
In-Reply-To: <20081209035318.GB22596@kroah.com>
From: Greg KH <greg@kroah.com>
Date: Mon, 8 Dec 2008 19:53:18 -0800
> On Mon, Dec 08, 2008 at 12:35:57PM -0800, David Miller wrote:
> > Because I have to do allmodconfig test builds _too_, and the build
> > will fail for me if I do these reverts which really would suck.
>
> Ok, that's fine, as long as stephen can keep this patch in his tree,
> I'll apply it to mine when you merge with Linus, as the staging tree
> will probably be one of the last things before the next -rc1 window
> closes.
BTW, there is something else we can do.
I can pull staging net driver changes into net-next-2.6
We can either do it as a one-time thing to alleviate this
merge hassle, or we can try and make it a more ongoing
merge mechanism.
^ permalink raw reply
* linux-next: Tree for December 9
From: Stephen Rothwell @ 2008-12-09 7:52 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 8154 bytes --]
Hi all,
Changes since 20081208:
Today's tree fails the powerpc allyesconfig build but succeeds with
CONFIG_PROFILE_ALL_BRANCHES turned off.
New trees:
audit-current
audit
Undropped tree:
ide
Dropped trees (temporarily):
v4l-dvb (build problem)
mmc (build problem)
drm (build problem)
semaphore-removal (due to unfixed conflicts against Linus' tree)
cpu_alloc (build problem)
perfmon3 (concerns from the x86 team)
audit (difficult conflicts)
staging (build failure)
The net tree gained 2 conflicts against the nfsd tree.
The drm tree gained a build problem and was dropped.
The security-testing tree gained a conflict against the audit-current
tree.
The lblnet tree lost 2 conflicts.
The ttydev tree lost 3 conflicts.
The audit tree gained several conflicts against the security-testing tree
and was dropped.
----------------------------------------------------------------------------
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-2.6.26
Merging audit-current/for-linus
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
CONFLICT (content): Merge conflict in drivers/char/Makefile
Merging sh/master
Merging sparc/master
Merging x86/auto-x86-next
Merging xtensa/master
Merging quilt/driver-core
CONFLICT (content): Merge conflict in arch/powerpc/platforms/85xx/mpc85xx_mds.c
Merging quilt/usb
Merging tip-core/auto-core-next
Merging cpus4096/auto-cpus4096-next
Merging ftrace/auto-ftrace-next
CONFLICT (content): Merge conflict in scripts/recordmcount.pl
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
Merging hid/for-next
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
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
Merging dlm/next
Merging scsi/master
Merging ocfs2/linux-next
Merging ext4/next
Merging async_tx/next
Merging udf/for_next
Merging net/master
CONFLICT (delete/modify): arch/sparc64/kernel/idprom.c deleted in HEAD and modified in net/master. Version net/master of arch/sparc64/kernel/idprom.c left in tree.
CONFLICT (content): Merge conflict in fs/lockd/host.c
CONFLICT (content): Merge conflict in fs/lockd/mon.c
$ git rm -f arch/sparc64/kernel/idprom.c
Applying net: async_tx merge fix
Merging mtd/master
CONFLICT (content): Merge conflict in drivers/mtd/maps/physmap.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
Merging quilt/rr
CONFLICT (content): Merge conflict in arch/x86/kernel/setup.c
CONFLICT (content): Merge conflict in kernel/cpu.c
Merging cifs/master
CONFLICT (content): Merge conflict in fs/cifs/connect.c
Applying cifs: update for new IP4/6 address printing
Merging mmc/next
$ git reset --hard HEAD^
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
CONFLICT (content): Merge conflict in arch/x86/mm/Makefile
CONFLICT (content): Merge conflict in mm/slab.c
CONFLICT (content): Merge conflict in mm/slub.c
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
CONFLICT (content): Merge conflict in drivers/char/tty_audit.c
CONFLICT (content): Merge conflict in fs/cifs/cifs_fs_sb.h
CONFLICT (content): Merge conflict in fs/ocfs2/namei.c
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_cred.h
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_globals.h
CONFLICT (content): Merge conflict in fs/xfs/linux-2.6/xfs_ioctl.c
CONFLICT (content): Merge conflict in fs/xfs/xfs_vnodeops.h
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
Merging watchdog/master
CONFLICT (content): Merge conflict in drivers/watchdog/iTCO_wdt.c
Merging proc/proc
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
CONFLICT (content): Merge conflict in kernel/sched.c
Merging osd/linux-next
Merging fatfs/master
Merging fuse/for-next
Merging jc_docs/docs-next
Merging trivial/for-next
Merging scsi-post-merge/master
Created commit 3b3d658: Revert "Merge commit 'drm/drm-next'"
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: build failure
From: Stephen Rothwell @ 2008-12-09 7:34 UTC (permalink / raw)
To: Dave Airlie; +Cc: linux-next, Jesse Barnes, Eric Anholt
[-- Attachment #1: Type: text/plain, Size: 683 bytes --]
Hi Dave,
Today's linux-next build (powerpc allyesconfig) failed like this:
drivers/gpu/drm/drm_gem.c: In function 'drm_gem_mmap':
drivers/gpu/drm/drm_gem.c:519: error: '_PAGE_CACHE_WC' undeclared (first use in this function)
Caused by commit 33b801854540a4f5205c0b2b4b91987e7f21af08 ("drm: GEM mmap
support"). I tried to revert just that commit, but it lead me down a
road of dependent commits, so I have reverted the whole drm tree for
today.
_PAGE_CACHE_WC appears to be defined only for x86 and, before the above
commit, was not used outside arch/x86.
--
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: mmc tree build failure
From: Stephen Rothwell @ 2008-12-09 7:16 UTC (permalink / raw)
To: Pierre Ossman; +Cc: linux-next, Rafael J. Wysocki, Greg KH, Philip Langdale
In-Reply-To: <20081209074751.3967406b@mjolnir.drzeus.cx>
[-- Attachment #1: Type: text/plain, Size: 358 bytes --]
Hi Pierre,
On Tue, 9 Dec 2008 07:47:51 +0100 Pierre Ossman <drzeus-list@drzeus.cx> wrote:
>
> Sorry about that. I got side-tracked and forgot to push the fixed tree.
> It should be up now.
It happens. I will include it tomorrow.
Thanks.
--
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: next-2008-11-09: s390 vs ->ioctx_list
From: Jens Axboe @ 2008-12-09 7:13 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: Stephen Rothwell, linux-next, linux-kernel, jmoyer
In-Reply-To: <20081209001113.GA6107@x200.localdomain>
On Tue, Dec 09 2008, Alexey Dobriyan wrote:
> CC arch/s390/mm/pgtable.o
> arch/s390/mm/pgtable.c: In function 's390_enable_sie':
> arch/s390/mm/pgtable.c:266: error: invalid operands to binary ||
> arch/s390/mm/pgtable.c:282: error: invalid operands to binary ||
>
> This is because ->ioctx_list turned from pointer to a hlist, some more locking
> and different check required.
Already posted a patch for this on friday, the branches have now been
updated.
--
Jens Axboe
^ permalink raw reply
* next-20081104 - kernel panic on ia64 box, at __mutex_lock_interruptible_slowpath
From: Kamalesh Babulal @ 2008-12-09 7:07 UTC (permalink / raw)
To: tony.luck; +Cc: sfr, linux-next, LKML, linux-ia64
In-Reply-To: <20081204200745.eff0ac87.sfr@canb.auug.org.au>
Hi Tony,
next-20081204 kernel panic's, while booting up on ia64 box. This panic
was not reproducible with the latest next-20081208 kernel.
VFS: Mounted root (cramfs filesystem) readonly.
Unable to handle kernel NULL pointer dereference (address 0000000000000000)
swapper[1266]: Oops 8804682956800 [1]
Modules linked in:
Pid: 1266, CPU 4, comm: swapper
psr : 00001010085a6010 ifs : 800000000000060d ip : [<a0000001007f73d0>] Not tainted (2.6.28-rc7-next-20081204-autokern1)
ip is at __mutex_lock_interruptible_slowpath+0x70/0x220
unat: 0000000000000000 pfs : 000000000000060d rsc : 0000000000000000
rnat: e303ca0717d84d54 bsps: 52f9f686bedfb255 pr : 101026600565a559
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70433f
csd : 0000000000000000 ssd : 0000000000000000
b0 : a0000001007f7390 b6 : a0000001004a2880 b7 : a0000001004d55c0
f6 : 1003e0000000000000000 f7 : 1003e0000000000000020
f8 : 1003e0000000000000800 f9 : 1003e0000000000010000
f10 : 1003e0000000000000800 f11 : 1003e0000000000000020
r1 : a000000100e88990 r2 : e000001303f97d30 r3 : e0000006443d0100
r8 : 0000000000000000 r9 : e000001304432aa0 r10 : e0000006443d0000
r11 : 0000000000000000 r12 : e000001303f97d10 r13 : e000001303f90000
r14 : 0000000000000000 r15 : 0000000000000000 r16 : ffffffffffffffff
r17 : e000001303f97d20 r18 : a000000100c5ef20 r19 : 0000000000000000
usb 2-1: new low speed USB device using uhci_hcd and address 2
r20 : a000000100c5ef50 r21 : e000001303f800c0 r22 : ffffffdfffffffff
r23 : e000001303f801de r24 : 0000000000000001 r25 : 000000000000001a
r26 : e00000130318401b r27 : 0000000000000000 r28 : 0000000010ee2419
r29 : 0000000010ee2419 r30 : 0000000000000000 r31 : e0000006443d00f4
Call Trace:
[<a0000001000155a0>] show_stack+0x80/0xa0
sp=e000001303f978e0 bsp=e000001303f91178
[<a000000100015ea0>] show_regs+0x880/0x8c0
sp=e000001303f97ab0 bsp=e000001303f91120
[<a00000010003dca0>] die+0x1a0/0x300
sp=e000001303f97ab0 bsp=e000001303f910d8
[<a0000001007fff20>] ia64_do_page_fault+0x8a0/0xba0
sp=e000001303f97ab0 bsp=e000001303f91078
[<a00000010000bfa0>] ia64_native_leave_kernel+0x0/0x270
sp=e000001303f97b40 bsp=e000001303f91078
[<a0000001007f73d0>] __mutex_lock_interruptible_slowpath+0x70/0x220
sp=e000001303f97d10 bsp=e000001303f91010
[<a0000001007f7630>] mutex_lock_interruptible+0x30/0x60
sp=e000001303f97d30 bsp=e000001303f90fe8
[<a0000001004d56b0>] uart_open+0xf0/0xa60
sp=e000001303f97d30 bsp=e000001303f90f58
[<a00000010049ace0>] tty_open+0x4a0/0xc20
sp=e000001303f97d60 bsp=e000001303f90ec0
[<a00000010018f2e0>] chrdev_open+0x1c0/0x380
sp=e000001303f97d70 bsp=e000001303f90e78
[<a000000100183b20>] __dentry_open+0x5c0/0x6a0
sp=e000001303f97d80 bsp=e000001303f90e00
[<a000000100183ca0>] nameidata_to_filp+0xa0/0xc0
sp=e000001303f97d80 bsp=e000001303f90dd0
[<a0000001001a3050>] do_filp_open+0x310/0x12e0
sp=e000001303f97d80 bsp=e000001303f90d10
usb 2-1: configuration #1 chosen from 1 choice
[<a000000100183290>] do_sys_open+0x90/0x200
sp=e000001303f97e30 bsp=e000001303f90cc0
[<a0000001001834d0>] sys_open+0x50/0x80
sp=e000001303f97e30 bsp=e000001303f90c68
input: LITE-ON Technology USB NetVista Full Width Keyboard. as /class/input/input1
[<a0000001009c82b0>] do_linuxrc+0xb0/0x120
sp=e000001303f97e30 bsp=e000001303f90c48
[<a000000100013710>] kernel_thread_helper+0xd0/0x100
sp=e000001303f97e30 bsp=e000001303f90c20
[<a00000010000a4c0>] start_kernel_thread+0x20/0x40
sp=e000001303f97e30 bsp=e000001303f90c20
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Trying to move old root to /initrd ... <6>generic-usb 0003:04B3:3025.0001: input: USB HID v1.10 Keyboard [LITE-ON Technology USB NetVista Full Width Keyboard.] on usb-0000:00:05.3-1/input0
okay
Freeing unused kernel memory: 1760kB freed
BUG: soft lockup - CPU#0 stuck for 61s! [swapper:1]
Modules linked in:
Modules linked in:
Pid: 1, CPU 0, comm: swapper
psr : 00001010085a6010 ifs : 8000000000000000 ip : [<a00000010000a500>] Tainted: G D (2.6.28-rc7-next-20081204-autokern1)
ip is at ia64_spinlock_contention+0x20/0x60
unat: 0000000000000000 pfs : 0000000000000081 rsc : 0000000000000003
rnat: 0000000000000000 bsps: 0000000000000000 pr : 1810264469655559
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70433f
csd : 0930ffff000f0000 ssd : 0930ffff00000000
b0 : a0000001007f7390 b6 : a0000001007fa020 b7 : a0000001004d55c0
f6 : 1003e0000000000400000 f7 : 1003e0000000000000000
f8 : 1003e0000000028000000 f9 : 1003e0000000c5d145160
f10 : 1003eee8b2cb700000000 f11 : 1003e0000000000000001
r1 : a000000100e88990 r2 : 000000000000060d r3 : e00000064309001c
r8 : 0000000000000000 r9 : e000001304432aa0 r10 : e0000006443d0000
r11 : 0000000000000000 r12 : e000000643097d00 r13 : e000000643090000
r14 : 0000000000000000 r15 : e000001304432a00 r16 : 0000000000000000
r17 : 0000000000000000 r18 : a000000100c5ef20 r19 : 0000000000000000
r20 : a000000100c5ef50 r21 : e000001303f800c0 r22 : e000001304432aa0
r23 : 0000000000500002 r24 : e000000600005398 r25 : fffffffffffff000
r26 : a00000010049a840 r27 : 0000000000000000 r28 : e000000644516020
r29 : 0000000000000200 r30 : 0000000000000001 r31 : e0000006443d00f4
Call Trace:
[<a0000001000155a0>] show_stack+0x80/0xa0
sp=e000000643097960 bsp=e000000643091340
[<a000000100015ea0>] show_regs+0x880/0x8c0
sp=e000000643097b30 bsp=e0000006430912e8
[<a0000001000f8770>] softlockup_tick+0x2b0/0x3a0
sp=e000000643097b30 bsp=e000000643091290
[<a0000001000af920>] run_local_timers+0x40/0x60
sp=e000000643097b30 bsp=e000000643091278
[<a0000001000af980>] update_process_times+0x40/0xc0
sp=e000000643097b30 bsp=e000000643091248
[<a00000010003d800>] timer_interrupt+0x1c0/0x4c0
sp=e000000643097b30 bsp=e0000006430911e0
[<a0000001000f8a90>] handle_IRQ_event+0x90/0x120
sp=e000000643097b30 bsp=e0000006430911a8
[<a0000001000f8c70>] __do_IRQ+0x150/0x440
sp=e000000643097b30 bsp=e000000643091148
[<a0000001000129b0>] ia64_handle_irq+0x410/0x440
sp=e000000643097b30 bsp=e0000006430910c8
[<a00000010000bfa0>] ia64_native_leave_kernel+0x0/0x270
sp=e000000643097b30 bsp=e0000006430910c8
[<a00000010000a500>] ia64_spinlock_contention+0x20/0x60
sp=e000000643097d00 bsp=e0000006430910c8
[<a0000001007fa020>] _spin_lock+0x40/0x60
sp=e000000643097d00 bsp=e0000006430910c0
[<a0000001007f7390>] __mutex_lock_interruptible_slowpath+0x30/0x220
sp=e000000643097d00 bsp=e000000643091060
[<a0000001007f7630>] mutex_lock_interruptible+0x30/0x60
sp=e000000643097d20 bsp=e000000643091040
[<a0000001004d56b0>] uart_open+0xf0/0xa60
sp=e000000643097d20 bsp=e000000643090fa8
[<a00000010049ace0>] tty_open+0x4a0/0xc20
sp=e000000643097d50 bsp=e000000643090f10
[<a00000010018f2e0>] chrdev_open+0x1c0/0x380
sp=e000000643097d60 bsp=e000000643090ec8
[<a000000100183b20>] __dentry_open+0x5c0/0x6a0
sp=e000000643097d70 bsp=e000000643090e50
[<a000000100183ca0>] nameidata_to_filp+0xa0/0xc0
sp=e000000643097d70 bsp=e000000643090e28
[<a0000001001a3050>] do_filp_open+0x310/0x12e0
sp=e000000643097d70 bsp=e000000643090d60
[<a000000100183290>] do_sys_open+0x90/0x200
sp=e000000643097e20 bsp=e000000643090d10
[<a0000001001834d0>] sys_open+0x50/0x80
sp=e000000643097e20 bsp=e000000643090cb8
[<a00000010000a980>] init_post+0x80/0x220
sp=e000000643097e20 bsp=e000000643090c98
[<a0000001009c0640>] kernel_init+0x420/0x440
sp=e000000643097e20 bsp=e000000643090c48
[<a000000100013710>] kernel_thread_helper+0xd0/0x100
sp=e000000643097e30 bsp=e000000643090c20
[<a00000010000a4c0>] start_kernel_thread+0x20/0x40
sp=e000000643097e30 bsp=e000000643090c20
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* linux-next: manual merge of the audit tree
From: Stephen Rothwell @ 2008-12-09 6:57 UTC (permalink / raw)
To: Al Viro; +Cc: linux-next, David Howells, James Morris, Eric Paris, Serge Hallyn
Hi Al,
Today's linux-next merge of the audit tree got a lot of conflict in
include/linux/audit.h, kernel/auditsc.c, kernel/capability.c and
security/commoncap.c against commits in the security-testing tree.
Its not obvious how to resolve these, so can you, Eric, James and Dave
have a conversation and see what you can come up with. Some will be
easy, but there are several overlapping changes here.
Looking harder, it looks like some (all?) of Eric's patches may already
be in the security-testing tree ...
I have dropped the audit tree for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc include/linux/audit.h
index 26c4f6f,1471971..0000000
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@@ -455,10 -455,8 +455,15 @@@ extern int __audit_mq_timedsend(mqd_t m
extern int __audit_mq_timedreceive(mqd_t mqdes, size_t msg_len, unsigned int __user *u_msg_prio, const struct timespec __user *u_abs_timeout);
extern int __audit_mq_notify(mqd_t mqdes, const struct sigevent __user *u_notification);
extern int __audit_mq_getsetattr(mqd_t mqdes, struct mq_attr *mqstat);
++<<<<<<< HEAD:include/linux/audit.h
+extern int __audit_log_bprm_fcaps(struct linux_binprm *bprm,
+ const struct cred *new,
+ const struct cred *old);
+extern int __audit_log_capset(pid_t pid, const struct cred *new, const struct cred *old);
++=======
+ extern void __audit_log_bprm_fcaps(struct linux_binprm *bprm, kernel_cap_t *pP, kernel_cap_t *pE);
+ extern int __audit_log_capset(pid_t pid, kernel_cap_t *eff, kernel_cap_t *inh, kernel_cap_t *perm);
++>>>>>>> audit/for-next:include/linux/audit.h
static inline int audit_ipc_obj(struct kern_ipc_perm *ipcp)
{
@@@ -509,20 -507,32 +514,49 @@@ static inline int audit_mq_getsetattr(m
return 0;
}
++<<<<<<< HEAD:include/linux/audit.h
+static inline int audit_log_bprm_fcaps(struct linux_binprm *bprm,
+ const struct cred *new,
+ const struct cred *old)
+{
+ if (unlikely(!audit_dummy_context()))
+ return __audit_log_bprm_fcaps(bprm, new, old);
+ return 0;
+}
+
+static inline int audit_log_capset(pid_t pid, const struct cred *new,
+ const struct cred *old)
+{
+ if (unlikely(!audit_dummy_context()))
+ return __audit_log_capset(pid, new, old);
++=======
+ /*
+ * ieieeeeee, an audit function without a return code!
+ *
+ * This function might fail! I decided that it didn't matter. We are too late
+ * to fail the syscall and the information isn't REQUIRED for any purpose. It's
+ * just nice to have. We should be able to look at past audit logs to figure
+ * out this process's current cap set along with the fcaps from the PATH record
+ * and use that to come up with the final set. Yeah, its ugly, but all the info
+ * is still in the audit log. So I'm not going to bother mentioning we failed
+ * if we couldn't allocate memory.
+ *
+ * If someone changes their mind they could create the aux record earlier and
+ * then search here and use that earlier allocation. But I don't wanna.
+ *
+ * -Eric
+ */
+ static inline void audit_log_bprm_fcaps(struct linux_binprm *bprm, kernel_cap_t *pP, kernel_cap_t *pE)
+ {
+ if (unlikely(!audit_dummy_context()))
+ __audit_log_bprm_fcaps(bprm, pP, pE);
+ }
+
+ static inline int audit_log_capset(pid_t pid, kernel_cap_t *eff, kernel_cap_t *inh, kernel_cap_t *perm)
+ {
+ if (unlikely(!audit_dummy_context()))
+ return __audit_log_capset(pid, eff, inh, perm);
++>>>>>>> audit/for-next:include/linux/audit.h
return 0;
}
@@@ -558,8 -568,8 +592,13 @@@ extern int audit_signals
#define audit_mq_timedreceive(d,l,p,t) ({ 0; })
#define audit_mq_notify(d,n) ({ 0; })
#define audit_mq_getsetattr(d,s) ({ 0; })
++<<<<<<< HEAD:include/linux/audit.h
+#define audit_log_bprm_fcaps(b, ncr, ocr) ({ 0; })
+#define audit_log_capset(pid, ncr, ocr) ({ 0; })
++=======
+ #define audit_log_bprm_fcaps(b, p, e) do { ; } while (0)
+ #define audit_log_capset(pid, e, i, p) ({ 0; })
++>>>>>>> audit/for-next:include/linux/audit.h
#define audit_ptrace(t) ((void)0)
#define audit_n_rules 0
#define audit_signals 0
diff --cc kernel/auditsc.c
index 4819f37,87fd50b..0000000
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@@ -89,8 -89,8 +89,13 @@@ struct audit_cap_data
kernel_cap_t permitted;
kernel_cap_t inheritable;
union {
++<<<<<<< HEAD:kernel/auditsc.c
+ unsigned int fE; /* effective bit of a file capability */
+ kernel_cap_t effective; /* effective set of a process */
++=======
+ unsigned int fE;
+ kernel_cap_t effective;
++>>>>>>> audit/for-next:kernel/auditsc.c
};
};
@@@ -2564,17 -2557,18 +2569,31 @@@ int __audit_signal_info(int sig, struc
/**
* __audit_log_bprm_fcaps - store information about a loading bprm and relevant fcaps
++<<<<<<< HEAD:kernel/auditsc.c
+ * @bprm: pointer to the bprm being processed
+ * @new: the proposed new credentials
+ * @old: the old credentials
++=======
+ * @bprm pointer to the bprm being processed
+ * @caps the caps read from the disk
++>>>>>>> audit/for-next:kernel/auditsc.c
*
* Simply check if the proc already has the caps given by the file and if not
* store the priv escalation info for later auditing at the end of the syscall
*
++<<<<<<< HEAD:kernel/auditsc.c
+ * -Eric
+ */
+int __audit_log_bprm_fcaps(struct linux_binprm *bprm,
+ const struct cred *new, const struct cred *old)
++=======
+ * this can fail and we don't care. See the note in audit.h for
+ * audit_log_bprm_fcaps() for my explaination....
+ *
+ * -Eric
+ */
+ void __audit_log_bprm_fcaps(struct linux_binprm *bprm, kernel_cap_t *pP, kernel_cap_t *pE)
++>>>>>>> audit/for-next:kernel/auditsc.c
{
struct audit_aux_data_bprm_fcaps *ax;
struct audit_context *context = current->audit_context;
@@@ -2583,7 -2577,7 +2602,11 @@@
ax = kmalloc(sizeof(*ax), GFP_KERNEL);
if (!ax)
++<<<<<<< HEAD:kernel/auditsc.c
+ return -ENOMEM;
++=======
+ return;
++>>>>>>> audit/for-next:kernel/auditsc.c
ax->d.type = AUDIT_BPRM_FCAPS;
ax->d.next = context->aux;
@@@ -2598,27 -2592,26 +2621,48 @@@
ax->fcap.fE = !!(vcaps.magic_etc & VFS_CAP_FLAGS_EFFECTIVE);
ax->fcap_ver = (vcaps.magic_etc & VFS_CAP_REVISION_MASK) >> VFS_CAP_REVISION_SHIFT;
++<<<<<<< HEAD:kernel/auditsc.c
+ ax->old_pcap.permitted = old->cap_permitted;
+ ax->old_pcap.inheritable = old->cap_inheritable;
+ ax->old_pcap.effective = old->cap_effective;
+
+ ax->new_pcap.permitted = new->cap_permitted;
+ ax->new_pcap.inheritable = new->cap_inheritable;
+ ax->new_pcap.effective = new->cap_effective;
+ return 0;
++=======
+ ax->old_pcap.permitted = *pP;
+ ax->old_pcap.inheritable = current->cap_inheritable;
+ ax->old_pcap.effective = *pE;
+
+ ax->new_pcap.permitted = current->cap_permitted;
+ ax->new_pcap.inheritable = current->cap_inheritable;
+ ax->new_pcap.effective = current->cap_effective;
++>>>>>>> audit/for-next:kernel/auditsc.c
}
/**
* __audit_log_capset - store information about the arguments to the capset syscall
++<<<<<<< HEAD:kernel/auditsc.c
+ * @pid: target pid of the capset call
+ * @new: the new credentials
+ * @old: the old (current) credentials
++=======
+ * @pid target pid of the capset call
+ * @eff effective cap set
+ * @inh inheritible cap set
+ * @perm permited cap set
++>>>>>>> audit/for-next:kernel/auditsc.c
*
* Record the aguments userspace sent to sys_capset for later printing by the
* audit system if applicable
*/
++<<<<<<< HEAD:kernel/auditsc.c
+int __audit_log_capset(pid_t pid,
+ const struct cred *new, const struct cred *old)
++=======
+ int __audit_log_capset(pid_t pid, kernel_cap_t *eff, kernel_cap_t *inh, kernel_cap_t *perm)
++>>>>>>> audit/for-next:kernel/auditsc.c
{
struct audit_aux_data_capset *ax;
struct audit_context *context = current->audit_context;
@@@ -2635,9 -2628,9 +2679,15 @@@
context->aux = (void *)ax;
ax->pid = pid;
++<<<<<<< HEAD:kernel/auditsc.c
+ ax->cap.effective = new->cap_effective;
+ ax->cap.inheritable = new->cap_effective;
+ ax->cap.permitted = new->cap_permitted;
++=======
+ ax->cap.effective = *eff;
+ ax->cap.inheritable = *eff;
+ ax->cap.permitted = *perm;
++>>>>>>> audit/for-next:kernel/auditsc.c
return 0;
}
diff --cc kernel/capability.c
index 36b4b4d,aaa2262..0000000
--- a/kernel/capability.c
+++ b/kernel/capability.c
@@@ -271,23 -458,36 +271,42 @@@ asmlinkage long sys_capset(cap_user_hea
i++;
}
++<<<<<<< HEAD:kernel/capability.c
+ new = prepare_creds();
+ if (!new)
+ return -ENOMEM;
++=======
+ ret = audit_log_capset(pid, &effective, &inheritable, &permitted);
+ if (ret)
+ return ret;
+
+ if (pid && (pid != task_pid_vnr(current)))
+ ret = do_sys_capset_other_tasks(pid, &effective, &inheritable,
+ &permitted);
+ else {
+ /*
+ * This lock is required even when filesystem
+ * capability support is configured - it protects the
+ * sys_capget() call from returning incorrect data in
+ * the case that the targeted process is not the
+ * current one.
+ */
+ spin_lock(&task_capability_lock);
++>>>>>>> audit/for-next:kernel/capability.c
- ret = security_capset_check(current, &effective, &inheritable,
- &permitted);
- /*
- * Having verified that the proposed changes are
- * legal, we now put them into effect.
- */
- if (!ret)
- security_capset_set(current, &effective, &inheritable,
- &permitted);
- spin_unlock(&task_capability_lock);
- }
+ ret = security_capset(new, current_cred(),
+ &effective, &inheritable, &permitted);
+ if (ret < 0)
+ goto error;
+
+ ret = audit_log_capset(pid, new, current_cred());
+ if (ret < 0)
+ return ret;
+ return commit_creds(new);
+error:
+ abort_creds(new);
return ret;
}
diff --cc security/commoncap.c
index 7971354,0b88160..0000000
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@@ -265,50 -203,46 +265,93 @@@ int cap_inode_killpriv(struct dentry *d
return inode->i_op->removexattr(dentry, XATTR_NAME_CAPS);
}
++<<<<<<< HEAD:security/commoncap.c
+/*
+ * Calculate the new process capability sets from the capability sets attached
+ * to a file.
+ */
+static inline int bprm_caps_from_vfs_caps(struct cpu_vfs_cap_data *caps,
+ struct linux_binprm *bprm,
+ bool *effective)
+{
+ struct cred *new = bprm->cred;
+ unsigned i;
+ int ret = 0;
+
+ if (caps->magic_etc & VFS_CAP_FLAGS_EFFECTIVE)
+ *effective = true;
+
+ CAP_FOR_EACH_U32(i) {
+ __u32 permitted = caps->permitted.cap[i];
+ __u32 inheritable = caps->inheritable.cap[i];
+
+ /*
+ * pP' = (X & fP) | (pI & fI)
+ */
+ new->cap_permitted.cap[i] =
+ (new->cap_bset.cap[i] & permitted) |
+ (new->cap_inheritable.cap[i] & inheritable);
+
+ if (permitted & ~new->cap_permitted.cap[i])
+ /* insufficient to execute correctly */
+ ret = -EPERM;
+ }
+
+ /*
+ * For legacy apps, with no internal support for recognizing they
+ * do not have enough capabilities, we return an error if they are
+ * missing some "forced" (aka file-permitted) capabilities.
+ */
+ return *effective ? ret : 0;
+}
+
+/*
+ * Extract the on-exec-apply capability sets for an executable file.
+ */
+int get_vfs_caps_from_disk(const struct dentry *dentry, struct cpu_vfs_cap_data *cpu_caps)
+{
++=======
+ static inline int bprm_caps_from_vfs_caps(struct cpu_vfs_cap_data *caps,
+ struct linux_binprm *bprm)
+ {
+ unsigned i;
+ int ret = 0;
+
+ if (caps->magic_etc & VFS_CAP_FLAGS_EFFECTIVE)
+ bprm->cap_effective = true;
+ else
+ bprm->cap_effective = false;
+
+ CAP_FOR_EACH_U32(i) {
+ __u32 permitted = caps->permitted.cap[i];
+ __u32 inheritable = caps->inheritable.cap[i];
+
+ /*
+ * pP' = (X & fP) | (pI & fI)
+ */
+ bprm->cap_post_exec_permitted.cap[i] =
+ (current->cap_bset.cap[i] & permitted) |
+ (current->cap_inheritable.cap[i] & inheritable);
+
+ if (permitted & ~bprm->cap_post_exec_permitted.cap[i]) {
+ /*
+ * insufficient to execute correctly
+ */
+ ret = -EPERM;
+ }
+ }
+
+ /*
+ * For legacy apps, with no internal support for recognizing they
+ * do not have enough capabilities, we return an error if they are
+ * missing some "forced" (aka file-permitted) capabilities.
+ */
+ return bprm->cap_effective ? ret : 0;
+ }
+
+ int get_vfs_caps_from_disk(const struct dentry *dentry, struct cpu_vfs_cap_data *cpu_caps)
+ {
++>>>>>>> audit/for-next:security/commoncap.c
struct inode *inode = dentry->d_inode;
__u32 magic_etc;
unsigned tocopy, i;
@@@ -322,9 -256,10 +365,16 @@@
size = inode->i_op->getxattr((struct dentry *)dentry, XATTR_NAME_CAPS, &caps,
XATTR_CAPS_SZ);
++<<<<<<< HEAD:security/commoncap.c
+ if (size == -ENODATA || size == -EOPNOTSUPP)
+ /* no data, that's ok */
+ return -ENODATA;
++=======
+ if (size == -ENODATA || size == -EOPNOTSUPP) {
+ /* no data, that's ok */
+ return -ENODATA;
+ }
++>>>>>>> audit/for-next:security/commoncap.c
if (size < 0)
return size;
@@@ -354,7 -289,6 +404,10 @@@
cpu_caps->permitted.cap[i] = le32_to_cpu(caps.data[i].permitted);
cpu_caps->inheritable.cap[i] = le32_to_cpu(caps.data[i].inheritable);
}
++<<<<<<< HEAD:security/commoncap.c
+
++=======
++>>>>>>> audit/for-next:security/commoncap.c
return 0;
}
@@@ -389,10 -316,7 +442,14 @@@ static int get_file_caps(struct linux_b
goto out;
}
++<<<<<<< HEAD:security/commoncap.c
+ rc = bprm_caps_from_vfs_caps(&vcaps, bprm, effective);
+ if (rc == -EINVAL)
+ printk(KERN_NOTICE "%s: cap_from_disk returned %d for %s\n",
+ __func__, rc, bprm->filename);
++=======
+ rc = bprm_caps_from_vfs_caps(&vcaps, bprm);
++>>>>>>> audit/for-next:security/commoncap.c
out:
dput(dentry);
@@@ -471,47 -356,59 +528,74 @@@ int cap_bprm_set_creds(struct linux_bin
* executables under compatibility mode, we override the
* capability sets for the file.
*
- * If only the real uid is 0, we do not set the effective
- * bit.
+ * If only the real uid is 0, we do not set the effective bit.
*/
- if (bprm->e_uid == 0 || current->uid == 0) {
+ if (new->euid == 0 || new->uid == 0) {
/* pP' = (cap_bset & ~0) | (pI & ~0) */
- bprm->cap_post_exec_permitted = cap_combine(
- current->cap_bset, current->cap_inheritable
- );
- bprm->cap_effective = (bprm->e_uid == 0);
- ret = 0;
+ new->cap_permitted = cap_combine(old->cap_bset,
+ old->cap_inheritable);
}
+ if (new->euid == 0)
+ effective = true;
}
++<<<<<<< HEAD:security/commoncap.c
+ /* Don't let someone trace a set[ug]id/setpcap binary with the revised
+ * credentials unless they have the appropriate permit
+ */
+ if ((new->euid != old->uid ||
+ new->egid != old->gid ||
+ !cap_issubset(new->cap_permitted, old->cap_permitted)) &&
+ bprm->unsafe & ~LSM_UNSAFE_PTRACE_CAP) {
+ /* downgrade; they get no more than they had, and maybe less */
+ if (!capable(CAP_SETUID)) {
+ new->euid = new->uid;
+ new->egid = new->gid;
++=======
+ return ret;
+ }
+
+ void cap_bprm_apply_creds (struct linux_binprm *bprm, int unsafe)
+ {
+ kernel_cap_t pP = current->cap_permitted;
+ kernel_cap_t pE = current->cap_effective;
+
+ if (bprm->e_uid != current->uid || bprm->e_gid != current->gid ||
+ !cap_issubset(bprm->cap_post_exec_permitted,
+ current->cap_permitted)) {
+ set_dumpable(current->mm, suid_dumpable);
+ current->pdeath_signal = 0;
+
+ if (unsafe & ~LSM_UNSAFE_PTRACE_CAP) {
+ if (!capable(CAP_SETUID)) {
+ bprm->e_uid = current->uid;
+ bprm->e_gid = current->gid;
+ }
+ if (cap_limit_ptraced_target()) {
+ bprm->cap_post_exec_permitted = cap_intersect(
+ bprm->cap_post_exec_permitted,
+ current->cap_permitted);
+ }
++>>>>>>> audit/for-next:security/commoncap.c
}
+ if (cap_limit_ptraced_target())
+ new->cap_permitted = cap_intersect(new->cap_permitted,
+ old->cap_permitted);
}
- current->suid = current->euid = current->fsuid = bprm->e_uid;
- current->sgid = current->egid = current->fsgid = bprm->e_gid;
+ new->suid = new->fsuid = new->euid;
+ new->sgid = new->fsgid = new->egid;
- /* For init, we want to retain the capabilities set
- * in the init_task struct. Thus we skip the usual
- * capability rules */
+ /* For init, we want to retain the capabilities set in the initial
+ * task. Thus we skip the usual capability rules
+ */
if (!is_global_init(current)) {
- current->cap_permitted = bprm->cap_post_exec_permitted;
- if (bprm->cap_effective)
- current->cap_effective = bprm->cap_post_exec_permitted;
+ if (effective)
+ new->cap_effective = new->cap_permitted;
else
- cap_clear(current->cap_effective);
+ cap_clear(new->cap_effective);
}
+ bprm->cap_effective = effective;
/*
* Audit candidate if current->cap_effective is set
@@@ -525,38 -422,22 +609,46 @@@
* Number 1 above might fail if you don't have a full bset, but I think
* that is interesting information to audit.
*/
++<<<<<<< HEAD:security/commoncap.c
+ if (!cap_isclear(new->cap_effective)) {
+ if (!cap_issubset(CAP_FULL_SET, new->cap_effective) ||
+ new->euid != 0 || new->uid != 0 ||
+ issecure(SECURE_NOROOT)) {
+ ret = audit_log_bprm_fcaps(bprm, new, old);
+ if (ret < 0)
+ return ret;
+ }
++=======
+ if (!cap_isclear(current->cap_effective)) {
+ if (!cap_issubset(CAP_FULL_SET, current->cap_effective) ||
+ (bprm->e_uid != 0) || (current->uid != 0) ||
+ issecure(SECURE_NOROOT))
+ audit_log_bprm_fcaps(bprm, &pP, &pE);
++>>>>>>> audit/for-next:security/commoncap.c
}
- current->securebits &= ~issecure_mask(SECURE_KEEP_CAPS);
+ new->securebits &= ~issecure_mask(SECURE_KEEP_CAPS);
+ return 0;
}
-int cap_bprm_secureexec (struct linux_binprm *bprm)
+/**
+ * cap_bprm_secureexec - Determine whether a secure execution is required
+ * @bprm: The execution parameters
+ *
+ * Determine whether a secure execution is required, return 1 if it is, and 0
+ * if it is not.
+ *
+ * The credentials have been committed by this point, and so are no longer
+ * available through @bprm->cred.
+ */
+int cap_bprm_secureexec(struct linux_binprm *bprm)
{
- if (current->uid != 0) {
+ const struct cred *cred = current_cred();
+
+ if (cred->uid != 0) {
if (bprm->cap_effective)
return 1;
- if (!cap_isclear(bprm->cap_post_exec_permitted))
+ if (!cap_isclear(cred->cap_permitted))
return 1;
}
^ permalink raw reply
* Re: linux-next: mmc tree build failure
From: Pierre Ossman @ 2008-12-09 6:47 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Rafael J. Wysocki, Greg KH, Philip Langdale
In-Reply-To: <20081209144244.fc3ebaa0.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1147 bytes --]
On Tue, 9 Dec 2008 14:42:44 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Pierre,
>
> On Thu, 4 Dec 2008 15:28:29 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Due to commit 75766a3cee0a1eb2f373e8112a73e69262e7831a ("ricoh_mmc: Use
> > suspend/resume_noirq") clashing with commit
> > 6e674b2ed59695a90166d9500aa2696a495696e7 ("PM: Simplify the new
> > suspend/hibernation framework for devices") from the driver-core tree.
> >
> > I am not sure what to do with this, so I have reverted the mmc tree
> > commit above for today. Hopefully, Rafael can suggest a fix.
>
> Since I am still getting this error, I have dropped the mmc tree for
> today.
Sorry about that. I got side-tracked and forgot to push the fixed tree.
It should be up now.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: m68k build failure
From: Stephen Rothwell @ 2008-12-09 6:45 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-next, Geert Uytterhoeven, Stephen Hemminger
[-- Attachment #1: Type: text/plain, Size: 508 bytes --]
Hi Dave,
The linux-next build (m68k defconfig) failed like this:
drivers/net/hydra.c: In function 'hydra_init':
/drivers/net/hydra.c:163: error: 'hydra_netdev_ops' undeclared (first use in this function)
Caused by commit 5618f0d1193d6b051da9b59b0e32ad24397f06a4 ("hydra:
convert to net_device_ops") which contains a typo in the net_device_ops
structure naming (presumably cut and paste).
--
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: avr32 build failure
From: Stephen Rothwell @ 2008-12-09 6:40 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-next, Haavard Skinnemoen
[-- Attachment #1: Type: text/plain, Size: 843 bytes --]
Hi Rusty,
The linux-next build (avr32 defconfig) failed like this:
arch/avr32/lib/lib.a(findbit.o): In function `generic_find_next_le_bit':
arch/avr32/lib/findbit.S:(.text+0xa6): multiple definition of `generic_find_next_le_bit'
lib/lib.a(find_next_bit.o):find_next_bit.c:(.text+0x58): first defined here
arch/avr32/lib/lib.a(findbit.o): In function `generic_find_next_zero_le_bit':
arch/avr32/lib/findbit.S:(.text+0xde): multiple definition of `generic_find_next_zero_le_bit'
lib/lib.a(find_next_bit.o):find_next_bit.c:(.text+0x144): first defined here
Caused by commit 9c5b94713eeadb030a3c72f7bfb07d7695f75699
("bitmap:find_last_bit") which caused lib/find_next_bit.o to be built
where it would not have been before.
--
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: net tree build failure
From: Stephen Rothwell @ 2008-12-09 6:29 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-next, Marcel Holtmann, Russell King
[-- Attachment #1: Type: text/plain, Size: 466 bytes --]
Hi Dave,
The linux-next build (arm xm_x2xx_defconfig) fails like this:
net/bluetooth/rfcomm/sock.c: In function 'rfcomm_sock_ioctl':
net/bluetooth/rfcomm/sock.c:795: error: 'sk' undeclared (first use in this function)
Introduced (I think) by commit a418b893a6af11ae73c762ed5b76c1bad6dc19d8
("Bluetooth: Enable per-module dynamic debug messages").
--
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 security-testing tree
From: Stephen Rothwell @ 2008-12-09 5:40 UTC (permalink / raw)
To: James Morris; +Cc: linux-next, David Howells, Miloslav Trmac, Al Viro
Hi James,
Today's linux-next merge of the security-testing tree got a conflict in
drivers/char/tty_audit.c between commit
49518720d67042cf431e7f96aed5b0f5c51a84e3 ("[PATCH] Audit: Log TIOCSTI")
from the audit-current tree and commit
66303bce9b924e35e435d35409d3abc371755767 ("CRED: Wrap task credential
accesses in the tty driver") from the security-testing tree.
The former moved the code that the latter was modifying. 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 drivers/char/tty_audit.c
index 632c296,d961fa9..0000000
--- a/drivers/char/tty_audit.c
+++ b/drivers/char/tty_audit.c
@@@ -76,11 -82,16 +76,12 @@@ static void tty_audit_log(const char *d
ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_TTY);
if (ab) {
char name[sizeof(tsk->comm)];
+ uid_t uid = task_uid(tsk);
- audit_log_format(ab, "tty pid=%u uid=%u auid=%u ses=%u "
- "major=%d minor=%d comm=",
+ audit_log_format(ab, "%s pid=%u uid=%u auid=%u ses=%u "
+ "major=%d minor=%d comm=", description,
- tsk->pid, tsk->uid, loginuid, sessionid,
+ tsk->pid, uid, loginuid, sessionid,
- buf->major, buf->minor);
+ major, minor);
get_task_comm(name, tsk);
audit_log_untrustedstring(ab, name);
audit_log_format(ab, " data=");
^ permalink raw reply
* Re: [PATCH] staging: really fix up Kconfig automatic deselction
From: Dmitry Eremin-Solenikov @ 2008-12-09 4:32 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, Stephen Rothwell
In-Reply-To: <20081209035444.GA22626@suse.de>
Greg KH wrote:
> On Tue, Dec 09, 2008 at 04:10:51AM +0300, Dmitry Eremin-Solenikov wrote:
>> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>
> This patch should be used instead of your current one in my tree, right?
> Or apply it on top of your current one?
On top of the previous one. If you want, you can squash them into one
commit, of course.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH] staging: really fix up Kconfig automatic deselction
From: Greg KH @ 2008-12-09 3:54 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: linux-next, Stephen Rothwell
In-Reply-To: <1228785051-12954-1-git-send-email-dbaryshkov@gmail.com>
On Tue, Dec 09, 2008 at 04:10:51AM +0300, Dmitry Eremin-Solenikov wrote:
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
This patch should be used instead of your current one in my tree, right?
Or apply it on top of your current one?
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: manual merge of the staging tree
From: Greg KH @ 2008-12-09 3:53 UTC (permalink / raw)
To: David Miller; +Cc: sfr, linux-next, wangchen
In-Reply-To: <20081208.123557.22263181.davem@davemloft.net>
On Mon, Dec 08, 2008 at 12:35:57PM -0800, David Miller wrote:
> From: Greg KH <greg@kroah.com>
> Date: Mon, 8 Dec 2008 07:17:50 -0800
>
> > On Mon, Dec 08, 2008 at 08:34:03PM +1100, Stephen Rothwell wrote:
> > > Hi Greg,
> > >
> > > Today's linux-next merge of the staging tree got a conflicts in
> > > drivers/staging/wlan-ng/p80211netdev.c and
> > > drivers/staging/wlan-ng/p80211wext.c between commit
> > > 979123d5343b4fdcd4c682745b8a0be9b8fac248 ("staging-p80211: Kill directly
> > > reference of netdev->priv") from the net tree and various commits from
> > > the staging tree.
> > >
> > > I fixed it up (see below) and can carry the fixes as necessary. (In the
> > > case of the second file, the latter removed the code that the former
> > > modified.)
> >
> > Dave, can you just drop the patch from your queue? This should already
> > be fixed up in the -next tree to not use the field you are wanting to
> > remove, right? So you shouldn't get any build errors from what I can
> > tell.
>
> I'd have to revert, which is ugly, because I tend to never
> rebase my tree as too many people depend upon it.
>
> Do you _really_ want me to do that?
Ick, no, that's ok.
You should use quilt, make it much easier to revert :)
> Because I have to do allmodconfig test builds _too_, and the build
> will fail for me if I do these reverts which really would suck.
Ok, that's fine, as long as stephen can keep this patch in his tree,
I'll apply it to mine when you merge with Linus, as the staging tree
will probably be one of the last things before the next -rc1 window
closes.
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: manual merge of the lblnet tree
From: Casey Schaufler @ 2008-12-09 4:15 UTC (permalink / raw)
To: Paul Moore; +Cc: James Morris, Stephen Rothwell, linux-next, David Howells
In-Reply-To: <200812081758.10731.paul.moore@hp.com>
Paul Moore wrote:
> On Monday 08 December 2008 4:16:24 pm James Morris wrote:
>
>> On Mon, 8 Dec 2008, Paul Moore wrote:
>>
>>> James, is the security-testing tree rebased regularly or is
>>> suitable to back a tree against?
>>>
>> No, it doesn't get rebased.
>>
>
> Okay, experiment time. I think I managed to pull from all the right
> spots, merge everything appropriately and end up with a security/
> directory that builds so I pushed it back out to the lblnet-2.6_next
> tree. I'm not quite sure the proper etiquette here but I had to fix
> Casey's patch a bit since it would apply cleanly; Casey if you could
> take a look I would appreciate it (it isn't exactly like what Stephen
> posted earlier but it is pretty darn close).
>
\Working ...
^ permalink raw reply
* Re: linux-next: mmc tree build failure
From: Stephen Rothwell @ 2008-12-09 3:42 UTC (permalink / raw)
To: Pierre Ossman; +Cc: linux-next, Rafael J. Wysocki, Greg KH, Philip Langdale
In-Reply-To: <20081204152829.69a795a3.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]
Hi Pierre,
On Thu, 4 Dec 2008 15:28:29 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> drivers/mmc/host/ricoh_mmc.c:235: error: variable 'ricoh_mmc_pm_ext_opts' has initializer but incomplete type
> drivers/mmc/host/ricoh_mmc.c:236: error: unknown field 'suspend_noirq' specified in initializer
> drivers/mmc/host/ricoh_mmc.c:236: warning: excess elements in struct initializer
> drivers/mmc/host/ricoh_mmc.c:236: warning: (near initialization for 'ricoh_mmc_pm_ext_opts')
> drivers/mmc/host/ricoh_mmc.c:237: error: unknown field 'resume_noirq' specified in initializer
> drivers/mmc/host/ricoh_mmc.c:237: warning: excess elements in struct initializer
> drivers/mmc/host/ricoh_mmc.c:237: warning: (near initialization for 'ricoh_mmc_pm_ext_opts')
> drivers/mmc/host/ricoh_mmc.c:245: error: unknown field 'pm' specified in initializer
> drivers/mmc/host/ricoh_mmc.c:245: warning: initialization from incompatible pointer type
>
> Due to commit 75766a3cee0a1eb2f373e8112a73e69262e7831a ("ricoh_mmc: Use
> suspend/resume_noirq") clashing with commit
> 6e674b2ed59695a90166d9500aa2696a495696e7 ("PM: Simplify the new
> suspend/hibernation framework for devices") from the driver-core tree.
>
> I am not sure what to do with this, so I have reverted the mmc tree
> commit above for today. Hopefully, Rafael can suggest a fix.
Since I am still getting this error, I have dropped the mmc tree for
today.
--
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 net tree
From: Stephen Rothwell @ 2008-12-09 2:21 UTC (permalink / raw)
To: David Miller; +Cc: linux-next, Harvey Harrison, Chuck Lever, J. Bruce Fields
Hi Dave,
Today's linux-next merge of the net tree got a conflict in
fs/lockd/host.c between commit 3105d87fe1d311e80fd4781e82fa519fd5e2ffe2
("NLM: Support IPv6 scope IDs in nlm_display_address()") from the nfsd
tree and various commits that replace the NIP* macros from the net 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 fs/lockd/host.c
index 472aac1,c48c263..0000000
--- a/fs/lockd/host.c
+++ b/fs/lockd/host.c
@@@ -105,37 -104,25 +105,37 @@@ static void nlm_clear_port(struct socka
}
}
-static void nlm_display_address(const struct sockaddr *sap,
- char *buf, const size_t len)
+static void nlm_display_ipv4_address(const struct sockaddr *sap, char *buf,
+ const size_t len)
{
const struct sockaddr_in *sin = (struct sockaddr_in *)sap;
- snprintf(buf, len, NIPQUAD_FMT, NIPQUAD(sin->sin_addr.s_addr));
++ snprintf(buf, len, "%pI4", &sin->sin_addr.s_addr);
+}
+
+static void nlm_display_ipv6_address(const struct sockaddr *sap, char *buf,
+ const size_t len)
+{
const struct sockaddr_in6 *sin6 = (struct sockaddr_in6 *)sap;
+ if (ipv6_addr_v4mapped(&sin6->sin6_addr))
- snprintf(buf, len, NIPQUAD_FMT,
- NIPQUAD(sin6->sin6_addr.s6_addr32[3]));
++ snprintf(buf, len, "%pI4",
++ &sin6->sin6_addr.s6_addr32[3]);
+ else if (sin6->sin6_scope_id != 0)
- snprintf(buf, len, NIP6_FMT "%%%u", NIP6(sin6->sin6_addr),
++ snprintf(buf, len, "%pI6%%%u", &sin6->sin6_addr,
+ sin6->sin6_scope_id);
+ else
- snprintf(buf, len, NIP6_FMT, NIP6(sin6->sin6_addr));
++ snprintf(buf, len, "%pI6", &sin6->sin6_addr);
+}
+
+static void nlm_display_address(const struct sockaddr *sap,
+ char *buf, const size_t len)
+{
switch (sap->sa_family) {
- case AF_UNSPEC:
- snprintf(buf, len, "unspecified");
- break;
case AF_INET:
- snprintf(buf, len, "%pI4", &sin->sin_addr.s_addr);
+ nlm_display_ipv4_address(sap, buf, len);
break;
case AF_INET6:
- if (ipv6_addr_v4mapped(&sin6->sin6_addr))
- snprintf(buf, len, "%pI4",
- &sin6->sin6_addr.s6_addr32[3]);
- else
- snprintf(buf, len, "%pI6", &sin6->sin6_addr);
+ nlm_display_ipv6_address(sap, buf, len);
break;
default:
snprintf(buf, len, "unsupported address family");
^ permalink raw reply
* linux-next: manual merge of the net tree
From: Stephen Rothwell @ 2008-12-09 2:13 UTC (permalink / raw)
To: David Miller; +Cc: linux-next, Chuck Lever, J. Bruce Fields, Harvey Harrison
[-- Attachment #1: Type: text/plain, Size: 543 bytes --]
Hi Dave,
Today's linux-next merge of the net tree got a conflict in fs/lockd/mon.c
between commit 9e414471988c5558df3674b94e145d8f926a683f ("NSM: Support
IPv6 version of mon_name") from the nfsd tree and commit
be859405487324ed548f1ba11dc949b8230ab991 ("fs: replace NIPQUAD()") from
the net tree.
The former removed the code that the latter modified. However, the nfsd
tree has added some more usages of the NIP macros ...
--
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
* [PATCH] staging: really fix up Kconfig automatic deselction
From: Dmitry Eremin-Solenikov @ 2008-12-09 1:10 UTC (permalink / raw)
To: linux-next; +Cc: Greg Kroah-Hartman, Stephen Rothwell, Dmitry Eremin-Solenikov
In-Reply-To: <20081208150832.GB19711@kroah.com>
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
drivers/staging/Kconfig | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 4089f14..1905919 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -39,6 +39,8 @@ config STAGING_EXCLUDE_BUILD
when selecting 'make allyesconfg' and 'make allmodconfig' so
don't be all that put off, your dog will be just fine.
+if !STAGING_EXCLUDE_BUILD
+
source "drivers/staging/et131x/Kconfig"
source "drivers/staging/slicoss/Kconfig"
@@ -62,3 +64,5 @@ source "drivers/staging/at76_usb/Kconfig"
source "drivers/staging/poch/Kconfig"
endif # !STAGING_EXCLUDE_BUILD
+
+endif # STAGING
--
1.5.6.5
^ permalink raw reply related
* Re: linux-next: manual merge of the lblnet tree
From: Stephen Rothwell @ 2008-12-09 0:23 UTC (permalink / raw)
To: Jean Delvare; +Cc: Paul Moore, linux-next, Hans de Goede
In-Reply-To: <20081208211941.6d2c2261@hyperion.delvare>
[-- Attachment #1: Type: text/plain, Size: 737 bytes --]
Hi Jean,
On Mon, 8 Dec 2008 21:19:41 +0100 Jean Delvare <khali@linux-fr.org> wrote:
>
> All in all I don't think it really matters.
> Documentation/feature-removal-schedule.txt will always have conflicts
> by design, but it's only a text file and if it isn't totally up-to-date
> in linux-next, I doubt anybody cares. So I would vote for permanently
> ignoring conflicts to this file.
I still have to do something with the conflicts and fixing them (like
this one) is trivial and "git rerere" remembers them, so carrying them is
also trivial. And, as you imply, it really doesn't matter if I get one
wrong. :-)
--
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: ide tree build failure
From: Stephen Rothwell @ 2008-12-09 0:12 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-next, Borislav Petkov
In-Reply-To: <200812081810.59270.bzolnier@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 419 bytes --]
Hi Bart,
On Mon, 8 Dec 2008 18:10:59 +0100 Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> wrote:
>
> I see, BLK_DEV_IDECD needs to select IDE_ATAPI now. I updated
> ide-atapi-accomodate-transfer-length-calculation-for-ide-cd.patch
> accordingly so ppc64_defconfing should build fine again.
Thanks.
--
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
* next-2008-11-09: s390 vs ->ioctx_list
From: Alexey Dobriyan @ 2008-12-09 0:11 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, jmoyer, jens.axboe
In-Reply-To: <20081208205929.366a9a01.sfr@canb.auug.org.au>
CC arch/s390/mm/pgtable.o
arch/s390/mm/pgtable.c: In function 's390_enable_sie':
arch/s390/mm/pgtable.c:266: error: invalid operands to binary ||
arch/s390/mm/pgtable.c:282: error: invalid operands to binary ||
This is because ->ioctx_list turned from pointer to a hlist, some more locking
and different check required.
^ permalink raw reply
* Re: linux-next: manual merge of the lblnet tree
From: Paul Moore @ 2008-12-08 22:58 UTC (permalink / raw)
To: James Morris, Casey Schaufler; +Cc: Stephen Rothwell, linux-next, David Howells
In-Reply-To: <alpine.LRH.1.10.0812090815370.6220@tundra.namei.org>
On Monday 08 December 2008 4:16:24 pm James Morris wrote:
> On Mon, 8 Dec 2008, Paul Moore wrote:
> > James, is the security-testing tree rebased regularly or is
> > suitable to back a tree against?
>
> No, it doesn't get rebased.
Okay, experiment time. I think I managed to pull from all the right
spots, merge everything appropriately and end up with a security/
directory that builds so I pushed it back out to the lblnet-2.6_next
tree. I'm not quite sure the proper etiquette here but I had to fix
Casey's patch a bit since it would apply cleanly; Casey if you could
take a look I would appreciate it (it isn't exactly like what Stephen
posted earlier but it is pretty darn close).
> > If so, I can rebase the lblnet-2.6_next tree
> > against security-testing to resolve the conflict ...
>
> Ok, and I can carry your patches in there if necessary.
I would like to figure out to make this work as it is likely to happen
again at some point in the future, but if I can't get it working
quickly I may punt on it and ask you to pull in the patches.
--
paul moore
linux @ hp
^ 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