* [PATCH] clean up of netif_rx_reschedule() changes in drivers
From: Kamalesh Babulal @ 2008-12-29 10:25 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David S. Miller, Neil Horman, linux-next, LKML, Linus, netdev,
ppc-dev
In-Reply-To: <20081229110041.0eca977a.sfr@canb.auug.org.au>
* Stephen Rothwell <sfr@canb.auug.org.au> [2008-12-29 11:00:41]:
> Hi Dave, Neil,
>
> Today's linux-next build (powerpc ppc64_defconfig) failed like this:
>
> drivers/net/ibmveth.c: In function 'ibmveth_poll':
> drivers/net/ibmveth.c:1034: warning: passing argument 1 of 'netif_rx_reschedule' from incompatible pointer type
> drivers/net/ibmveth.c:1034: error: too many arguments to function 'netif_rx_reschedule'
>
> Another miss in commit 908a7a16b852ffd618a9127be8d62432182d81b4 ("net: Remove
> unused netdev arg from some NAPI interfaces").
>
> I have added the following patch for today.
>
> (I wonder how many more there will be? :-()
>
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 29 Dec 2008 10:56:00 +1100
> Subject: [PATCH] net: ibmveth NAPI interface cleanup fix
>
> Commit 908a7a16b852ffd618a9127be8d62432182d81b4 ("net: Remove unused
> netdev arg from some NAPI interfaces") missed one spot.
Hi Stephen,
Thanks, the patch fixes the build failure for me.
Tested-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/net/ibmveth.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ibmveth.c b/drivers/net/ibmveth.c
> index 1f055a9..9bc0f17 100644
> --- a/drivers/net/ibmveth.c
> +++ b/drivers/net/ibmveth.c
> @@ -1031,7 +1031,7 @@ static int ibmveth_poll(struct napi_struct *napi, int budget)
> netif_rx_complete(napi);
>
> if (ibmveth_rxq_pending_buffer(adapter) &&
> - netif_rx_reschedule(netdev, napi)) {
> + netif_rx_reschedule(napi)) {
> lpar_rc = h_vio_signal(adapter->vdev->unit_address,
> VIO_IRQ_DISABLE);
> goto restart_poll;
> --
> 1.6.0.5
I hit similar build failure due to the change in the netif_rx_reschedule()
drivers/net/ehea/ehea_main.c: In function 'ehea_poll':
drivers/net/ehea/ehea_main.c:844: warning: passing argument 1 of 'netif_rx_reschedule' from incompatible pointer type
drivers/net/ehea/ehea_main.c:844: error: too many arguments to function 'netif_rx_reschedule'
make[3]: *** [drivers/net/ehea/ehea_main.o] Error 1
greping through the sources for the changes missed out, we have
./drivers/net/arm/ixp4xx_eth.c:507: netif_rx_reschedule(dev, napi)) {
./drivers/net/arm/ep93xx_eth.c:310: if (more && netif_rx_reschedule(dev, napi))
./drivers/net/wan/ixp4xx_hss.c:657: netif_rx_reschedule(dev, napi)) {
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
--
drivers/net/arm/ep93xx_eth.c | 2 +-
drivers/net/arm/ixp4xx_eth.c | 2 +-
drivers/net/wan/ixp4xx_hss.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/arm/ep93xx_eth.c b/drivers/net/arm/ep93xx_eth.c
index 6ecc600..3ec20cc 100644
--- a/drivers/net/arm/ep93xx_eth.c
+++ b/drivers/net/arm/ep93xx_eth.c
@@ -307,7 +307,7 @@ poll_some_more:
}
spin_unlock_irq(&ep->rx_lock);
- if (more && netif_rx_reschedule(dev, napi))
+ if (more && netif_rx_reschedule(napi))
goto poll_some_more;
}
diff --git a/drivers/net/arm/ixp4xx_eth.c b/drivers/net/arm/ixp4xx_eth.c
index 26af411..5fce1d5 100644
--- a/drivers/net/arm/ixp4xx_eth.c
+++ b/drivers/net/arm/ixp4xx_eth.c
@@ -504,7 +504,7 @@ static int eth_poll(struct napi_struct *napi, int budget)
netif_rx_complete(napi);
qmgr_enable_irq(rxq);
if (!qmgr_stat_empty(rxq) &&
- netif_rx_reschedule(dev, napi)) {
+ netif_rx_reschedule(napi)) {
#if DEBUG_RX
printk(KERN_DEBUG "%s: eth_poll"
" netif_rx_reschedule successed\n",
diff --git a/drivers/net/wan/ixp4xx_hss.c b/drivers/net/wan/ixp4xx_hss.c
index 0c68025..2dc2416 100644
--- a/drivers/net/wan/ixp4xx_hss.c
+++ b/drivers/net/wan/ixp4xx_hss.c
@@ -654,7 +654,7 @@ static int hss_hdlc_poll(struct napi_struct *napi, int budget)
netif_rx_complete(dev, napi);
qmgr_enable_irq(rxq);
if (!qmgr_stat_empty(rxq) &&
- netif_rx_reschedule(dev, napi)) {
+ netif_rx_reschedule(napi)) {
#if DEBUG_RX
printk(KERN_DEBUG "%s: hss_hdlc_poll"
" netif_rx_reschedule succeeded\n",
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply related
* Re: [PATCH] clean up of netif_rx_reschedule() changes in drivers
From: Stephen Rothwell @ 2008-12-29 10:41 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: David S. Miller, Neil Horman, linux-next, LKML, Linus, netdev,
ppc-dev
In-Reply-To: <20081229102509.GA11111@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]
Hi Kamalesh,
On Mon, 29 Dec 2008 15:55:29 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>
> I hit similar build failure due to the change in the netif_rx_reschedule()
>
> drivers/net/ehea/ehea_main.c: In function 'ehea_poll':
> drivers/net/ehea/ehea_main.c:844: warning: passing argument 1 of 'netif_rx_reschedule' from incompatible pointer type
> drivers/net/ehea/ehea_main.c:844: error: too many arguments to function 'netif_rx_reschedule'
> make[3]: *** [drivers/net/ehea/ehea_main.o] Error 1
Linus already took a patch for ibmveth and ehea.
> greping through the sources for the changes missed out, we have
>
.
.
>
> Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
> --
> drivers/net/arm/ep93xx_eth.c | 2 +-
> drivers/net/arm/ixp4xx_eth.c | 2 +-
> drivers/net/wan/ixp4xx_hss.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
Thanks for the patch, I assume that Dave or Linus will take care of that.
--
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 iommu tree
From: Stephen Rothwell @ 2008-12-29 12:04 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linux-next, Arjan van de Ven, Jeremy Fitzhardinge
Hi Ingo,
Today's linux-next merge of the iommu tree got a conflict in
arch/x86/kernel/Makefile between commit
b43d196c4d3fe46d6dda7c987c47792612b80b1b ("x86: corruption-check: some
post-move cleanups") from Linus' tree and commit
cfb80c9eae8c7ed8f2ee81090062d15ead51cbe8 ("x86: unify pci iommu setup and
allow swiotlb to compile for 32 bit") from the iommu tree.
Simply 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 arch/x86/kernel/Makefile
index 3d82c15,a9c656f..0000000
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@@ -108,7 -105,7 +108,8 @@@ microcode-$(CONFIG_MICROCODE_INTEL) +=
microcode-$(CONFIG_MICROCODE_AMD) += microcode_amd.o
obj-$(CONFIG_MICROCODE) += microcode.o
+obj-$(CONFIG_X86_CHECK_BIOS_CORRUPTION) += check.o
+ obj-$(CONFIG_SWIOTLB) += pci-swiotlb_64.o # NB rename without _64
###
# 64 bit specific files
^ permalink raw reply
* linux-next: manual merge of the iommu tree
From: Stephen Rothwell @ 2008-12-29 12:10 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linux-next, Jeremy Fitzhardinge, Arjan van de Ven
Hi Ingo,
Today's linux-next merge of the iommu tree got a conflict in
arch/x86/mm/init_32.c between commit
304e629bf4a3150a0bf6556fc45c52c5c082340f ("x86: corruption check: run the
corruption checks from a work queue") from Linus' tree and commit
cfb80c9eae8c7ed8f2ee81090062d15ead51cbe8 ("x86: unify pci iommu setup and
allow swiotlb to compile for 32 bit") from the iommu tree.
Just overlapping removal/addition. I fixed it up (see below) and can
carry the fix as necessay.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc arch/x86/mm/init_32.c
index bdcbe2c,2b4b14f..0000000
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@@ -969,6 -970,10 +970,8 @@@ void __init mem_init(void
int codesize, reservedpages, datasize, initsize;
int tmp;
- start_periodic_check_for_corruption();
-
+ pci_iommu_alloc();
+
#ifdef CONFIG_FLATMEM
BUG_ON(!mem_map);
#endif
^ permalink raw reply
* Re: linux-next: manual merge of the iommu tree
From: Ingo Molnar @ 2008-12-29 12:15 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, Arjan van de Ven, Jeremy Fitzhardinge
In-Reply-To: <20081229230451.4e322cde.sfr@canb.auug.org.au>
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Ingo,
>
> Today's linux-next merge of the iommu tree got a conflict in
> arch/x86/kernel/Makefile between commit
> b43d196c4d3fe46d6dda7c987c47792612b80b1b ("x86: corruption-check: some
> post-move cleanups") from Linus' tree and commit
> cfb80c9eae8c7ed8f2ee81090062d15ead51cbe8 ("x86: unify pci iommu setup and
> allow swiotlb to compile for 32 bit") from the iommu tree.
>
> Simply overlapping additions. I fixed it up (see below) and can carry
> the fix as necessary.
had a resolution for this cached from tip/master - so i just re-integrated
and re-pushed auto-iommu-next so it should go away next time you pick it
up. Thanks,
Ingo
^ permalink raw reply
* Re: linux-next: manual merge of the iommu tree
From: Stephen Rothwell @ 2008-12-29 12:20 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linux-next, Arjan van de Ven, Jeremy Fitzhardinge
In-Reply-To: <20081229121501.GE9628@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 377 bytes --]
Hi Ingo,
On Mon, 29 Dec 2008 13:15:01 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> had a resolution for this cached from tip/master - so i just re-integrated
> and re-pushed auto-iommu-next so it should go away next time you pick it
> up. Thanks,
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
* linux-next: manual merge of the uwb tree
From: Stephen Rothwell @ 2008-12-29 12:30 UTC (permalink / raw)
To: David Vrabel; +Cc: linux-next, Harvey Harrison, Greg KH
Hi David,
Today's linux-next merge of the uwb tree got a conflict in
drivers/usb/wusbcore/rh.c between commit
96f391057a3c29655b82b90d902f678d901c0eb1 ("USB: wusb: annotate
association types withe proper endianness") from the usb tree and commit
bce83697c5fe84a7a5d38c96fbbe43b4bc028c3e ("uwb: use dev_dbg() for debug
messages") from the uwb 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 drivers/usb/wusbcore/rh.c
index b1bb82d,95c6fa3..0000000
--- a/drivers/usb/wusbcore/rh.c
+++ b/drivers/usb/wusbcore/rh.c
@@@ -351,13 -326,11 +326,11 @@@ static int wusbhc_rh_clear_port_feat(st
static int wusbhc_rh_get_port_status(struct wusbhc *wusbhc, u16 port_idx,
u32 *_buf, u16 wLength)
{
- int result = -EINVAL;
- u16 *buf = (u16 *) _buf;
+ __le16 *buf = (__le16 *)_buf;
- d_fnstart(1, wusbhc->dev, "(wusbhc %p port_idx %u wLength %u)\n",
- wusbhc, port_idx, wLength);
if (port_idx > wusbhc->ports_max)
- goto error;
+ return -EINVAL;
+
mutex_lock(&wusbhc->mutex);
buf[0] = cpu_to_le16(wusb_port_by_idx(wusbhc, port_idx)->status);
buf[1] = cpu_to_le16(wusb_port_by_idx(wusbhc, port_idx)->change);
^ permalink raw reply
* linux-next: manual merge of the uwb tree
From: Stephen Rothwell @ 2008-12-29 12:36 UTC (permalink / raw)
To: David Vrabel; +Cc: linux-next, Harvey Harrison
[-- Attachment #1: Type: text/plain, Size: 558 bytes --]
Hi David,
Today's linux-next merge of the uwb tree got a conflict in
drivers/uwb/wlp/eda.c between commit
a20fd0a783551831bb6b9b69710e5bbb93dc2730 ("uwb: use the %pM formatting
specifier in eda.c") from Linus' tree and commit
bce83697c5fe84a7a5d38c96fbbe43b4bc028c3e ("uwb: use dev_dbg() for debug
messages") from the uwb tree.
The latter removed the some code that the former was modifying. I fixed
it up and can carry the fix for now.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: manual merge of the boot-params tree
From: Stephen Rothwell @ 2008-12-29 14:01 UTC (permalink / raw)
To: Rusty Russell
Cc: linux-next, Alok Kataria, Dan Hecht, H. Peter Anvin, Yinghai Lu
Hi Rusty,
Today's linux-next merge of the boot-params tree got a conflict in
arch/x86/kernel/cpu/common.c between commit
88b094fb8d4fe43b7025ea8d487059e8813e02cd ("x86: Hypervisor detection and
get tsc_freq from hypervisor") from Linus' tree and commit
568991994fb3aad34504e9bdac458a2bfd388c7f ("x86: clean up
setup_clear/force_cpu_cap handling") from the boot-params tree.
Just overlapping additions. I fixed it up (see below) and can carry the
fix for now.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc arch/x86/kernel/cpu/common.c
index 42e0853,63531c9..0000000
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@@ -704,7 -716,9 +717,11 @@@ static void __cpuinit identify_cpu(stru
detect_ht(c);
#endif
+ init_hypervisor(c);
++
+ /* Command-line override before we AND into smp all cpus cap. */
+ override_capabilities(c->x86_capability);
+
/*
* On SMP, boot_cpu_data holds the common feature set between
* all CPUs; so make sure that we indicate which features are
^ permalink raw reply
* linux-next: manual merge of the boot-params tree
From: Stephen Rothwell @ 2008-12-29 14:10 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-next, Greg KH
[-- Attachment #1: Type: text/plain, Size: 712 bytes --]
Hi Rusty,
Today's linux-next merge of the boot-params tree got a conflict in
drivers/usb/core/usb.c between commit
6e7b5429a08fe4f71c336710bd45acdce6cd3df7 ("USB: don't use
__module_param_call") from the usb tree and commit
9634765245cd7aba71328c71813ca882d008632d ("USB: Don't use
__module_param_call; use core_param") from the boot-params tree.
Two different versions of the same change? I fixed it up (used the
boot-params tree version) and can carry the fix as necessary. It sounds
like Greg should drop the patch from the usb tree (or pick up the version
from the boot-params 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: manual merge of the boot-params tree
From: Stephen Rothwell @ 2008-12-29 14:22 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-next, Yinghai Lu, Ingo Molnar
Hi Rusty,
Today's linux-next merge of the boot-params tree got a conflict in
init/main.c between commit 0b8f1efad30bd58f89961b82dfe68b9edf8fd2ac
("sparse irq_desc[] array: core kernel and x86 changes") from the
sparseirq tree and commit 25bf48b74b9fb23b347d00656b604f9e55c72183 ("Fix
powerpc (tested on ppc64) command line handling") from the boot-params
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 init/main.c
index 396b271,ad933ad..0000000
--- a/init/main.c
+++ b/init/main.c
@@@ -543,20 -522,30 +526,40 @@@ void __init __weak thread_info_cache_in
{
}
+int __init __weak arch_early_irq_init(void)
+{
+ return 0;
+}
+
+int __init __weak early_irq_init(void)
+{
+ return arch_early_irq_init();
+}
+
+ /* Non-destructive early parse of commandline. PowerPC calls this early. */
+ void __init parse_early_and_core_params(char *cmdline)
+ {
+ static bool __initdata done = false;
+
+ if (done)
+ return;
+
+ parse_args("Core and early params", cmdline,
+ __start___core_param,
+ __stop___core_param - __start___core_param,
+ do_early_param, true);
+ done = true;
+ }
+
asmlinkage void __init start_kernel(void)
{
- char * command_line;
- extern struct kernel_param __start___param[], __stop___param[];
+ char *static_command_line;
+
+ printk(KERN_NOTICE);
+ printk(linux_banner);
+
+ arch_get_boot_command_line();
+ parse_early_and_core_params(boot_command_line);
smp_setup_processor_id();
^ permalink raw reply
* Re: Pull request for FS-Cache, including NFS patches
From: David Howells @ 2008-12-29 14:26 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Bernd Schubert, nfsv4, linux-kernel, steved, dhowells, linux-next,
linux-fsdevel, Andrew Morton, rwheeler
In-Reply-To: <20081229144533.4a0ab696.sfr@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> What was the result of discussions around FS-Cache? I ask because it
> reappeared in linux-next today via the nfs tree (merged into that on Dec
> 24 and 25) ...
That is the result of discussions during the kernel summit in Portland. The
discussion here is about whether Andrew agrees with adding the patches or not,
as far as I can tell. There are a number of people/companies who want them;
there is Andrew who does not.
David
^ permalink raw reply
* Re: Pull request for FS-Cache, including NFS patches
From: Trond Myklebust @ 2008-12-29 14:30 UTC (permalink / raw)
To: Andrew Morton
Cc: Stephen Rothwell, Bernd Schubert, nfsv4, linux-kernel, steved,
dhowells, linux-next, linux-fsdevel, rwheeler
In-Reply-To: <20081228200134.426bf203.akpm@linux-foundation.org>
On Sun, 2008-12-28 at 20:01 -0800, Andrew Morton wrote:
> On Mon, 29 Dec 2008 14:45:33 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi David,
> >
> > On Fri, 19 Dec 2008 11:05:39 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > Given the ongoing discussions around FS-Cache, I have removed it from
> > > linux-next. Please ask me to include it again (if sensible) once some
> > > decision has been reached about its future.
> >
> > What was the result of discussions around FS-Cache?
>
> There was none.
>
> Dan Muntz's question:
>
> Solaris has had CacheFS since ~1995, HPUX had a port of it since
> ~1997. I'd be interested in evidence of even a small fraction of
> Solaris and/or HPUX shops using CacheFS. I am aware of customers who
> thought it sounded like a good idea, but ended up ditching it for
> various reasons (e.g., CacheFS just adds overhead if you almost
> always hit your local mem cache).
>
> was an very very good one.
>
> Seems that instead of answering it, we've decided to investigate the
> fate of those who do not learn from history.
David has given you plenty of arguments for why it helps scale the
server (including specific workloads), has given you numbers validating
his claim, and has presented claims that Red Hat has customers using
cachefs in RHEL-5.
The arguments I've seen against it, have so far been:
1. Solaris couldn't sell their implementation
2. It's too big
3. It's intrusive
Argument (1) has so far appeared to be pure FUD. In order to discuss the
lessons of history, you need to first do the work of analysing and
understanding it first. I really don't see how it is relevant to Linux
whether or not the Solaris and HPUX cachefs implementations worked out
unless you can demonstrate that that their experience shows some fatal
flaw in the arguments and numbers that David presented, and that his
customers are deluded.
If you want examples of permanent caches that clearly do help servers
scale, then look no further than the on-disk caches used in almost all
http browser implemantations. Alternatively, as David mentioned, there
are the on-disk caches used by AFS/DFS/coda.
(2) may be valid, but I have yet to see specifics for where you'd like
to see the cachefs code slimmed down. Did I miss them?
(3) was certainly true 3 years ago, when the code was first presented
for review, and so we did a review and critique then. The NFS specific
changes have improved greatly as a result, and as far as I know, the
security folks are happy too. If you're not happy with the parts that
affect the memory management code then, again, it would be useful to see
specifics that what you want changed.
If there is still controversy concerning this, then I can temporarily
remove cachefs from the nfs linux-next branch, but I'm definitely
keeping it in the linux-mm branch until someone gives me a reason for
why it shouldn't be merged in its current state.
Trond
^ permalink raw reply
* Re: Pull request for FS-Cache, including NFS patches
From: Ric Wheeler @ 2008-12-29 14:54 UTC (permalink / raw)
To: Trond Myklebust
Cc: Stephen Rothwell, Bernd Schubert, nfsv4, linux-kernel, steved,
dhowells, linux-next, linux-fsdevel, Andrew Morton
In-Reply-To: <1230561056.7046.47.camel@heimdal.trondhjem.org>
Trond Myklebust wrote:
> On Sun, 2008-12-28 at 20:01 -0800, Andrew Morton wrote:
>
>> On Mon, 29 Dec 2008 14:45:33 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>>
>>> Hi David,
>>>
>>> On Fri, 19 Dec 2008 11:05:39 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>
>>>> Given the ongoing discussions around FS-Cache, I have removed it from
>>>> linux-next. Please ask me to include it again (if sensible) once some
>>>> decision has been reached about its future.
>>>>
>>> What was the result of discussions around FS-Cache?
>>>
>> There was none.
>>
>> Dan Muntz's question:
>>
>> Solaris has had CacheFS since ~1995, HPUX had a port of it since
>> ~1997. I'd be interested in evidence of even a small fraction of
>> Solaris and/or HPUX shops using CacheFS. I am aware of customers who
>> thought it sounded like a good idea, but ended up ditching it for
>> various reasons (e.g., CacheFS just adds overhead if you almost
>> always hit your local mem cache).
>>
>> was an very very good one.
>>
>> Seems that instead of answering it, we've decided to investigate the
>> fate of those who do not learn from history.
>>
>
> David has given you plenty of arguments for why it helps scale the
> server (including specific workloads), has given you numbers validating
> his claim, and has presented claims that Red Hat has customers using
> cachefs in RHEL-5.
> The arguments I've seen against it, have so far been:
>
> 1. Solaris couldn't sell their implementation
> 2. It's too big
> 3. It's intrusive
>
> Argument (1) has so far appeared to be pure FUD. In order to discuss the
> lessons of history, you need to first do the work of analysing and
> understanding it first. I really don't see how it is relevant to Linux
> whether or not the Solaris and HPUX cachefs implementations worked out
> unless you can demonstrate that that their experience shows some fatal
> flaw in the arguments and numbers that David presented, and that his
> customers are deluded.
> If you want examples of permanent caches that clearly do help servers
> scale, then look no further than the on-disk caches used in almost all
> http browser implemantations. Alternatively, as David mentioned, there
> are the on-disk caches used by AFS/DFS/coda.
>
I can add that our Red Hat customers who tried the cachefs preview did
find it useful for their workloads (and, by the way, also use the
Solaris cachefs on solaris boxes if I remember correctly). They have
been nagging me and others at Red Hat about getting it into supported
state for quite a while :-)
As you point out, this is all about getting more clients to be driven by
a set of NFS servers.
Regards,
Ric
> (2) may be valid, but I have yet to see specifics for where you'd like
> to see the cachefs code slimmed down. Did I miss them?
>
> (3) was certainly true 3 years ago, when the code was first presented
> for review, and so we did a review and critique then. The NFS specific
> changes have improved greatly as a result, and as far as I know, the
> security folks are happy too. If you're not happy with the parts that
> affect the memory management code then, again, it would be useful to see
> specifics that what you want changed.
>
> If there is still controversy concerning this, then I can temporarily
> remove cachefs from the nfs linux-next branch, but I'm definitely
> keeping it in the linux-mm branch until someone gives me a reason for
> why it shouldn't be merged in its current state.
>
> Trond
>
>
^ permalink raw reply
* Re: Pull request for FS-Cache, including NFS patches
From: David Howells @ 2008-12-29 15:01 UTC (permalink / raw)
To: Andrew Morton
Cc: Stephen Rothwell, Bernd Schubert, nfsv4, linux-kernel, steved,
dhowells, linux-next, linux-fsdevel, rwheeler
In-Reply-To: <20081228200134.426bf203.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> wrote:
> > What was the result of discussions around FS-Cache?
>
> There was none.
I disagree with your assertion that there was no result. Various people,
beside myself, have weighed in with situations where FS-Cache is or may be
useful. You've been presented with benchmarks showing that it can make a
difference.
However, *you* are the antagonist, as strictly defined in the dictionary; we
were trying to convince *you*, so a result has to come from *you*. I feel
that you are completely against it and that we've no hope of shifting you.
> Dan Muntz's question:
>
> Solaris has had CacheFS since ~1995, HPUX had a port of it since
> ~1997. I'd be interested in evidence of even a small fraction of
> Solaris and/or HPUX shops using CacheFS. I am aware of customers who
> thought it sounded like a good idea, but ended up ditching it for
> various reasons (e.g., CacheFS just adds overhead if you almost
> always hit your local mem cache).
>
> was an very very good one.
And to a large extent irrelevant. Yes, we know caching adds overhead; I've
never tried to pretend otherwise. It's an exercise in compromise. You don't
just go and slap a cache on everything. There *are* situations in which a
cache will help. We have customers who know about them and are willing to
live with the overhead.
What I have done is to ensure that, even if caching is compiled in, then the
overhead is minimal if there is _no_ cache present. That is requirement #1 on
my list.
Assuming I understand what he said correctly, I've avoided the main issue
listed by Dan because I don't do as Solaris does and interpolate the cache
between the user and NFS. Of course, that probably buys me other issues (FS
design is an exercise in compromise too).
> Seems that instead of answering it, we've decided to investigate the
> fate of those who do not learn from history.
Sigh.
The main point is that caching _is_ useful, even with its drawbacks. Dan may
be aware of customers of Sun/HP who thought caching sounds like a good idea,
but then ended up ditching it. I can well believe it. But I am also aware of
customers of Red Hat who are actively using the caching we put in RHEL-5 and
customers who really want caching available in future RHEL and Fedora versions
for various reasons.
To sum up:
(1) Overhead is minimal if there is no cache.
(2) Benchmarks show that the cache can be effective.
(3) People are already using it and finding it useful.
(4) There are people who want it for various projects.
(5) The use of a cache does not automatically buy you an improvement in
performance: it's a matter of compromise.
(6) The performance improvement may be in the network or the servers, not the
client that is actually doing the caching.
David
^ permalink raw reply
* Re: Pull request for FS-Cache, including NFS patches
From: David Howells @ 2008-12-29 15:04 UTC (permalink / raw)
To: Andrew Morton
Cc: dhowells, Stephen Rothwell, Bernd Schubert, nfsv4, hch,
linux-kernel, steved, linux-fsdevel, rwheeler, linux-next,
Trond Myklebust
In-Reply-To: <20081228200726.7b7078b4.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> wrote:
> And that of course means that many many 2.6.28 patches which I am
> maintaining will need significant rework to apply on top of linux-next,
> and then they won't apply to mainline. Or that linux-next will not apply
> on top of those patches. Mainly memory management.
Significant rework to many many patches? The FS-Cache patches don't have all
that much impact outside of their own directories, AFS and NFS.
> Please drop the NFS tree until after -rc1.
>
> Guys, this: http://lkml.org/lkml/2008/12/27/173
Okay, that's a reasonable request.
David
^ permalink raw reply
* Re: linux-next: rr tree build failure
From: Mike Travis @ 2008-12-29 15:23 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Rusty Russell, linux-next, Ingo Molnar
In-Reply-To: <20081229191253.6c04bf3e.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> Hi Rusty,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> In file included from include/linux/smp.h:33,
> from include/linux/topology.h:33,
> from include/linux/mmzone.h:763,
> from include/linux/gfp.h:4,
> from include/linux/kmod.h:22,
> from include/linux/module.h:13,
> from include/linux/crypto.h:21,
> from arch/x86/kernel/asm-offsets_64.c:7,
> from arch/x86/kernel/asm-offsets.c:4:
> arch/x86/include/asm/smp.h: In function 'num_booting_cpus':
> arch/x86/include/asm/smp.h:152: error: implicit declaration of function 'cpus_weight'
>
> I have dropped the rr tree for today.
>
Hi Stephen,
I have this fixed in:
commit 3b656ce6c3d7ea2a36c1ebe77d436d5550980baa
Author: Mike Travis <travis@sgi.com>
Date: Sat Dec 27 01:45:56 2008 -0800
x86: cleanup remaining cpumask_t ops in smpboot code
which was pushed via tip/cpus4096. It includes many other
updates so I'm not exactly sure how this merges into
linux-next.
Thanks,
Mike
^ permalink raw reply
* Re: [PATCH] clean up of netif_rx_reschedule() changes in drivers
From: Neil Horman @ 2008-12-29 15:37 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Kamalesh Babulal, David S. Miller, linux-next, LKML, Linus,
netdev, ppc-dev
In-Reply-To: <20081229214144.43be8c1d.sfr@canb.auug.org.au>
On Mon, Dec 29, 2008 at 09:41:44PM +1100, Stephen Rothwell wrote:
> Hi Kamalesh,
>
> On Mon, 29 Dec 2008 15:55:29 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> >
> > I hit similar build failure due to the change in the netif_rx_reschedule()
> >
> > drivers/net/ehea/ehea_main.c: In function 'ehea_poll':
> > drivers/net/ehea/ehea_main.c:844: warning: passing argument 1 of 'netif_rx_reschedule' from incompatible pointer type
> > drivers/net/ehea/ehea_main.c:844: error: too many arguments to function 'netif_rx_reschedule'
> > make[3]: *** [drivers/net/ehea/ehea_main.o] Error 1
>
> Linus already took a patch for ibmveth and ehea.
>
> > greping through the sources for the changes missed out, we have
> >
> .
> .
> >
> > Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
> > --
> > drivers/net/arm/ep93xx_eth.c | 2 +-
> > drivers/net/arm/ixp4xx_eth.c | 2 +-
> > drivers/net/wan/ixp4xx_hss.c | 2 +-
> > 3 files changed, 3 insertions(+), 3 deletions(-)
>
> Thanks for the patch, I assume that Dave or Linus will take care of that.
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
Thanks guys, not sure how my patch missed that. I did an allmodconfig build
that passed successfully. Thanks!
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* linux-next: rr_cpumask tree build failure
From: Stephen Rothwell @ 2008-12-29 15:55 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-next, Mike Travis
[-- Attachment #1: Type: text/plain, Size: 608 bytes --]
Hi Rusty,
Today's linux-next build (powerpc allnoconfig) failed like this:
drivers/base/cpu.c: In function 'print_cpus_kernel_max':
drivers/base/cpu.c:136: error: 'CONFIG_NR_CPUS' undeclared (first use in this function)
Caused by commit e057d7aea9d8f2a46cd440d8bfb72245d4e72d79 ("cpumask: add
sysfs displays for configured and disabled cpu maps") from the rr_cpumask
tree. Powerpc (at least) does not define CONFIG_NR_CPUS for a non SMP
build.
I have reverted that commit 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
* [ofa-general] Re: linux-next: origin tree build failure
From: Roland Dreier @ 2008-12-29 16:13 UTC (permalink / raw)
To: Aleksey Senin
Cc: Stephen Rothwell, linux-next, Linus, LKML,
general@lists.openfabrics.org
In-Reply-To: <1230544737.4261.33.camel@alst60>
> After another investigation of this problem, I think that proposed
> solution is #ifdef as good for a first stage. IPv6 support is mandatory
> when we are talking about running linux in some organization. But, of
> course, the way how it implemented in IB stack should be changed. So on
> the second stage, I'd like drop out these "defines" and at the time of
> module initialization obtain addresses of IPv6 functions and in the case
> if they are present at the runtime, call them. It should be nice
> solution for RMDA_CM and IPoIB modules.
I don't think this second stage sounds like a good idea. Suppose
someone loads the RDMA CM first, so it doesn't find the ipv6 functions,
and then later loads and configures ipv6. You'll end up in a situation
where trying to make an IPv6 connection fails spuriously. (And just the
ugliness of looking up function pointers isn't very nice either)
- R.
^ permalink raw reply
* linux-next: Tree for December 29
From: Stephen Rothwell @ 2008-12-29 16:16 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 11113 bytes --]
Hi all,
Changes since 20081219:
Undropped tree:
scci
mtd
Dropped trees (temporarily):
nfs (akpm request due to 2.6.30 features)
kvm (build problem)
rr (build poblem)
semaphore-removal (due to unfixed conflicts against Linus' tree)
cpu_alloc (build problem)
audit (difficult conflicts)
Linus' tree had three build failures requiring patches and one requiring
a revert.
The timers tree gained a conflict against the cpus4096 tree and a build
failure requiring a merge fixup.
The nfs tree was dropped at Andrew Morton's request.
The kvm tree gained a conflict against the powerpc tree and a build
failure is still present so it was dropped.
The net tree lost all its conflicts.
The rr_cpumask tree gained a build failure that required a commit to be
reverted.
The rr tree lost a conflict, but gained a conflict against each of the
cpus4096 tree and Linus' tree and a build failure so it was dropped.
The cifs tree lost its conflicts.
The security-testing tree lost its conflicts.
The iommu tree gained 2 conflicts against Linus' tree.
The uwb tree gained a conflict against each of the usb tree and Linus'
tree.
The boot-params tree gained a conflict against each of Linus' tree, the
usb tree and the sparseirq tree.
----------------------------------------------------------------------------
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
http://www.canb.auug.org.au/~sfr/
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging kbuild-current/master
Merging quilt/driver-core.current
Merging quilt/usb.current
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
CONFLICT (content): Merge conflict in drivers/char/tty_audit.c
Merging dwmw2/master
Applying: cifs: update for new IP4/6 address printing
Applying: net: ehea NAPI interface cleanup fix
Applying: net: ibmveth NAPI interface cleanup fix
Created commit e47e584: Revert "RDMA/addr: Add support for translating IPv6 addresses"
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
CONFLICT (content): Merge conflict in drivers/char/Makefile
Merging 4xx/next
Merging galak/next
Merging pxa/for-next
Merging s390/features
Merging sh/master
Merging sparc/master
CONFLICT (delete/modify): arch/sparc64/kernel/idprom.c deleted in sparc/master and modified in HEAD. Version HEAD of arch/sparc64/kernel/idprom.c left in tree.
$ git rm -f arch/sparc64/kernel/idprom.c
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
CONFLICT (content): Merge conflict in Documentation/DocBook/networking.tmpl
CONFLICT (content): Merge conflict in Documentation/DocBook/networking.tmpl
mark the corrected paths with 'git add <paths>' or 'git rm <paths>' and commit the result.
Created commit dd1bc42: Revert "wimax: Makefile, Kconfig and docbook linkage for the stack"
Merging tip-core/auto-core-next
CONFLICT (content): Merge conflict in include/linux/hardirq.h
Merging cpus4096/auto-cpus4096-next
Merging ftrace/auto-ftrace-next
Merging genirq/auto-genirq-next
Merging safe-poison-pointers/auto-safe-poison-pointers-next
Merging sched/auto-sched-next
Merging stackprotector/auto-stackprotector-next
Merging timers/auto-timers-next
CONFLICT (content): Merge conflict in kernel/time/tick-sched.c
CONFLICT (content): Merge conflict in sound/drivers/pcsp/pcsp.c
Applying: sound: fixup for timers tree interaction
Merging pci/linux-next
Merging quilt/device-mapper
CONFLICT (content): Merge conflict in drivers/md/dm.c
Merging hid/for-next
Merging quilt/i2c
Merging quilt/jdelvare-hwmon
Merging quilt/kernel-doc
Merging v4l-dvb/master
Merging jfs/next
Merging kbuild/master
Merging quilt/ide
Merging libata/NEXT
Merging xfs/master
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 infiniband/for-next
Merging acpi/test
Merging nfsd/nfsd-next
CONFLICT (content): Merge conflict in fs/lockd/host.c
CONFLICT (content): Merge conflict in fs/lockd/mon.c
Merging ieee1394/for-next
Merging ubi/linux-next
Merging kvm/master
CONFLICT (content): Merge conflict in arch/powerpc/kvm/powerpc.c
CONFLICT (content): Merge conflict in arch/x86/kernel/reboot.c
$ git reset --hard HEAD^
Merging dlm/next
Merging scsi/master
Merging ocfs2/linux-next
CONFLICT (content): Merge conflict in fs/ocfs2/namei.c
Merging ext4/next
Merging async_tx/next
Applying: net: async_tx merge fix
Merging udf/for_next
Merging net/master
Merging mtd/master
CONFLICT (content): Merge conflict in arch/arm/mach-pxa/corgi.c
CONFLICT (content): Merge conflict in arch/arm/mach-pxa/poodle.c
CONFLICT (content): Merge conflict in arch/arm/mach-pxa/spitz.c
CONFLICT (content): Merge conflict in drivers/mtd/devices/m25p80.c
CONFLICT (content): Merge conflict in drivers/mtd/devices/mtd_dataflash.c
Merging wireless/master
Merging crypto/master
Merging vfs/for-next
Merging sound/for-next
Merging cpufreq/next
Merging v9fs/for-next
Merging rr_cpumask/master
CONFLICT (content): Merge conflict in kernel/sched.c
Merging quilt/rr
CONFLICT (content): Merge conflict in drivers/virtio/virtio_pci.c
CONFLICT (content): Merge conflict in kernel/rcuclassic.c
CONFLICT (content): Merge conflict in kernel/workqueue.c
$ git reset --hard HEAD^
Merging cifs/master
Merging mmc/next
Merging gfs2/master
Merging input/next
Merging semaphore/semaphore
Merging bkl-removal/bkl-removal
CONFLICT (content): Merge conflict in fs/ioctl.c
Merging ubifs/linux-next
Merging lsm/for-next
Merging block/for-next
CONFLICT (content): Merge conflict in fs/bio.c
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
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
CONFLICT (content): Merge conflict in arch/x86/kernel/Makefile
CONFLICT (content): Merge conflict in arch/x86/mm/init_32.c
Merging uwb/for-upstream
CONFLICT (content): Merge conflict in drivers/usb/wusbcore/rh.c
CONFLICT (content): Merge conflict in drivers/uwb/wlp/eda.c
Merging watchdog/master
Merging proc/proc
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
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 boot-params/master
CONFLICT (content): Merge conflict in arch/arm/kernel/setup.c
CONFLICT (content): Merge conflict in arch/parisc/kernel/setup.c
CONFLICT (content): Merge conflict in arch/sh/boards/mach-microdev/setup.c
CONFLICT (content): Merge conflict in arch/sh/boards/mach-migor/setup.c
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/common.c
CONFLICT (content): Merge conflict in drivers/usb/core/usb.c
CONFLICT (content): Merge conflict in init/main.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
Merging scsi-post-merge/master
Applying: driver core: fix root_device_register for not CONFIG_MODULES
Created commit 257d8bc: Revert "cpumask: add sysfs displays for configured and disabled cpu maps"
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: rr_cpumask tree build failure
From: Mike Travis @ 2008-12-29 16:31 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Rusty Russell, linux-next, Ingo Molnar
In-Reply-To: <20081230025557.89d2565e.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> Hi Rusty,
>
> Today's linux-next build (powerpc allnoconfig) failed like this:
>
> drivers/base/cpu.c: In function 'print_cpus_kernel_max':
> drivers/base/cpu.c:136: error: 'CONFIG_NR_CPUS' undeclared (first use in this function)
>
> Caused by commit e057d7aea9d8f2a46cd440d8bfb72245d4e72d79 ("cpumask: add
> sysfs displays for configured and disabled cpu maps") from the rr_cpumask
> tree. Powerpc (at least) does not define CONFIG_NR_CPUS for a non SMP
> build.
>
> I have reverted that commit for today.
Hi Stephen,
This was my fault. I thought that:
cpumask: make CONFIG_NR_CPUS always valid.
From: Rusty Russell <rusty@rustcorp.com.au>
was already present upstream. This would be the better fix, but as a short
term fix, you can use the following patch.
Thanks,
Mike
---
drivers/base/cpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6-for-ingo.orig/drivers/base/cpu.c
+++ linux-2.6-for-ingo/drivers/base/cpu.c
@@ -133,7 +133,7 @@ print_cpus_func(present);
*/
static ssize_t print_cpus_kernel_max(struct sysdev_class *class, char *buf)
{
- int n = snprintf(buf, PAGE_SIZE-2, "%d\n", CONFIG_NR_CPUS - 1);
+ int n = snprintf(buf, PAGE_SIZE-2, "%d\n", NR_CPUS - 1);
return n;
}
static SYSDEV_CLASS_ATTR(kernel_max, 0444, print_cpus_kernel_max, NULL);
^ permalink raw reply
* [ofa-general] Re: linux-next: origin tree build failure
From: Aleksey Senin @ 2008-12-29 16:52 UTC (permalink / raw)
To: Roland Dreier
Cc: Stephen Rothwell, linux-next, Linus, LKML,
general@lists.openfabrics.org
In-Reply-To: <adavdt3t0wf.fsf@cisco.com>
I thought about this.It can be solved by loading ipv6 module before
RDMA_CM by specifying modules dependencies in modprobe.conf file. At
least this solution helps in the the case when administrator want IB,
but not IPv6.
On Mon, 2008-12-29 at 08:13 -0800, Roland Dreier wrote:
> > After another investigation of this problem, I think that proposed
> > solution is #ifdef as good for a first stage. IPv6 support is mandatory
> > when we are talking about running linux in some organization. But, of
> > course, the way how it implemented in IB stack should be changed. So on
> > the second stage, I'd like drop out these "defines" and at the time of
> > module initialization obtain addresses of IPv6 functions and in the case
> > if they are present at the runtime, call them. It should be nice
> > solution for RMDA_CM and IPoIB modules.
>
> I don't think this second stage sounds like a good idea. Suppose
> someone loads the RDMA CM first, so it doesn't find the ipv6 functions,
> and then later loads and configures ipv6. You'll end up in a situation
> where trying to make an IPv6 connection fails spuriously. (And just the
> ugliness of looking up function pointers isn't very nice either)
>
> - R.
^ permalink raw reply
* [ofa-general] Re: linux-next: origin tree build failure
From: Roland Dreier @ 2008-12-29 20:18 UTC (permalink / raw)
To: Aleksey Senin
Cc: Stephen Rothwell, linux-next, Linus, LKML,
general@lists.openfabrics.org
In-Reply-To: <1230544737.4261.33.camel@alst60>
Something like the following maybe? (This turns off the RDMA CM if
INFINIBAND=y and IPV6=m -- another possibility would be to just turn off
RDMA CM IPv6 support in the case that IB is build-in but IPv6 is
modular, but that seems like a worse idea overall)
diff --git a/drivers/infiniband/Kconfig b/drivers/infiniband/Kconfig
index a5dc78a..538a0ba 100644
--- a/drivers/infiniband/Kconfig
+++ b/drivers/infiniband/Kconfig
@@ -36,7 +36,7 @@ config INFINIBAND_USER_MEM
config INFINIBAND_ADDR_TRANS
bool
- depends on INET
+ depends on INET && !(INFINIBAND = y && IPV6 = m)
default y
source "drivers/infiniband/hw/mthca/Kconfig"
diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
index d98b05b..ec7abb5 100644
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -128,6 +128,7 @@ int rdma_translate_ip(struct sockaddr *addr, struct rdma_dev_addr *dev_addr)
ret = rdma_copy_addr(dev_addr, dev, NULL);
dev_put(dev);
break;
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
case AF_INET6:
for_each_netdev(&init_net, dev) {
if (ipv6_chk_addr(&init_net,
@@ -138,6 +139,7 @@ int rdma_translate_ip(struct sockaddr *addr, struct rdma_dev_addr *dev_addr)
}
}
break;
+#endif
default:
break;
}
@@ -179,10 +181,11 @@ static void addr_send_arp(struct sockaddr *dst_in)
{
struct rtable *rt;
struct flowi fl;
- struct dst_entry *dst;
memset(&fl, 0, sizeof fl);
- if (dst_in->sa_family == AF_INET) {
+
+ switch (dst_in->sa_family) {
+ case AF_INET:
fl.nl_u.ip4_u.daddr =
((struct sockaddr_in *) dst_in)->sin_addr.s_addr;
@@ -191,8 +194,13 @@ static void addr_send_arp(struct sockaddr *dst_in)
neigh_event_send(rt->u.dst.neighbour, NULL);
ip_rt_put(rt);
+ break;
+
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+ case AF_INET6:
+ {
+ struct dst_entry *dst;
- } else {
fl.nl_u.ip6_u.daddr =
((struct sockaddr_in6 *) dst_in)->sin6_addr;
@@ -202,6 +210,9 @@ static void addr_send_arp(struct sockaddr *dst_in)
neigh_event_send(dst->neighbour, NULL);
dst_release(dst);
+ break;
+ }
+#endif
}
}
@@ -254,6 +265,7 @@ out:
return ret;
}
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
static int addr6_resolve_remote(struct sockaddr_in6 *src_in,
struct sockaddr_in6 *dst_in,
struct rdma_dev_addr *addr)
@@ -282,6 +294,14 @@ static int addr6_resolve_remote(struct sockaddr_in6 *src_in,
dst_release(dst);
return ret;
}
+#else
+static int addr6_resolve_remote(struct sockaddr_in6 *src_in,
+ struct sockaddr_in6 *dst_in,
+ struct rdma_dev_addr *addr)
+{
+ return -EADDRNOTAVAIL;
+}
+#endif
static int addr_resolve_remote(struct sockaddr *src_in,
struct sockaddr *dst_in,
@@ -340,7 +360,9 @@ static int addr_resolve_local(struct sockaddr *src_in,
struct net_device *dev;
int ret;
- if (dst_in->sa_family == AF_INET) {
+ switch (dst_in->sa_family) {
+ case AF_INET:
+ {
__be32 src_ip = ((struct sockaddr_in *) src_in)->sin_addr.s_addr;
__be32 dst_ip = ((struct sockaddr_in *) dst_in)->sin_addr.s_addr;
@@ -362,7 +384,12 @@ static int addr_resolve_local(struct sockaddr *src_in,
memcpy(addr->dst_dev_addr, dev->dev_addr, MAX_ADDR_LEN);
}
dev_put(dev);
- } else {
+ break;
+ }
+
+#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
+ case AF_INET6:
+ {
struct in6_addr *a;
for_each_netdev(&init_net, dev)
@@ -390,6 +417,13 @@ static int addr_resolve_local(struct sockaddr *src_in,
if (!ret)
memcpy(addr->dst_dev_addr, dev->dev_addr, MAX_ADDR_LEN);
}
+ break;
+ }
+#endif
+
+ default:
+ ret = -EADDRNOTAVAIL;
+ break;
}
return ret;
^ permalink raw reply related
* Re: linux-next: Tree for December 29 (fcoe)
From: Randy Dunlap @ 2008-12-29 20:31 UTC (permalink / raw)
To: Stephen Rothwell, scsi; +Cc: linux-next, LKML
In-Reply-To: <20081230031621.60acd90b.sfr@canb.auug.org.au>
On Tue, 30 Dec 2008 03:16:21 +1100 Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20081219:
>
> Undropped tree:
> scci
> mtd
>
> Dropped trees (temporarily):
> nfs (akpm request due to 2.6.30 features)
> kvm (build problem)
> rr (build poblem)
> semaphore-removal (due to unfixed conflicts against Linus' tree)
> cpu_alloc (build problem)
> audit (difficult conflicts)
>
> Linus' tree had three build failures requiring patches and one requiring
> a revert.
linux-next-20081229/drivers/scsi/fcoe/libfcoe.c:995: error: dereferencing pointer to incomplete type
linux-next-20081229/drivers/scsi/fcoe/libfcoe.c:1015: error: dereferencing pointer to incomplete type
(on netdev->name ?)
Also, libfoce.c has 2 printk's that say "foce:" instead of "fcoe:"...
---
~Randy
^ 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