* Re: linux-next: scsi tree build warnings
From: James Smart @ 2008-12-11 14:35 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: James Bottomley, linux-next@vger.kernel.org
In-Reply-To: <20081211132503.bc5e5994.sfr@canb.auug.org.au>
we're cleaning this up now...
-- james s
Stephen Rothwell wrote:
> Hi James,
>
> Today's linux-next build (powerpc ppc64_defconfig) produced these
> warnings:
>
> drivers/scsi/lpfc/lpfc_scsi.c: In function 'lpfc_parse_bg_err':
> drivers/scsi/lpfc/lpfc_scsi.c:1319: warning: format '%llx' expects type 'long long unsigned int', but argument 3 has type 'sector_t'
> drivers/scsi/lpfc/lpfc_scsi.c: In function 'lpfc_queuecommand':
> drivers/scsi/lpfc/lpfc_scsi.c:2376: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'sector_t'
> drivers/scsi/lpfc/lpfc_scsi.c:2382: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'sector_t'
> drivers/scsi/lpfc/lpfc_scsi.c:2404: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'sector_t'
> drivers/scsi/lpfc/lpfc_scsi.c:2409: warning: format '%llu' expects type 'long long unsigned int', but argument 6 has type 'sector_t'
> drivers/scsi/lpfc/lpfc_attr.c: In function 'lpfc_bg_guard_err_show':
> drivers/scsi/lpfc/lpfc_attr.c:126: warning: format '%llu' expects type 'long long unsigned int', but argument 4 has type 'uint64_t'
> drivers/scsi/lpfc/lpfc_attr.c: In function 'lpfc_bg_apptag_err_show':
> drivers/scsi/lpfc/lpfc_attr.c:137: warning: format '%llu' expects type 'long long unsigned int', but argument 4 has type 'uint64_t'
> drivers/scsi/lpfc/lpfc_attr.c: In function 'lpfc_bg_reftag_err_show':
> drivers/scsi/lpfc/lpfc_attr.c:148: warning: format '%llu' expects type 'long long unsigned int', but argument 4 has type 'uint64_t'
>
> Introduced by commit 46c6a5eabb0284b10c0377bd78c04edcb4163ee0 ("[SCSI] lpfc 8.3.0 : Add BlockGuard support (T10-DIF) code").
>
> I guess sector_t and uint64_t should be cast to "unsigned long long"
> for printing as u64 is "unsigned long" on some architectures and
> "unsigned long long" on others.
^ permalink raw reply
* Re: linux-next: Tree for December 11
From: Alexey Zaytsev @ 2008-12-11 12:40 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML
In-Reply-To: <20081211200459.14d18d7a.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 3163 bytes --]
On Thu, Dec 11, 2008 at 12:04, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Changes since 20081210:
>
> New tree:
> nommu
>
> Undropped tree:
> sound
>
> Dropped trees (temporarily):
> v4l-dvb (build problem)
> mtd (difficult conflicts)
> 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)
> nommu (build problem)
> staging (build failure)
>
> The driver-core tree gained a build failure that needed a commit reverted.
>
> The ftrace tree gained a conflict against Linus' tree.
>
> The pci tree gained a conflict against the driver-core tree.
>
> The mtd tree gained 3 conflicts against the arm tree which I could not
> easily resolve, so it was dropped.
>
> The ttydev tree gained a conflict against the async_tx tree requiring a
> commit from the async_tx tree to be reverted.
>
> The nommu tree gained conflicts against the slab and kmemcheck trees and
> also a build failure so it was dropped.
>
> ----------------------------------------------------------------------------
Hi.
I'm seeing this warning early in boot logs. It does not appear on 2.6.28-rc7.
Not sure how long it's been around. Haven't built -next for some time.
[ 0.004000] Intel machine check reporting enabled on CPU#0.
[ 0.004000] using mwait in idle threads.
[ 0.004000] Checking 'hlt' instruction... <4>------------[ cut here
]------------
[ 0.004167] WARNING: at kernel/sched.c:4364 sub_preempt_count+0xae/0xc0()
[ 0.004266] Hardware name: HP Compaq nx7300 (GB848ES#ACB)
[ 0.004361] Modules linked in:
[ 0.004497] Pid: 0, comm: swapper Not tainted 2.6.28-rc8-next-20081211 #117
[ 0.004595] Call Trace:
[ 0.004689] [<c01324d6>] warn_slowpath+0x86/0xa0
[ 0.004789] [<c0155d00>] ? check_usage_forwards+0x10/0xb0
[ 0.004886] [<c015394a>] ? save_trace+0x3a/0xa0
[ 0.004981] [<c015742d>] ? mark_lock+0x37d/0xe00
[ 0.005076] [<c01580f9>] ? __lock_acquire+0x249/0x610
[ 0.005175] [<c04a3a02>] ? _spin_unlock_irq+0x22/0x50
[ 0.005272] [<c0158e50>] ? trace_hardirqs_on_caller+0x70/0x1a0
[ 0.005369] [<c04a3a0d>] ? _spin_unlock_irq+0x2d/0x50
[ 0.005465] [<c0124bfe>] sub_preempt_count+0xae/0xc0
[ 0.005564] [<c0137012>] _local_bh_enable+0x52/0xc0
[ 0.005661] [<c013725f>] __do_softirq+0x11f/0x170
[ 0.005756] [<c0137140>] ? __do_softirq+0x0/0x170
[ 0.005851] <IRQ> [<c0137729>] ? irq_exit+0x89/0xa0
[ 0.005993] [<c01059ed>] ? do_IRQ+0xad/0x120
[ 0.006088] [<c0103aac>] ? common_interrupt+0x2c/0x34
[ 0.006184] [<c013007b>] ? mmput+0x2b/0xc0
[ 0.006281] [<c06735a8>] ? check_bugs+0xb8/0xe0
[ 0.006379] [<c066b7ea>] ? start_kernel+0x26a/0x310
[ 0.006475] [<c066b270>] ? unknown_bootoption+0x0/0x210
[ 0.006572] [<c066b077>] ? __init_begin+0x77/0xb0
[ 0.006674] ---[ end trace 4eaa2a86a8e2da22 ]---
[ 0.016004] OK.
[ 0.016560] ACPI: Core revision 20081031
[ 0.044495] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
Config and full dmesg attached.
[-- Attachment #2: config.gz --]
[-- Type: application/x-gzip, Size: 13973 bytes --]
[-- Attachment #3: dmesg.gz --]
[-- Type: application/x-gzip, Size: 15202 bytes --]
^ permalink raw reply
* Re: linux-next: scsi-post-merge tree build failure
From: David Howells @ 2008-12-11 12:35 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: dhowells, linux-next
In-Reply-To: <20081211192737.44532af0.sfr@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Today's linux-next build (powerpc ppc44x_config) failed like this:
>
> arch/powerpc/lib/dma-noncoherent.c:80: error: redefinition of 'struct vm_region'
>
> Caused by commit f65466230e8afd45f716e5b836711ce270f45105 ("NOMMU: Make
> VMAs per MM as for MMU-mode linux").
Sigh. Someone's already taken the name vm_region for a struct. I guess I
need to find a different name:-(
David
^ permalink raw reply
* RE: linux-next: manual merge of the mtd tree
From: Eric Miao @ 2008-12-11 10:32 UTC (permalink / raw)
To: Stephen Rothwell, Dmitry Eremin-Solenikov
Cc: David Woodhouse, linux-next, Russell King
In-Reply-To: <20081211212335.828b902c.sfr@canb.auug.org.au>
> -----Original Message-----
> From: Stephen Rothwell [mailto:sfr@canb.auug.org.au]
> Sent: 2008年12月11日 18:24
> To: Dmitry Eremin-Solenikov
> Cc: David Woodhouse; linux-next@vger.kernel.org; Eric Miao; Russell King
> Subject: Re: linux-next: manual merge of the mtd tree
>
> Hi Dmitry,
>
> On Thu, 11 Dec 2008 13:11:20 +0300 "Dmitry Eremin-Solenikov"
> <dbaryshkov@gmail.com> wrote:
> >
> > Unfortunately those changes are independant, so I don't quite
> > understand what to do.
> > If you'd prefer, I can provide merged versions of all 3 files, so that
> > you can use this
> > as merge resolution via git-rerere. Is that suitable for you?
>
> That would be a great help, thanks.
I can do a trivial merge of mtd tree and resolve this, but it would be
more reasonable if the merge can be made within one tree (I don't think
cross-merging back-n-forth is something interesting)
^ permalink raw reply
* Re: linux-next: manual merge of the mtd tree
From: Stephen Rothwell @ 2008-12-11 10:23 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: David Woodhouse, linux-next, Eric Miao, Russell King
In-Reply-To: <bc64b4640812110211h294707d8ndd58f611152b893d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 505 bytes --]
Hi Dmitry,
On Thu, 11 Dec 2008 13:11:20 +0300 "Dmitry Eremin-Solenikov" <dbaryshkov@gmail.com> wrote:
>
> Unfortunately those changes are independant, so I don't quite
> understand what to do.
> If you'd prefer, I can provide merged versions of all 3 files, so that
> you can use this
> as merge resolution via git-rerere. Is that suitable for you?
That would be a great help, 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: linux-next: manual merge of the ttydev tree
From: Alan Cox @ 2008-12-11 10:21 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Dan Williams, David Daney
In-Reply-To: <20081211172645.f40c8b9f.sfr@canb.auug.org.au>
On Thu, 11 Dec 2008 17:26:45 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Alan,
>
> Today's linux-next merge of the ttydev tree got a conflict in
> drivers/serial/8250.c between commit
> 507ce132910803e8fd1116467e99f59da3d526f0 ("iop13xx: workaround errata
> that causes uart interrupts to be missed") from the async_tx tree and
> commit 63c4074301f79f1620d6c880973d6ef1cc770990
> ("tty-serial-8250-regops") from the ttydev tree.
>
> I have reverted the async_tx commit for today. Please try to figure out
> what should happen here.
Dan - can you feed the uart 8250 patches through the ttydev tree or are
there dependancies on other parts of async_tx ?
Alan
^ permalink raw reply
* Re: linux-next: manual merge of the mtd tree
From: Dmitry Eremin-Solenikov @ 2008-12-11 10:11 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: David Woodhouse, linux-next, Eric Miao, Russell King
In-Reply-To: <20081211134307.b7ce748d.sfr@canb.auug.org.au>
2008/12/11 Stephen Rothwell <sfr@canb.auug.org.au>:
> Hi David,
>
> Today's linux-next merge of the mtd tree got conflicts in
> arch/arm/mach-pxa/corgi.c, arch/arm/mach-pxa/poodle.c and
> arch/arm/mach-pxa/spitz.c between commits
> 4a9295ccb43ead9ec054d0bd374c992c692b2cf4 ("[ARM] pxa/corgi: add physmap
> mapping for ROM"), 431a2cff07446b0325ec063e5b401ca7c11e0058 ("[ARM]
> pxa/poodle: add physmap mapping for ROM") and
> e5d3bf3c106c0557199076a57800adb85206c1ce ("[ARM] pxa/spitz: add physmap
> mapping for ROM") from the arm tree and commit
> 6af7a8eb1eb2b5a0967fccf61e750b085d60ad48 ("[MTD] sharpsl-nand: move
> registration to board code") from the mtd tree.
>
> They seem to be overlapping changes. Can you guys rationalise this,
> please, as I am in no position to fix these conflicts up.
Unfortunately those changes are independant, so I don't quite
understand what to do.
If you'd prefer, I can provide merged versions of all 3 files, so that
you can use this
as merge resolution via git-rerere. Is that suitable for you?
>
> I have dropped the mtd tree for today.
--
With best wishes
Dmitry
^ permalink raw reply
* next-20081210: BUG: sleeping function called from invalid context at mm/slub.c:1619 (XFS)
From: Alexander Beregalov @ 2008-12-11 10:10 UTC (permalink / raw)
To: linux-next@vger.kernel.org, xfs, xfs-masters
BUG: sleeping function called from invalid context at mm/slub.c:1619
in_atomic(): 1, irqs_disabled(): 0, pid: 8096, name: sh
INFO: lockdep is turned off.
Pid: 8096, comm: sh Tainted: G W 2.6.28-rc7-next-20081210 #2
Call Trace:
[<ffffffff80256e5a>] ? __debug_show_held_locks+0x1b/0x24
[<ffffffff8022fb55>] __might_sleep+0x120/0x122
[<ffffffff8029c526>] __kmalloc+0x70/0xfc
[<ffffffff803534d2>] kmem_alloc+0x75/0xd7
[<ffffffff803350ba>] xfs_fs_vcmn_err+0x46/0x94
[<ffffffff80335297>] xfs_fs_cmn_err+0x59/0x5e
[<ffffffff802578a1>] ? trace_hardirqs_on_caller+0x1f/0x15f
[<ffffffff803434c0>] ? xlog_grant_push_ail+0x26/0xed
[<ffffffff804e55d3>] ? _spin_lock+0x68/0x70
[<ffffffff803416e6>] xlog_space_left+0x62/0x6b
[<ffffffff803434d8>] xlog_grant_push_ail+0x3e/0xed
[<ffffffff80343c6f>] xfs_log_reserve+0xa8/0xbc
[<ffffffff8034cc4e>] xfs_trans_reserve+0xe0/0x1bb
[<ffffffff80350059>] xfs_create+0x138/0x431
[<ffffffff802ad852>] ? d_rehash+0x23/0x44
[<ffffffff8035a090>] xfs_vn_mknod+0xc9/0x139
[<ffffffff8035a11b>] xfs_vn_create+0xb/0xd
[<ffffffff802a89dd>] vfs_create+0x58/0x7e
[<ffffffff802a94f7>] do_filp_open+0x249/0x7d0
[<ffffffff8022fbec>] ? get_parent_ip+0x11/0x41
[<ffffffff80231651>] ? sub_preempt_count+0xba/0xce
[<ffffffff802b2a0a>] ? alloc_fd+0x11d/0x12e
[<ffffffff8029e19e>] do_sys_open+0x53/0xda
[<ffffffff80224b3d>] ? do_page_fault+0x394/0x887
[<ffffffff8029e24e>] sys_open+0x1b/0x1d
[<ffffffff8020b85b>] system_call_fastpath+0x16/0x1b
Filesystem "sda2": xlog_space_left: head behind tail
tail_cycle = 1802201963, tail_bytes = -690563584
GH cycle = 3078, GH bytes = 69183384
^ permalink raw reply
* linux-next: Tree for December 11
From: Stephen Rothwell @ 2008-12-11 9:04 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 9382 bytes --]
Hi all,
Changes since 20081210:
New tree:
nommu
Undropped tree:
sound
Dropped trees (temporarily):
v4l-dvb (build problem)
mtd (difficult conflicts)
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)
nommu (build problem)
staging (build failure)
The driver-core tree gained a build failure that needed a commit reverted.
The ftrace tree gained a conflict against Linus' tree.
The pci tree gained a conflict against the driver-core tree.
The mtd tree gained 3 conflicts against the arm tree which I could not
easily resolve, so it was dropped.
The ttydev tree gained a conflict against the async_tx tree requiring a
commit from the async_tx tree to be reverted.
The nommu tree gained conflicts against the slab and kmemcheck trees and
also a build failure so it 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 132 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
Created commit 1a20fa9: Revert "mtd: struct device - replace bus_id with dev_name(), dev_set_name()"
Merging quilt/usb
Merging tip-core/auto-core-next
Merging cpus4096/auto-cpus4096-next
Merging ftrace/auto-ftrace-next
CONFLICT (content): Merge conflict in include/linux/ftrace.h
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
CONFLICT (content): Merge conflict in drivers/pci/pci-driver.c
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 arch/arm/mach-pxa/corgi.c
CONFLICT (content): Merge conflict in arch/arm/mach-pxa/poodle.c
CONFLICT (content): Merge conflict in arch/arm/mach-pxa/spitz.c
$ git reset --hard
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
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 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 drivers/serial/8250.c
CONFLICT (content): Merge conflict in fs/devpts/inode.c
$ git reset --hard
Created commit a59876f: Revert "iop13xx: workaround errata that causes uart interrupts to be missed"
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 nommu/master
CONFLICT (content): Merge conflict in Documentation/sysctl/vm.txt
CONFLICT (content): Merge conflict in kernel/fork.c
Merging trivial/for-next
Merging quilt/staging
CONFLICT (delete/modify): drivers/staging/winbond/linux/wbusb.c deleted in quilt/staging and modified in HEAD. Version HEAD of drivers/staging/winbond/linux/wbusb.c left in tree.
CONFLICT (content): Merge conflict in drivers/staging/wlan-ng/p80211netdev.c
CONFLICT (content): Merge conflict in drivers/staging/wlan-ng/p80211wext.c
$ git rm -f drivers/staging/winbond/linux/wbusb.c
$ git reset --hard HEAD^
Merging scsi-post-merge/master
$ git reset --hard HEAD^^
Merging trivial/for-next
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the audit tree
From: Stephen Rothwell @ 2008-12-11 9:01 UTC (permalink / raw)
To: Al Viro; +Cc: David Howells, Eric Paris, linux-next, James Morris, Serge Hallyn
In-Reply-To: <20081211063138.GP28946@ZenIV.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 678 bytes --]
Hi Al,
On Thu, 11 Dec 2008 06:31:38 +0000 Al Viro <viro@ZenIV.linux.org.uk> wrote:
>
> So at this point everything in that branch is taken care of. I do have
> several more in a private queue, but those will need review and testing
> before they go into -next.
Easiest thing to do then is to make the for-linus and for-next branches
point into Linus' tree until you need them again. That way you don't
need to let me know when to start (or stop) fetching them again - I just
fetch them every day and if there is something there it will get
integrated.
--
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: powerpc build warning
From: Stephen Rothwell @ 2008-12-11 8:42 UTC (permalink / raw)
To: Paul Mackerras, Benjamin Herrenschmidt, linuxppc-dev
Cc: linux-next, Dave Hansen
[-- Attachment #1: Type: text/plain, Size: 464 bytes --]
Hi Paul,
Today's linux-next build (powerpc allyesconfig) produced this warning:
arch/powerpc/mm/numa.c: In function 'do_init_bootmem':
arch/powerpc/mm/numa.c:932: warning: unused variable 'i'
Caused by commit 4a6186696e7f15b3ea4dafcdb64ee0703e0e4487 ("powerpc: Fix
boot freeze on machine with empty memory node") which is now in Linus'
tree.
--
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: staging tree build failure
From: Stephen Rothwell @ 2008-12-11 8:37 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, Dmitry Baryshkov
In-Reply-To: <20081208204303.3c99dfa4.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 756 bytes --]
Hi Greg,
On Mon, 8 Dec 2008 20:43:03 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> drivers/staging/agnx/xmit.c: In function 'fill_agnx_hdr':
> drivers/staging/agnx/xmit.c:629: error: 'struct <anonymous>' has no member named 'retry_limit'
> drivers/staging/agnx/xmit.c:630: error: 'struct <anonymous>' has no member named 'retry_limit'
.
.
.
>
> Commit "STAGING: Move staging drivers back to staging-specific menu"
> allowed them to build in the allmodconfig again. I have dropped the
> staging tree for today.
This failure is still happening.
--
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: scsi-post-merge tree build failure
From: Stephen Rothwell @ 2008-12-11 8:28 UTC (permalink / raw)
To: David Howells; +Cc: linux-next
In-Reply-To: <20081211192737.44532af0.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 139 bytes --]
Should have been "nommu tree".
--
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: scsi-post-merge tree build failure
From: Stephen Rothwell @ 2008-12-11 8:27 UTC (permalink / raw)
To: David Howells; +Cc: linux-next
[-- Attachment #1: Type: text/plain, Size: 429 bytes --]
Hi David,
Today's linux-next build (powerpc ppc44x_config) failed like this:
arch/powerpc/lib/dma-noncoherent.c:80: error: redefinition of 'struct vm_region'
Caused by commit f65466230e8afd45f716e5b836711ce270f45105 ("NOMMU: Make
VMAs per MM as for MMU-mode linux").
I have dropped the nommu 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
* Re: linux-next: manual merge of the nommu tree
From: Paul Mundt @ 2008-12-11 7:42 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Howells, linux-next, Christoph Lameter, Pekka Enberg
In-Reply-To: <20081211182530.924d4af6.sfr@canb.auug.org.au>
On Thu, Dec 11, 2008 at 06:25:30PM +1100, Stephen Rothwell wrote:
> Hi David,
>
> Today's linux-next merge of the nommu tree got a conflict in
> Documentation/sysctl/vm.txt between commit
> cb8fc7a88a0069ebdab220180bf9b45e568f0ba9 ("slub: Trigger defragmentation
> from memory reclaim") from the slab tree and commit
> 1a5d96d0151ce2ec77bf08498751fe8d9365c95f ("NOMMU: Make mmap allocation
> page trimming behaviour configurable.") from the nommu tree.
>
> Just overlapping additions. I fixed it up (see below) and can carry the
> fix as necessary.
I suppose this is what happens when everyone has the same bright idea of
appending to the end of the file. Though I am surprised that there was
contention in Documentation/ of all places. Thanks for fixing this up.
^ permalink raw reply
* linux-next: manual merge of the nommu tree
From: Stephen Rothwell @ 2008-12-11 7:43 UTC (permalink / raw)
To: David Howells; +Cc: linux-next, Vegard Nossum, Pekka Enberg, Ingo Molnar
Hi David,
Today's linux-next merge of the nommu tree got a conflict in
kernel/fork.c between commit e6df1035b1b488cafde1e69f1a25f2706c3ac1f7
("kmemcheck: add mm functions") from the kmemcheck tree and commit
f65466230e8afd45f716e5b836711ce270f45105 ("NOMMU: Make VMAs per MM as for
MMU-mode linux") from the nommu tree.
I fixed it up as best I can (see below) and can carry the fix as
necessary (though it would be good if you guys could figure out a better
solution).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc kernel/fork.c
index 446167a,d7c5b42..0000000
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@@ -1459,23 -1451,21 +1459,21 @@@ void __init proc_caches_init(void
{
sighand_cachep = kmem_cache_create("sighand_cache",
sizeof(struct sighand_struct), 0,
- SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_DESTROY_BY_RCU,
- sighand_ctor);
+ SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_DESTROY_BY_RCU|
+ SLAB_NOTRACK, sighand_ctor);
signal_cachep = kmem_cache_create("signal_cache",
sizeof(struct signal_struct), 0,
- SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
+ SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_NOTRACK, NULL);
files_cachep = kmem_cache_create("files_cache",
sizeof(struct files_struct), 0,
- SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
+ SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_NOTRACK, NULL);
fs_cachep = kmem_cache_create("fs_cache",
sizeof(struct fs_struct), 0,
- SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
+ SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_NOTRACK, NULL);
- vm_area_cachep = kmem_cache_create("vm_area_struct",
- sizeof(struct vm_area_struct), 0,
- SLAB_PANIC|SLAB_NOTRACK, NULL);
mm_cachep = kmem_cache_create("mm_struct",
sizeof(struct mm_struct), ARCH_MIN_MMSTRUCT_ALIGN,
- SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL);
+ SLAB_HWCACHE_ALIGN|SLAB_PANIC|SLAB_NOTRACK, NULL);
+ mmap_init();
}
/*
diff --git a/mm/mmap.c b/mm/mmap.c
index 6e5fc98..d85193e 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2478,5 +2478,5 @@ void __init mmap_init(void)
{
vm_area_cachep = kmem_cache_create("vm_area_struct",
sizeof(struct vm_area_struct), 0,
- SLAB_PANIC, NULL);
+ SLAB_PANIC|SLAB_NOTRACK, NULL);
}
diff --git a/mm/nommu.c b/mm/nommu.c
index 61b7f7a..efb3d01 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -447,10 +447,10 @@ void __init mmap_init(void)
{
vm_region_jar = kmem_cache_create("vm_region_jar",
sizeof(struct vm_region), 0,
- SLAB_PANIC, NULL);
+ SLAB_PANIC|SLAB_NOTRACK, NULL);
vm_area_cachep = kmem_cache_create("vm_area_struct",
sizeof(struct vm_area_struct), 0,
- SLAB_PANIC, NULL);
+ SLAB_PANIC|SLAB_NOTRACK, NULL);
}
/*
^ permalink raw reply related
* Re: [bug?] bio: add experimental support for inlining a number of bio_vecs inside the bio
From: Jens Axboe @ 2008-12-11 7:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: kosaki.motohiro, sfr, linux-next, linux-kernel
In-Reply-To: <20081210131311.e03d6fc5.akpm@linux-foundation.org>
On Wed, Dec 10 2008, Andrew Morton wrote:
> On Wed, 10 Dec 2008 13:12:38 +0100
> Jens Axboe <jens.axboe@oracle.com> wrote:
>
> > > experimental??
> >
> > Experimental in the sense that it's the first version, not the concept.
> > It's held up well for me, but just yesterday I received the first bug
> > report on a ppc platform and now you have this on ia64.
>
>
> Well there's another bug report up-list. "next-20081209: pdflush: page
> allocation failure (xfs)".
>
> The clearing of (__GFP_WAIT | __GFP_IO) will call the page allocator in the
> weakest possible mode and will of course spew page allocations warnings
> with great frequency. It should at least add in __GFP_NOWARN.
OK, that must be for the change titled
"bio: only mempool back the largest bio_vec slab cache"
and yes, that does look like it wants a bit more gfp loving, probably
the same as mempool_alloc() would use anyway. I'll get that fixed.
--
Jens Axboe
^ permalink raw reply
* linux-next: manual merge of the nommu tree
From: Stephen Rothwell @ 2008-12-11 7:25 UTC (permalink / raw)
To: David Howells; +Cc: linux-next, Christoph Lameter, Paul Mundt, Pekka Enberg
Hi David,
Today's linux-next merge of the nommu tree got a conflict in
Documentation/sysctl/vm.txt between commit
cb8fc7a88a0069ebdab220180bf9b45e568f0ba9 ("slub: Trigger defragmentation
from memory reclaim") from the slab tree and commit
1a5d96d0151ce2ec77bf08498751fe8d9365c95f ("NOMMU: Make mmap allocation
page trimming behaviour configurable.") from the nommu tree.
Just overlapping additions. 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 Documentation/sysctl/vm.txt
index 5e7329a,e9a5c28..0000000
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@@ -38,7 -38,7 +38,8 @@@ Currently, these files are in /proc/sys
- numa_zonelist_order
- nr_hugepages
- nr_overcommit_hugepages
+- slab_defrag_limit
+ - nr_trim_pages (only if CONFIG_MMU=n)
==============================================================
@@@ -351,11 -351,17 +352,27 @@@ See Documentation/vm/hugetlbpage.tx
==============================================================
+slab_defrag_limit
+
+Determines the frequency of calls from reclaim into slab defragmentation.
+Slab defrag reclaims objects from sparsely populates slab pages.
+The default is 1000. Increase if slab defragmentation occurs
+too frequently. Decrease if more slab defragmentation passes
+are needed. The slabinfo tool can report on the frequency of the callbacks.
+
++==============================================================
++
+ nr_trim_pages
+
+ This is available only on NOMMU kernels.
+
+ This value adjusts the excess page trimming behaviour of power-of-2 aligned
+ NOMMU mmap allocations.
+
+ A value of 0 disables trimming of allocations entirely, while a value of 1
+ trims excess pages aggressively. Any value >= 1 acts as the watermark where
+ trimming of allocations is initiated.
+
+ The default value is 1.
+
+ See Documentation/nommu-mmap.txt for more information.
^ permalink raw reply
* Re: linux-next: manual merge of the audit tree
From: Al Viro @ 2008-12-11 6:31 UTC (permalink / raw)
To: David Howells
Cc: Eric Paris, Stephen Rothwell, linux-next, James Morris,
Serge Hallyn
In-Reply-To: <13530.1228937583@redhat.com>
On Wed, Dec 10, 2008 at 07:33:03PM +0000, David Howells wrote:
> Eric Paris <eparis@redhat.com> wrote:
>
> > I think David is right, all the conflicts should come from
> > security-testing. Al does have other good stuff in his tree though, Al
> > do you want to just kick all of my patches out?
>
> Maybe it's worth James taking Al's changes into his tree and resolving all the
> conflicts in favour of what's in his tree.
It's already done. Everything that used to be in for-linus except
tty_audit.c one went into mainline; tty_audit got rediffed and sent
to James; for-linus..for-next had several Eric's patches that were
in security tree (and thus are dropped from audit one - I couldn't
care less which tree are they merged from as long as they get into
the mainline) and an s390 patch that got sent off to linux-s390@vger
and would be better off going via the s390 tree anyway.
So at this point everything in that branch is taken care of. I do have
several more in a private queue, but those will need review and testing
before they go into -next.
^ permalink raw reply
* linux-next: manual merge of the ttydev tree
From: Stephen Rothwell @ 2008-12-11 6:26 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-next, Dan Williams, David Daney
[-- Attachment #1: Type: text/plain, Size: 564 bytes --]
Hi Alan,
Today's linux-next merge of the ttydev tree got a conflict in
drivers/serial/8250.c between commit
507ce132910803e8fd1116467e99f59da3d526f0 ("iop13xx: workaround errata
that causes uart interrupts to be missed") from the async_tx tree and
commit 63c4074301f79f1620d6c880973d6ef1cc770990
("tty-serial-8250-regops") from the ttydev tree.
I have reverted the async_tx commit for today. Please try to figure out
what should happen here.
--
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: driver-core tree build failure
From: Greg KH @ 2008-12-11 4:55 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Kay Sievers
In-Reply-To: <20081211112127.7aa2c373.sfr@canb.auug.org.au>
On Thu, Dec 11, 2008 at 11:21:27AM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> drivers/mtd/maps/physmap.c: In function 'physmap_flash_probe':
> drivers/mtd/maps/physmap.c:108: error: expected ')' before '{' token
> drivers/mtd/maps/physmap.c:144: error: expected expression before '}' token
>
> Caused by commit 7267696c2421503e280d9da5bbdbd5c11e1e5b25 ("mtd: struct
> device - replace bus_id with dev_name(), dev_set_name()").
>
> I have reverted that patch for today.
>
> Please be more careful ... allmodconfig is your friend when doing wide
> ranging changes ...
Very sorry about that, I did kick off such a build, but forgot to look
at the result of it, my fault.
I've now fixed this up so it should be fine for tomorrow.
thanks for keeping us honest :)
greg k-h
^ permalink raw reply
* Re: [PATCH] cpumask:cpumask_of_node-ia64 fix
From: KOSAKI Motohiro @ 2008-12-11 4:53 UTC (permalink / raw)
To: Mike Travis
Cc: kosaki.motohiro, Luck, Tony, Rusty Russell, linux-next, LKML,
Stephen Rothwell
In-Reply-To: <494093F7.5020000@sgi.com>
> KOSAKI Motohiro wrote:
> > ===
> > Subject: [PATCH] cpumask:cpumask_of_node-ia64 fix
> > Impact: bug fix
> >
> > commit 07c636deede53ff3e96d54df0ece2c838e61951f introduce new CPU mask API and change cpu_mask variable type.
> >
> > -----------------------------------------------
> > - cpumask_t cpu_mask;
> > + const struct cpumask *cpu_mask;
> > --------------------------------------------------
> >
> >
> > However, its change is incomplete. in build time, compiler output following type mismatch warnings.
> >
> > arch/ia64/kernel/iosapic.c:708: warning: passing argument 2 of '__cpu_clear' from incompatible pointer type
> > arch/ia64/kernel/iosapic.c:711: warning: passing argument 1 of '__cpus_weight' from incompatible pointer type
> > arch/ia64/kernel/iosapic.c:719: warning: passing argument 1 of '__first_cpu' from incompatible pointer type
> > arch/ia64/kernel/iosapic.c:720: warning: passing argument 2 of '__next_cpu' from incompatible pointer type
>
> Good catch, however ...
> >
> >
> > Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> > CC: "Luck, Tony" <tony.luck@intel.com>
> > CC: Rusty Russell <rusty@rustcorp.com.au>
> > ---
> > arch/ia64/kernel/iosapic.c | 10 +++++-----
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > Index: b/arch/ia64/kernel/iosapic.c
> > ===================================================================
> > --- a/arch/ia64/kernel/iosapic.c
> > +++ b/arch/ia64/kernel/iosapic.c
> > @@ -695,7 +695,7 @@ get_target_cpu (unsigned int gsi, int ir
> > #ifdef CONFIG_NUMA
> > {
> > int num_cpus, cpu_index, iosapic_index, numa_cpu, i = 0;
> > - const struct cpumask *cpu_mask;
> > + struct cpumask *cpu_mask;
> >
> > iosapic_index = find_iosapic(gsi);
> > if (iosapic_index < 0 ||
> > @@ -705,10 +705,10 @@ get_target_cpu (unsigned int gsi, int ir
> > cpu_mask = cpumask_of_node(iosapic_lists[iosapic_index].node);
> > for_each_cpu_and(numa_cpu, cpu_mask, &domain) {
> > if (!cpu_online(numa_cpu))
> > - cpu_clear(numa_cpu, cpu_mask);
> > + cpu_clear(numa_cpu, *cpu_mask);
>
> ... you cannot modify the read-only cpumask_of_node map. Suggested alternative below.
Oh, I see.
I didn't understand original intention.
and my review and test doen't find any problem in your patch.
Very thanks.
The following is the folded patch of your patch and your over-simplified fix.
===
Subject: [PATCH] don't change cpumask_of_node
Impact: bug fix
commit 07c636deede53ff3e96d54df0ece2c838e61951f introduce new CPU mask API and change cpu_mask variable type.
However, its change is incomplete. in build time, compiler output following type mismatch warnings.
arch/ia64/kernel/iosapic.c:708: warning: passing argument 2 of '__cpu_clear' from incompatible pointer type
arch/ia64/kernel/iosapic.c:711: warning: passing argument 1 of '__cpus_weight' from incompatible pointer type
arch/ia64/kernel/iosapic.c:719: warning: passing argument 1 of '__first_cpu' from incompatible pointer type
arch/ia64/kernel/iosapic.c:720: warning: passing argument 2 of '__next_cpu' from incompatible pointer type
More unfortunately, current code change the return value o cpumask_of_node().
but it is unacceptable operation. it cause to corrupt data structure.
Signed-off-by: Mike Travis <travis@sgi.com>
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
CC: "Luck, Tony" <tony.luck@intel.com>
CC: Rusty Russell <rusty@rustcorp.com.au>
---
arch/ia64/kernel/iosapic.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
Index: b/arch/ia64/kernel/iosapic.c
===================================================================
--- a/arch/ia64/kernel/iosapic.c
+++ b/arch/ia64/kernel/iosapic.c
@@ -703,23 +703,23 @@ get_target_cpu (unsigned int gsi, int ir
goto skip_numa_setup;
cpu_mask = cpumask_of_node(iosapic_lists[iosapic_index].node);
+ num_cpus = 0;
for_each_cpu_and(numa_cpu, cpu_mask, &domain) {
- if (!cpu_online(numa_cpu))
- cpu_clear(numa_cpu, cpu_mask);
+ if (cpu_online(numa_cpu))
+ num_cpus++;
}
- num_cpus = cpus_weight(cpu_mask);
-
if (!num_cpus)
goto skip_numa_setup;
/* Use irq assignment to distribute across cpus in node */
cpu_index = irq % num_cpus;
- for (numa_cpu = first_cpu(cpu_mask) ; i < cpu_index ; i++)
- numa_cpu = next_cpu(numa_cpu, cpu_mask);
+ for_each_cpu_and(numa_cpu, cpu_mask, &domain)
+ if (cpu_online(numa_cpu) && i++ >= cpu_index)
+ break;
- if (numa_cpu != NR_CPUS)
+ if (numa_cpu < nr_cpu_ids)
return cpu_physical_id(numa_cpu);
}
skip_numa_setup:
@@ -730,7 +730,7 @@ skip_numa_setup:
* case of NUMA.)
*/
do {
- if (++cpu >= NR_CPUS)
+ if (++cpu >= nr_cpu_ids)
cpu = 0;
} while (!cpu_online(cpu) || !cpu_isset(cpu, domain));
^ permalink raw reply
* Re: [PATCH] cpumask:cpumask_of_node-ia64 fix
From: Mike Travis @ 2008-12-11 4:31 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: Luck, Tony, Rusty Russell, linux-next, LKML, Stephen Rothwell
In-Reply-To: <494093F7.5020000@sgi.com>
Mike Travis wrote:
> KOSAKI Motohiro wrote:
>> ===
>> Subject: [PATCH] cpumask:cpumask_of_node-ia64 fix
>> Impact: bug fix
>>
>> commit 07c636deede53ff3e96d54df0ece2c838e61951f introduce new CPU mask API and change cpu_mask variable type.
>>
>> -----------------------------------------------
>> - cpumask_t cpu_mask;
>> + const struct cpumask *cpu_mask;
>> --------------------------------------------------
>>
>>
>> However, its change is incomplete. in build time, compiler output following type mismatch warnings.
>>
>> arch/ia64/kernel/iosapic.c:708: warning: passing argument 2 of '__cpu_clear' from incompatible pointer type
>> arch/ia64/kernel/iosapic.c:711: warning: passing argument 1 of '__cpus_weight' from incompatible pointer type
>> arch/ia64/kernel/iosapic.c:719: warning: passing argument 1 of '__first_cpu' from incompatible pointer type
>> arch/ia64/kernel/iosapic.c:720: warning: passing argument 2 of '__next_cpu' from incompatible pointer type
>
> Good catch, however ...
>>
>> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>> CC: "Luck, Tony" <tony.luck@intel.com>
>> CC: Rusty Russell <rusty@rustcorp.com.au>
>> ---
>> arch/ia64/kernel/iosapic.c | 10 +++++-----
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> Index: b/arch/ia64/kernel/iosapic.c
>> ===================================================================
>> --- a/arch/ia64/kernel/iosapic.c
>> +++ b/arch/ia64/kernel/iosapic.c
>> @@ -695,7 +695,7 @@ get_target_cpu (unsigned int gsi, int ir
>> #ifdef CONFIG_NUMA
>> {
>> int num_cpus, cpu_index, iosapic_index, numa_cpu, i = 0;
>> - const struct cpumask *cpu_mask;
>> + struct cpumask *cpu_mask;
>>
>> iosapic_index = find_iosapic(gsi);
>> if (iosapic_index < 0 ||
>> @@ -705,10 +705,10 @@ get_target_cpu (unsigned int gsi, int ir
>> cpu_mask = cpumask_of_node(iosapic_lists[iosapic_index].node);
>> for_each_cpu_and(numa_cpu, cpu_mask, &domain) {
>> if (!cpu_online(numa_cpu))
>> - cpu_clear(numa_cpu, cpu_mask);
>> + cpu_clear(numa_cpu, *cpu_mask);
>
> ... you cannot modify the read-only cpumask_of_node map. Suggested alternative below.
>
>> }
>>
>> - num_cpus = cpus_weight(cpu_mask);
>> + num_cpus = cpus_weight(*cpu_mask);
>>
>> if (!num_cpus)
>> goto skip_numa_setup;
>> @@ -716,8 +716,8 @@ get_target_cpu (unsigned int gsi, int ir
>> /* Use irq assignment to distribute across cpus in node */
>> cpu_index = irq % num_cpus;
>>
>> - for (numa_cpu = first_cpu(cpu_mask) ; i < cpu_index ; i++)
>> - numa_cpu = next_cpu(numa_cpu, cpu_mask);
>> + for (numa_cpu = first_cpu(*cpu_mask) ; i < cpu_index ; i++)
>> + numa_cpu = next_cpu(numa_cpu, *cpu_mask);
>>
>> if (numa_cpu != NR_CPUS)
>> return cpu_physical_id(numa_cpu);
>>
>>
>> --
> ---
> arch/ia64/kernel/iosapic.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> --- linux-2.6-next.orig/arch/ia64/kernel/iosapic.c
> +++ linux-2.6-next/arch/ia64/kernel/iosapic.c
> @@ -703,23 +703,23 @@ get_target_cpu (unsigned int gsi, int ir
> goto skip_numa_setup;
>
> cpu_mask = cpumask_of_node(iosapic_lists[iosapic_index].node);
> + num_cpus = 0;
> for_each_cpu_and(numa_cpu, cpu_mask, &domain) {
> - if (!cpu_online(numa_cpu))
> - cpu_clear(numa_cpu, cpu_mask);
> + if (cpu_online(numa_cpu))
> + num_cpus++;
> }
>
> - num_cpus = cpus_weight(cpu_mask);
> -
> if (!num_cpus)
> goto skip_numa_setup;
>
> /* Use irq assignment to distribute across cpus in node */
> cpu_index = irq % num_cpus;
>
> - for (numa_cpu = first_cpu(cpu_mask) ; i < cpu_index ; i++)
> - numa_cpu = next_cpu(numa_cpu, cpu_mask);
> + for_each_cpu_and(numa_cpu, cpu_mask, cpu_online_mask)
> + if (i++ >= cpu_index)
> + break;
Oops, looks like I over-simplified the above...
for_each_cpu_and(numa_cpu, cpu_mask, &domain)
if (cpu_online(numa_cpu) && i++ >= cpu_index)
break;
>
> - if (numa_cpu != NR_CPUS)
> + if (numa_cpu < nr_cpu_ids)
> return cpu_physical_id(numa_cpu);
> }
> skip_numa_setup:
> @@ -730,7 +730,7 @@ skip_numa_setup:
> * case of NUMA.)
> */
> do {
> - if (++cpu >= NR_CPUS)
> + if (++cpu >= nr_cpu_ids)
> cpu = 0;
> } while (!cpu_online(cpu) || !cpu_isset(cpu, domain));
>
> ---
>
> One aside, I'm not sure of ia64, but x86_64 keeps only online cpus in the cpumask_of_node_map.
> IOW, if a cpu goes offline, it's removed from the map. So the whole and'ing thing above may
> be unnecessary.
^ permalink raw reply
* Re: [PATCH] cpumask:cpumask_of_node-ia64 fix
From: Mike Travis @ 2008-12-11 4:15 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: Luck, Tony, Rusty Russell, linux-next, LKML, Stephen Rothwell
In-Reply-To: <20081211105721.4FEE.KOSAKI.MOTOHIRO@jp.fujitsu.com>
KOSAKI Motohiro wrote:
> ===
> Subject: [PATCH] cpumask:cpumask_of_node-ia64 fix
> Impact: bug fix
>
> commit 07c636deede53ff3e96d54df0ece2c838e61951f introduce new CPU mask API and change cpu_mask variable type.
>
> -----------------------------------------------
> - cpumask_t cpu_mask;
> + const struct cpumask *cpu_mask;
> --------------------------------------------------
>
>
> However, its change is incomplete. in build time, compiler output following type mismatch warnings.
>
> arch/ia64/kernel/iosapic.c:708: warning: passing argument 2 of '__cpu_clear' from incompatible pointer type
> arch/ia64/kernel/iosapic.c:711: warning: passing argument 1 of '__cpus_weight' from incompatible pointer type
> arch/ia64/kernel/iosapic.c:719: warning: passing argument 1 of '__first_cpu' from incompatible pointer type
> arch/ia64/kernel/iosapic.c:720: warning: passing argument 2 of '__next_cpu' from incompatible pointer type
Good catch, however ...
>
>
> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> CC: "Luck, Tony" <tony.luck@intel.com>
> CC: Rusty Russell <rusty@rustcorp.com.au>
> ---
> arch/ia64/kernel/iosapic.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> Index: b/arch/ia64/kernel/iosapic.c
> ===================================================================
> --- a/arch/ia64/kernel/iosapic.c
> +++ b/arch/ia64/kernel/iosapic.c
> @@ -695,7 +695,7 @@ get_target_cpu (unsigned int gsi, int ir
> #ifdef CONFIG_NUMA
> {
> int num_cpus, cpu_index, iosapic_index, numa_cpu, i = 0;
> - const struct cpumask *cpu_mask;
> + struct cpumask *cpu_mask;
>
> iosapic_index = find_iosapic(gsi);
> if (iosapic_index < 0 ||
> @@ -705,10 +705,10 @@ get_target_cpu (unsigned int gsi, int ir
> cpu_mask = cpumask_of_node(iosapic_lists[iosapic_index].node);
> for_each_cpu_and(numa_cpu, cpu_mask, &domain) {
> if (!cpu_online(numa_cpu))
> - cpu_clear(numa_cpu, cpu_mask);
> + cpu_clear(numa_cpu, *cpu_mask);
... you cannot modify the read-only cpumask_of_node map. Suggested alternative below.
> }
>
> - num_cpus = cpus_weight(cpu_mask);
> + num_cpus = cpus_weight(*cpu_mask);
>
> if (!num_cpus)
> goto skip_numa_setup;
> @@ -716,8 +716,8 @@ get_target_cpu (unsigned int gsi, int ir
> /* Use irq assignment to distribute across cpus in node */
> cpu_index = irq % num_cpus;
>
> - for (numa_cpu = first_cpu(cpu_mask) ; i < cpu_index ; i++)
> - numa_cpu = next_cpu(numa_cpu, cpu_mask);
> + for (numa_cpu = first_cpu(*cpu_mask) ; i < cpu_index ; i++)
> + numa_cpu = next_cpu(numa_cpu, *cpu_mask);
>
> if (numa_cpu != NR_CPUS)
> return cpu_physical_id(numa_cpu);
>
>
> --
---
arch/ia64/kernel/iosapic.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
--- linux-2.6-next.orig/arch/ia64/kernel/iosapic.c
+++ linux-2.6-next/arch/ia64/kernel/iosapic.c
@@ -703,23 +703,23 @@ get_target_cpu (unsigned int gsi, int ir
goto skip_numa_setup;
cpu_mask = cpumask_of_node(iosapic_lists[iosapic_index].node);
+ num_cpus = 0;
for_each_cpu_and(numa_cpu, cpu_mask, &domain) {
- if (!cpu_online(numa_cpu))
- cpu_clear(numa_cpu, cpu_mask);
+ if (cpu_online(numa_cpu))
+ num_cpus++;
}
- num_cpus = cpus_weight(cpu_mask);
-
if (!num_cpus)
goto skip_numa_setup;
/* Use irq assignment to distribute across cpus in node */
cpu_index = irq % num_cpus;
- for (numa_cpu = first_cpu(cpu_mask) ; i < cpu_index ; i++)
- numa_cpu = next_cpu(numa_cpu, cpu_mask);
+ for_each_cpu_and(numa_cpu, cpu_mask, cpu_online_mask)
+ if (i++ >= cpu_index)
+ break;
- if (numa_cpu != NR_CPUS)
+ if (numa_cpu < nr_cpu_ids)
return cpu_physical_id(numa_cpu);
}
skip_numa_setup:
@@ -730,7 +730,7 @@ skip_numa_setup:
* case of NUMA.)
*/
do {
- if (++cpu >= NR_CPUS)
+ if (++cpu >= nr_cpu_ids)
cpu = 0;
} while (!cpu_online(cpu) || !cpu_isset(cpu, domain));
---
One aside, I'm not sure of ia64, but x86_64 keeps only online cpus in the cpumask_of_node_map.
IOW, if a cpu goes offline, it's removed from the map. So the whole and'ing thing above may
be unnecessary.
^ permalink raw reply
* Re: [linux-next][PATCH] cpumask:cpumask_of_node-ia64 fix
From: KOSAKI Motohiro @ 2008-12-11 4:09 UTC (permalink / raw)
To: linux-ia64
Cc: kosaki.motohiro, Luck, Tony, Rusty Russell, linux-next, LKML,
Stephen Rothwell
In-Reply-To: <20081211105721.4FEE.KOSAKI.MOTOHIRO@jp.fujitsu.com>
Oops, sorry.
I forgot cc to linux-ia64.
> ===
> Subject: [PATCH] cpumask:cpumask_of_node-ia64 fix
> Impact: bug fix
>
> commit 07c636deede53ff3e96d54df0ece2c838e61951f introduce new CPU mask API and change cpu_mask variable type.
>
> -----------------------------------------------
> - cpumask_t cpu_mask;
> + const struct cpumask *cpu_mask;
> --------------------------------------------------
>
>
> However, its change is incomplete. in build time, compiler output following type mismatch warnings.
>
> arch/ia64/kernel/iosapic.c:708: warning: passing argument 2 of '__cpu_clear' from incompatible pointer type
> arch/ia64/kernel/iosapic.c:711: warning: passing argument 1 of '__cpus_weight' from incompatible pointer type
> arch/ia64/kernel/iosapic.c:719: warning: passing argument 1 of '__first_cpu' from incompatible pointer type
> arch/ia64/kernel/iosapic.c:720: warning: passing argument 2 of '__next_cpu' from incompatible pointer type
>
>
> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> CC: "Luck, Tony" <tony.luck@intel.com>
> CC: Rusty Russell <rusty@rustcorp.com.au>
> ---
> arch/ia64/kernel/iosapic.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> Index: b/arch/ia64/kernel/iosapic.c
> ===================================================================
> --- a/arch/ia64/kernel/iosapic.c
> +++ b/arch/ia64/kernel/iosapic.c
> @@ -695,7 +695,7 @@ get_target_cpu (unsigned int gsi, int ir
> #ifdef CONFIG_NUMA
> {
> int num_cpus, cpu_index, iosapic_index, numa_cpu, i = 0;
> - const struct cpumask *cpu_mask;
> + struct cpumask *cpu_mask;
>
> iosapic_index = find_iosapic(gsi);
> if (iosapic_index < 0 ||
> @@ -705,10 +705,10 @@ get_target_cpu (unsigned int gsi, int ir
> cpu_mask = cpumask_of_node(iosapic_lists[iosapic_index].node);
> for_each_cpu_and(numa_cpu, cpu_mask, &domain) {
> if (!cpu_online(numa_cpu))
> - cpu_clear(numa_cpu, cpu_mask);
> + cpu_clear(numa_cpu, *cpu_mask);
> }
>
> - num_cpus = cpus_weight(cpu_mask);
> + num_cpus = cpus_weight(*cpu_mask);
>
> if (!num_cpus)
> goto skip_numa_setup;
> @@ -716,8 +716,8 @@ get_target_cpu (unsigned int gsi, int ir
> /* Use irq assignment to distribute across cpus in node */
> cpu_index = irq % num_cpus;
>
> - for (numa_cpu = first_cpu(cpu_mask) ; i < cpu_index ; i++)
> - numa_cpu = next_cpu(numa_cpu, cpu_mask);
> + for (numa_cpu = first_cpu(*cpu_mask) ; i < cpu_index ; i++)
> + numa_cpu = next_cpu(numa_cpu, *cpu_mask);
>
> if (numa_cpu != NR_CPUS)
> return cpu_physical_id(numa_cpu);
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
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