2008-07-01 15:14:50

by Stephen Rothwell

[permalink] [raw]
Subject: inux-next: Tree for July 1

Hi all,

Changes since next-20080630:

New tree: ttydev - unfortunately it had to be reverted because of build
failures after lots of conflict resolution (which may have caused the
build failures).

Changed tree: the cris tree changed branch names.

The sched tree gained a couple of conflicts against the ftrace and
cpus4096 trees.

The pci tree gained a conflict against the x86 tree.

The usb tree reverted due to a build failure after merging with the pci
tree was changed for a fixup patch.

The v4l-dvb tree lost its three conflicts against Linus' tree.

The s390 tree gained a conflict against the diver-core tree.

The ide tree fixed its build problems.

The nfsd tree lost a conflict against the nfs tree.

The powerpc tree gained a conflict against the ide tree.

The net tree gained two conflicts against the powerpc tree.

The galak tree lost its conflict against the net tree.

the blk-removal tree gained a conflict against the s390 tree.

The firmware tree lost several conflicts against the net tree so didn't
need a commit reverted any more.

Merging the ttydev tree got several conflicts against the usb and
firmware trees. Unfortunately, it also would not build and so was
reverted.

I have also applied the following patches for know problems:
module: fix NULL pointer dereference in find_symbol()

----------------------------------------------------------------------------

I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
(patches at
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups, it is also built with powerpc allnoconfig,
44x_defconfig and allyesconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

We are up to 99 trees (counting Linus' and 14 trees of patches pending for
Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Jan Dittmer for adding the linux-next tree to his build tests
at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy
Dunlap for doing many randconfig builds.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.

--
Cheers,
Stephen Rothwell [email protected]

$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging powerpc-merge/merge
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sparc-current/master
Merging sound-current/for-linus
Merging arm-current/master
Merging pci-current/for-linus
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 quilt/driver-core
Merging quilt/usb
Merging tip-core/auto-core-next
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
CONFLICT (content): Merge conflict in kernel/Makefile
CONFLICT (content): Merge conflict in kernel/sched.c
CONFLICT (content): Merge conflict in kernel/sched_rt.c
Applying sched: fix rculist split fallout
Merging stackprotector/auto-stackprotector-next
Merging timers/auto-timers-next
Merging x86/auto-x86-next
CONFLICT (content): Merge conflict in arch/x86/kernel/entry_32.S
CONFLICT (content): Merge conflict in arch/x86/kernel/process_32.c
CONFLICT (content): Merge conflict in arch/x86/kernel/process_64.c
Applying acpi-acpi_numa_init-build-fix
Applying ia64, acpi: fix Altix boot breakage in ACPI
Applying acpi: fix boot breakage on Altix
Merging pci/linux-next
CONFLICT (delete/modify): arch/x86/kernel/setup_64.c deleted in HEAD and modified in pci/linux-next. Version pci/linux-next of arch/x86/kernel/setup_64.c left in tree.
CONFLICT (content): Merge conflict in arch/x86/pci/irq.c
CONFLICT (content): Merge conflict in arch/x86/pci/pci.h
CONFLICT (content): Merge conflict in include/linux/device.h
Applying pci: usb fixup 1
Merging quilt/device-mapper
Merging hid/mm
Merging quilt/i2c
CONFLICT (content): Merge conflict in drivers/i2c/i2c-core.c
Merging quilt/kernel-doc
Merging avr32/avr32-arch
Merging v4l-dvb/stable
Applying v4l-dvb: class_for_each_device API change fallout
Merging s390/features
CONFLICT (content): Merge conflict in drivers/s390/block/dasd.c
CONFLICT (content): Merge conflict in drivers/s390/block/dasd_eckd.c
CONFLICT (content): Merge conflict in drivers/s390/block/dasd_fba.c
CONFLICT (content): Merge conflict in drivers/s390/char/tape_core.c
CONFLICT (content): Merge conflict in drivers/s390/cio/device_fsm.c
CONFLICT (content): Merge conflict in drivers/s390/cio/qdio.c
CONFLICT (content): Merge conflict in drivers/s390/net/claw.c
CONFLICT (content): Merge conflict in drivers/s390/net/ctcm_main.c
CONFLICT (content): Merge conflict in drivers/s390/net/lcs.c
CONFLICT (content): Merge conflict in drivers/s390/net/netiucv.c
Merging sh/master
Merging jfs/next
Merging kbuild/master
Merging quilt/ide
Merging libata/NEXT
Merging nfs/linux-next
Merging xfs/master
Merging infiniband/for-next
Merging acpi/test
CONFLICT (content): Merge conflict in Documentation/kernel-parameters.txt
CONFLICT (content): Merge conflict in arch/ia64/kernel/process.c
CONFLICT (content): Merge conflict in arch/x86/kernel/process.c
CONFLICT (content): Merge conflict in arch/x86/kernel/srat_32.c
CONFLICT (content): Merge conflict in drivers/acpi/processor_core.c
CONFLICT (content): Merge conflict in drivers/acpi/processor_throttling.c
CONFLICT (content): Merge conflict in drivers/acpi/sleep/main.c
CONFLICT (content): Merge conflict in include/asm-ia64/processor.h
CONFLICT (content): Merge conflict in include/asm-x86/processor.h
Merging blackfin/for-linus
Merging nfsd/nfsd-next
CONFLICT (content): Merge conflict in net/sunrpc/svc.c
Merging ieee1394/for-next
Merging hwmon/testing
Merging ubi/master
Merging kvm/master
Merging dlm/next
Merging scsi/master
Applying scsi: fix fallout from the class_find_device API change
Applying scsi: fix fallout from KOBJ_NAME_LEN removal
Merging ia64/test
Merging tests/master
CONFLICT (content): Merge conflict in lib/Kconfig.debug
Merging ocfs2/linux-next
Merging selinux/for-akpm
Merging quilt/m68k
Merging powerpc/powerpc-next
CONFLICT (content): Merge conflict in drivers/macintosh/mediabay.c
Merging lblnet/master
Merging ext4/next
Merging 4xx/next
Merging async_tx/next
Merging udf/for_next
Merging security-testing/next
Merging net/master
CONFLICT (content): Merge conflict in Documentation/powerpc/booting-without-of.txt
CONFLICT (content): Merge conflict in drivers/net/fs_enet/fs_enet-main.c
Merging sparc/master
CONFLICT (content): Merge conflict in include/asm-m68k/sbus.h
Merging galak/powerpc-next
Merging mtd/master
Merging wireless/master
Merging crypto/master
Merging vfs/vfs-2.6.25
Merging sound/master
Merging arm/devel
CONFLICT (content): Merge conflict in arch/arm/mach-at91/board-yl-9200.c
Merging cpufreq/next
CONFLICT (content): Merge conflict in drivers/cpufreq/cpufreq.c
Merging v9fs/for-next
Merging quilt/rr
CONFLICT (content): Merge conflict in drivers/char/hvc_console.h
CONFLICT (content): Merge conflict in kernel/stop_machine.c
Applying rr fix patch 1
Applying virtio: virtio console can be a module
Merging cifs/master
Merging mmc/next
Merging gfs2/master
Merging input/next
Merging semaphore/semaphore
Merging semaphore-removal/semaphore-removal
CONFLICT (content): Merge conflict in drivers/net/ps3_gelic_wireless.c
CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_attr.c
CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_def.h
CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_mbx.c
CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_mid.c
CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_os.c
Merging bkl-removal/bkl-removal
CONFLICT (content): Merge conflict in drivers/s390/char/monreader.c
CONFLICT (content): Merge conflict in fs/nfs/file.c
Merging trivial/next
Merging ubifs/for_andrew
Merging lsm/for-next
Merging block/for-next
Merging embedded/master
Merging firmware/master
CONFLICT (content): Merge conflict in drivers/atm/Makefile
CONFLICT (content): Merge conflict in drivers/char/ip2/ip2main.c
CONFLICT (content): Merge conflict in drivers/media/dvb/ttpci/Makefile
CONFLICT (delete/modify): drivers/usb/serial/ti_fw_3410.h deleted in firmware/master and modified in HEAD. Version HEAD of drivers/usb/serial/ti_fw_3410.h left in tree.
CONFLICT (delete/modify): drivers/usb/serial/ti_fw_5052.h deleted in firmware/master and modified in HEAD. Version HEAD of drivers/usb/serial/ti_fw_5052.h left in tree.
CONFLICT (content): Merge conflict in drivers/usb/serial/ti_usb_3410_5052.c
CONFLICT (content): Merge conflict in sound/pci/Kconfig
CONFLICT (content): Merge conflict in sound/pci/maestro3.c
CONFLICT (content): Merge conflict in sound/pci/ymfpci/ymfpci_main.c
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
Merging backlight/for-mm
CONFLICT (content): Merge conflict in drivers/video/backlight/Kconfig
CONFLICT (content): Merge conflict in drivers/video/backlight/Makefile
Merging kgdb/kgdb-next
Merging slab/for-next
Merging m68knommu/for-next
Merging uclinux/for-next
Merging md/for-next
Merging cris/for-next
Merging quilt/ttydev
CONFLICT (delete/modify): drivers/net/wireless/strip.c deleted in HEAD and modified in quilt/ttydev. Version quilt/ttydev of drivers/net/wireless/strip.c left in tree.
CONFLICT (content): Merge conflict in drivers/serial/cpm_uart/cpm_uart_core.c
CONFLICT (content): Merge conflict in drivers/usb/gadget/serial.c
CONFLICT (delete/modify): drivers/usb/serial/airprime.c deleted in HEAD and modified in quilt/ttydev. Version quilt/ttydev of drivers/usb/serial/airprime.c left in tree.
CONFLICT (content): Merge conflict in drivers/usb/serial/cp2101.c
CONFLICT (content): Merge conflict in drivers/usb/serial/digi_acceleport.c
CONFLICT (content): Merge conflict in drivers/usb/serial/ftdi_sio.c
CONFLICT (content): Merge conflict in drivers/usb/serial/io_fw_down3.h
CONFLICT (content): Merge conflict in drivers/usb/serial/io_ti.c
CONFLICT (content): Merge conflict in drivers/usb/serial/ir-usb.c
CONFLICT (content): Merge conflict in drivers/usb/serial/keyspan.c
CONFLICT (content): Merge conflict in drivers/usb/serial/keyspan_pda.c
CONFLICT (delete/modify): drivers/usb/serial/ti_fw_3410.h deleted in HEAD and modified in quilt/ttydev. Version quilt/ttydev of drivers/usb/serial/ti_fw_3410.h left in tree.
CONFLICT (delete/modify): drivers/usb/serial/ti_fw_5052.h deleted in HEAD and modified in quilt/ttydev. Version quilt/ttydev of drivers/usb/serial/ti_fw_5052.h left in tree.
CONFLICT (content): Merge conflict in drivers/usb/serial/ti_usb_3410_5052.c
CONFLICT (content): Merge conflict in drivers/usb/serial/usb-serial.c
CONFLICT (content): Merge conflict in drivers/usb/serial/whiteheat.c
$ git reset --hard HEAD^
Applying module: fix NULL pointer dereference in find_symbol()


Attachments:
(No filename) (11.57 kB)
(No filename) (197.00 B)
Download all attachments

2008-07-01 20:34:46

by Rafael J. Wysocki

[permalink] [raw]
Subject: Re: inux-next: Tree for July 1

On Tuesday, 1 of July 2008, Stephen Rothwell wrote:
> Hi all,
>
> Changes since next-20080630:
>
> New tree: ttydev - unfortunately it had to be reverted because of build
> failures after lots of conflict resolution (which may have caused the
> build failures).
>
> Changed tree: the cris tree changed branch names.
>
> The sched tree gained a couple of conflicts against the ftrace and
> cpus4096 trees.
>
> The pci tree gained a conflict against the x86 tree.
>
> The usb tree reverted due to a build failure after merging with the pci
> tree was changed for a fixup patch.
>
> The v4l-dvb tree lost its three conflicts against Linus' tree.
>
> The s390 tree gained a conflict against the diver-core tree.
>
> The ide tree fixed its build problems.
>
> The nfsd tree lost a conflict against the nfs tree.
>
> The powerpc tree gained a conflict against the ide tree.
>
> The net tree gained two conflicts against the powerpc tree.
>
> The galak tree lost its conflict against the net tree.
>
> the blk-removal tree gained a conflict against the s390 tree.
>
> The firmware tree lost several conflicts against the net tree so didn't
> need a commit reverted any more.
>
> Merging the ttydev tree got several conflicts against the usb and
> firmware trees. Unfortunately, it also would not build and so was
> reverted.
>
> I have also applied the following patches for know problems:
> module: fix NULL pointer dereference in find_symbol()

I can't mount NFS shares with this kernel. I get something of this sort in
dmesg and it seems to be 100% reproducible:

[ 314.058858] RPC: Registered udp transport module.
[ 314.058863] RPC: Registered tcp transport module.
[ 314.490970] RPC: transport (0) not supported
[ 319.246987] __ratelimit: 23 messages suppressed

linux-next from yesterday was fine with the same .config .

Thanks,
Rafael

2008-07-01 20:49:57

by Randy Dunlap

[permalink] [raw]
Subject: Re: inux-next: Tree for July 1

On Tue, 1 Jul 2008, Rafael J. Wysocki wrote:

> On Tuesday, 1 of July 2008, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since next-20080630:
> >
> > New tree: ttydev - unfortunately it had to be reverted because of build
> > failures after lots of conflict resolution (which may have caused the
> > build failures).
> >
> > Changed tree: the cris tree changed branch names.
> >
> > The sched tree gained a couple of conflicts against the ftrace and
> > cpus4096 trees.
> >
> > The pci tree gained a conflict against the x86 tree.
> >
> > The usb tree reverted due to a build failure after merging with the pci
> > tree was changed for a fixup patch.
> >
> > The v4l-dvb tree lost its three conflicts against Linus' tree.
> >
> > The s390 tree gained a conflict against the diver-core tree.
> >
> > The ide tree fixed its build problems.
> >
> > The nfsd tree lost a conflict against the nfs tree.
> >
> > The powerpc tree gained a conflict against the ide tree.
> >
> > The net tree gained two conflicts against the powerpc tree.
> >
> > The galak tree lost its conflict against the net tree.
> >
> > the blk-removal tree gained a conflict against the s390 tree.
> >
> > The firmware tree lost several conflicts against the net tree so didn't
> > need a commit reverted any more.
> >
> > Merging the ttydev tree got several conflicts against the usb and
> > firmware trees. Unfortunately, it also would not build and so was
> > reverted.
> >
> > I have also applied the following patches for know problems:
> > module: fix NULL pointer dereference in find_symbol()
>
> I can't mount NFS shares with this kernel. I get something of this sort in
> dmesg and it seems to be 100% reproducible:
>
> [ 314.058858] RPC: Registered udp transport module.
> [ 314.058863] RPC: Registered tcp transport module.
> [ 314.490970] RPC: transport (0) not supported
> [ 319.246987] __ratelimit: 23 messages suppressed
>
> linux-next from yesterday was fine with the same .config .

Same problem for me. Thanks for reporting it.
I wondered if it was something that I did wrong...

--
~Randy

2008-07-01 20:50:49

by Chuck Lever

[permalink] [raw]
Subject: Re: inux-next: Tree for July 1

On Jul 1, 2008, at 4:36 PM, Rafael J. Wysocki wrote:
> On Tuesday, 1 of July 2008, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since next-20080630:
>>
>> New tree: ttydev - unfortunately it had to be reverted because of
>> build
>> failures after lots of conflict resolution (which may have caused the
>> build failures).
>>
>> Changed tree: the cris tree changed branch names.
>>
>> The sched tree gained a couple of conflicts against the ftrace and
>> cpus4096 trees.
>>
>> The pci tree gained a conflict against the x86 tree.
>>
>> The usb tree reverted due to a build failure after merging with the
>> pci
>> tree was changed for a fixup patch.
>>
>> The v4l-dvb tree lost its three conflicts against Linus' tree.
>>
>> The s390 tree gained a conflict against the diver-core tree.
>>
>> The ide tree fixed its build problems.
>>
>> The nfsd tree lost a conflict against the nfs tree.
>>
>> The powerpc tree gained a conflict against the ide tree.
>>
>> The net tree gained two conflicts against the powerpc tree.
>>
>> The galak tree lost its conflict against the net tree.
>>
>> the blk-removal tree gained a conflict against the s390 tree.
>>
>> The firmware tree lost several conflicts against the net tree so
>> didn't
>> need a commit reverted any more.
>>
>> Merging the ttydev tree got several conflicts against the usb and
>> firmware trees. Unfortunately, it also would not build and so was
>> reverted.
>>
>> I have also applied the following patches for know problems:
>> module: fix NULL pointer dereference in find_symbol()
>
> I can't mount NFS shares with this kernel. I get something of this
> sort in
> dmesg and it seems to be 100% reproducible:
>
> [ 314.058858] RPC: Registered udp transport module.
> [ 314.058863] RPC: Registered tcp transport module.
> [ 314.490970] RPC: transport (0) not supported
> [ 319.246987] __ratelimit: 23 messages suppressed
>
> linux-next from yesterday was fine with the same .config .

What's your mount command line?

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

2008-07-01 21:04:03

by Rafael J. Wysocki

[permalink] [raw]
Subject: Re: inux-next: Tree for July 1

On Tuesday, 1 of July 2008, Chuck Lever wrote:
> On Jul 1, 2008, at 4:36 PM, Rafael J. Wysocki wrote:
> > On Tuesday, 1 of July 2008, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> Changes since next-20080630:
> >>
> >> New tree: ttydev - unfortunately it had to be reverted because of
> >> build
> >> failures after lots of conflict resolution (which may have caused the
> >> build failures).
> >>
> >> Changed tree: the cris tree changed branch names.
> >>
> >> The sched tree gained a couple of conflicts against the ftrace and
> >> cpus4096 trees.
> >>
> >> The pci tree gained a conflict against the x86 tree.
> >>
> >> The usb tree reverted due to a build failure after merging with the
> >> pci
> >> tree was changed for a fixup patch.
> >>
> >> The v4l-dvb tree lost its three conflicts against Linus' tree.
> >>
> >> The s390 tree gained a conflict against the diver-core tree.
> >>
> >> The ide tree fixed its build problems.
> >>
> >> The nfsd tree lost a conflict against the nfs tree.
> >>
> >> The powerpc tree gained a conflict against the ide tree.
> >>
> >> The net tree gained two conflicts against the powerpc tree.
> >>
> >> The galak tree lost its conflict against the net tree.
> >>
> >> the blk-removal tree gained a conflict against the s390 tree.
> >>
> >> The firmware tree lost several conflicts against the net tree so
> >> didn't
> >> need a commit reverted any more.
> >>
> >> Merging the ttydev tree got several conflicts against the usb and
> >> firmware trees. Unfortunately, it also would not build and so was
> >> reverted.
> >>
> >> I have also applied the following patches for know problems:
> >> module: fix NULL pointer dereference in find_symbol()
> >
> > I can't mount NFS shares with this kernel. I get something of this
> > sort in
> > dmesg and it seems to be 100% reproducible:
> >
> > [ 314.058858] RPC: Registered udp transport module.
> > [ 314.058863] RPC: Registered tcp transport module.
> > [ 314.490970] RPC: transport (0) not supported
> > [ 319.246987] __ratelimit: 23 messages suppressed
> >
> > linux-next from yesterday was fine with the same .config .
>
> What's your mount command line?

albercik:~ # mount -t nfs chimera:/home/rafael/src src/
mount.nfs: Input/output error

Thanks,
Rafael

2008-07-02 00:49:21

by Myklebust, Trond

[permalink] [raw]
Subject: Re: inux-next: Tree for July 1

On Tue, 2008-07-01 at 22:36 +0200, Rafael J. Wysocki wrote:
> I can't mount NFS shares with this kernel. I get something of this sort in
> dmesg and it seems to be 100% reproducible:
>
> [ 314.058858] RPC: Registered udp transport module.
> [ 314.058863] RPC: Registered tcp transport module.
> [ 314.490970] RPC: transport (0) not supported
> [ 319.246987] __ratelimit: 23 messages suppressed

Does this patch fix the problem for you?
-----------------------------------------------------------------------------------
From: Trond Myklebust <[email protected]>
NFS: Fix the mount protocol defaults for binary mounts

Signed-off-by: Trond Myklebust <[email protected]>
---

fs/nfs/super.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index e09b1c2..85fbb98 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -1575,6 +1575,7 @@ static int nfs_validate_mount_data(void *options,

if (!(data->flags & NFS_MOUNT_TCP))
args->nfs_server.protocol = XPRT_TRANSPORT_UDP;
+ nfs_set_transport_defaults(args);
/* N.B. caller will free nfs_server.hostname in all cases */
args->nfs_server.hostname = kstrdup(data->hostname, GFP_KERNEL);
args->namlen = data->namlen;


--
Trond Myklebust
Linux NFS client maintainer

NetApp
[email protected]
http://www.netapp.com

2008-07-02 03:11:39

by Joseph Fannin

[permalink] [raw]
Subject: Re: inux-next 0701 mv643xx_eth powerpc build failure

On Wed, Jul 02, 2008 at 01:14:34AM +1000, Stephen Rothwell wrote:

[next-20080701]

I'm getting a build failure on 32bit powerpc in -next, but not in mainline:

drivers/net/mv643xx_eth.c: In function 'mv643xx_eth_netpoll':
drivers/net/mv643xx_eth.c:2115: error: 'INT_CAUSE_EXT' undeclared
(first use in this function)
drivers/net/mv643xx_eth.c:2115: error: (Each undeclared identifier is
reported only once
drivers/net/mv643xx_eth.c:2115: error: for each function it appears in.)

I haven't investigated any further than a quick check if this hardware
even makes sense on 32bit powerpc -- it seems it does. For now, I'm
just going to punt this and go to bed. :-)

--
Joseph Fannin
[email protected]

2008-07-02 03:18:16

by Randy Dunlap

[permalink] [raw]
Subject: Re: inux-next: Tree for July 1

On Wed, 2 Jul 2008 01:14:34 +1000 Stephen Rothwell wrote:

> Hi all,
>
> Changes since next-20080630:

It looks like localversion-next contains:
-next-20080702
for the 20080701 kernel. :(
Makes my scripts fail.


http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commitdiff;h=55b50ebb424c5c4168077335f3909e3a925a6948

---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/

2008-07-02 03:28:00

by Stephen Rothwell

[permalink] [raw]
Subject: Re: inux-next: Tree for July 1

Hi Randy,

On Tue, 1 Jul 2008 20:15:14 -0700 Randy Dunlap <[email protected]> wrote:
>
> On Wed, 2 Jul 2008 01:14:34 +1000 Stephen Rothwell wrote:
>
> > Hi all,
> >
> > Changes since next-20080630:
>
> It looks like localversion-next contains:
> -next-20080702
> for the 20080701 kernel. :(
> Makes my scripts fail.

That would be because I finished after midnight. I will be more careful
in the future.

--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/


Attachments:
(No filename) (519.00 B)
(No filename) (197.00 B)
Download all attachments

2008-07-02 03:32:41

by Randy Dunlap

[permalink] [raw]
Subject: Re: inux-next: Tree for July 1

On Tue, 01 Jul 2008 20:49:03 -0400 Trond Myklebust wrote:

> On Tue, 2008-07-01 at 22:36 +0200, Rafael J. Wysocki wrote:
> > I can't mount NFS shares with this kernel. I get something of this sort in
> > dmesg and it seems to be 100% reproducible:
> >
> > [ 314.058858] RPC: Registered udp transport module.
> > [ 314.058863] RPC: Registered tcp transport module.
> > [ 314.490970] RPC: transport (0) not supported
> > [ 319.246987] __ratelimit: 23 messages suppressed
>
> Does this patch fix the problem for you?

Yes. Thanks.


> -----------------------------------------------------------------------------------
> From: Trond Myklebust <[email protected]>
> NFS: Fix the mount protocol defaults for binary mounts
>
> Signed-off-by: Trond Myklebust <[email protected]>
> ---
>
> fs/nfs/super.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/fs/nfs/super.c b/fs/nfs/super.c
> index e09b1c2..85fbb98 100644
> --- a/fs/nfs/super.c
> +++ b/fs/nfs/super.c
> @@ -1575,6 +1575,7 @@ static int nfs_validate_mount_data(void *options,
>
> if (!(data->flags & NFS_MOUNT_TCP))
> args->nfs_server.protocol = XPRT_TRANSPORT_UDP;
> + nfs_set_transport_defaults(args);
> /* N.B. caller will free nfs_server.hostname in all cases */
> args->nfs_server.hostname = kstrdup(data->hostname, GFP_KERNEL);
> args->namlen = data->namlen;
>
>
> --

---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/

2008-07-02 04:11:12

by Stephen Rothwell

[permalink] [raw]
Subject: Re: inux-next 0701 mv643xx_eth powerpc build failure

Hi Joseph,

On Tue, 1 Jul 2008 23:11:12 -0400 Joseph Fannin <[email protected]> wrote:
>
> On Wed, Jul 02, 2008 at 01:14:34AM +1000, Stephen Rothwell wrote:
>
> [next-20080701]
>
> I'm getting a build failure on 32bit powerpc in -next, but not in mainline:
>
> drivers/net/mv643xx_eth.c: In function 'mv643xx_eth_netpoll':
> drivers/net/mv643xx_eth.c:2115: error: 'INT_CAUSE_EXT' undeclared
> (first use in this function)
> drivers/net/mv643xx_eth.c:2115: error: (Each undeclared identifier is
> reported only once
> drivers/net/mv643xx_eth.c:2115: error: for each function it appears in.)

Caused by commit 073a345c04b01da0cc5b79ac7be0c7c8b1691ef5 ("mv643xx_eth:
clarify irq masking and unmasking") from the net or wireless tree. It
entered linux-next on June 19.

--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/


Attachments:
(No filename) (873.00 B)
(No filename) (197.00 B)
Download all attachments

2008-07-02 08:21:36

by Lennert Buytenhek

[permalink] [raw]
Subject: Re: inux-next 0701 mv643xx_eth powerpc build failure

On Tue, Jul 01, 2008 at 11:11:12PM -0400, Joseph Fannin wrote:

> I'm getting a build failure on 32bit powerpc in -next, but not in mainline:
>
> drivers/net/mv643xx_eth.c: In function 'mv643xx_eth_netpoll':
> drivers/net/mv643xx_eth.c:2115: error: 'INT_CAUSE_EXT' undeclared
> (first use in this function)
> drivers/net/mv643xx_eth.c:2115: error: (Each undeclared identifier is
> reported only once
> drivers/net/mv643xx_eth.c:2115: error: for each function it appears in.)

Does this fix it for you?


Index: linux-2.6.26-rc8/drivers/net/mv643xx_eth.c
===================================================================
--- linux-2.6.26-rc8.orig/drivers/net/mv643xx_eth.c
+++ linux-2.6.26-rc8/drivers/net/mv643xx_eth.c
@@ -2184,7 +2184,7 @@ static void mv643xx_eth_netpoll(struct n

mv643xx_eth_irq(dev->irq, dev);

- wrl(mp, INT_MASK(mp->port_num), INT_TX_END | INT_RX | INT_CAUSE_EXT);
+ wrl(mp, INT_MASK(mp->port_num), INT_TX_END | INT_RX | INT_EXT);
}
#endif



> I haven't investigated any further than a quick check if this hardware
> even makes sense on 32bit powerpc -- it seems it does.

It does -- it is used on ARM, PPC and MIPS.

2008-07-02 10:50:14

by Rafael J. Wysocki

[permalink] [raw]
Subject: Re: inux-next: Tree for July 1

On Wednesday, 2 of July 2008, Randy Dunlap wrote:
> On Tue, 01 Jul 2008 20:49:03 -0400 Trond Myklebust wrote:
>
> > On Tue, 2008-07-01 at 22:36 +0200, Rafael J. Wysocki wrote:
> > > I can't mount NFS shares with this kernel. I get something of this sort in
> > > dmesg and it seems to be 100% reproducible:
> > >
> > > [ 314.058858] RPC: Registered udp transport module.
> > > [ 314.058863] RPC: Registered tcp transport module.
> > > [ 314.490970] RPC: transport (0) not supported
> > > [ 319.246987] __ratelimit: 23 messages suppressed
> >
> > Does this patch fix the problem for you?
>
> Yes. Thanks.

It also fixes the issue for me.

Thanks,
Rafael

2008-07-02 17:15:29

by Myklebust, Trond

[permalink] [raw]
Subject: Re: inux-next: Tree for July 1

On Wed, 2008-07-02 at 10:34 -0400, Chuck Lever wrote:
> On Tue, Jul 1, 2008 at 8:49 PM, Trond Myklebust
> <[email protected]> wrote:
> > On Tue, 2008-07-01 at 22:36 +0200, Rafael J. Wysocki wrote:
> >> I can't mount NFS shares with this kernel. I get something of this sort in
> >> dmesg and it seems to be 100% reproducible:
> >>
> >> [ 314.058858] RPC: Registered udp transport module.
> >> [ 314.058863] RPC: Registered tcp transport module.
> >> [ 314.490970] RPC: transport (0) not supported
> >> [ 319.246987] __ratelimit: 23 messages suppressed
> >
> > Does this patch fix the problem for you?
> > -----------------------------------------------------------------------------------
> > From: Trond Myklebust <[email protected]>
> > NFS: Fix the mount protocol defaults for binary mounts
> >
> > Signed-off-by: Trond Myklebust <[email protected]>
> > ---
> >
> > fs/nfs/super.c | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/fs/nfs/super.c b/fs/nfs/super.c
> > index e09b1c2..85fbb98 100644
> > --- a/fs/nfs/super.c
> > +++ b/fs/nfs/super.c
> > @@ -1575,6 +1575,7 @@ static int nfs_validate_mount_data(void *options,
> >
> > if (!(data->flags & NFS_MOUNT_TCP))
> > args->nfs_server.protocol = XPRT_TRANSPORT_UDP;
> > + nfs_set_transport_defaults(args);
>
> nfs_set_transport_defaults() is overkill for the legacy mount path.
> The bug is that the logic here assumes that nfs_server.protocol
> already has the default value of XPRT_TRANSPORT_TCP, but commit
> 8b59ea3c removed that default. The correct fix is to add
>
> args->nfs_server.protocol = XPRT_TRANSPORT_TCP;
>
> just before the 'if' statement. We should fold that into 8b59ea3c to
> preserve bisectability.

NACK. You still need to set the appropriate retrans and timeo defaults.

--
Trond Myklebust
Linux NFS client maintainer

NetApp
[email protected]
http://www.netapp.com

2008-07-02 19:02:49

by Myklebust, Trond

[permalink] [raw]
Subject: Re: inux-next: Tree for July 1

On Wed, 2008-07-02 at 13:43 -0400, Chuck Lever wrote:
> On Wed, Jul 2, 2008 at 1:15 PM, Trond Myklebust
> <[email protected]> wrote:
> > On Wed, 2008-07-02 at 10:34 -0400, Chuck Lever wrote:
> >> On Tue, Jul 1, 2008 at 8:49 PM, Trond Myklebust
> >> <[email protected]> wrote:
> >> > On Tue, 2008-07-01 at 22:36 +0200, Rafael J. Wysocki wrote:
> >> >> I can't mount NFS shares with this kernel. I get something of this sort in
> >> >> dmesg and it seems to be 100% reproducible:
> >> >>
> >> >> [ 314.058858] RPC: Registered udp transport module.
> >> >> [ 314.058863] RPC: Registered tcp transport module.
> >> >> [ 314.490970] RPC: transport (0) not supported
> >> >> [ 319.246987] __ratelimit: 23 messages suppressed
> >> >
> >> > Does this patch fix the problem for you?
> >> > -----------------------------------------------------------------------------------
> >> > From: Trond Myklebust <[email protected]>
> >> > NFS: Fix the mount protocol defaults for binary mounts
> >> >
> >> > Signed-off-by: Trond Myklebust <[email protected]>
> >> > ---
> >> >
> >> > fs/nfs/super.c | 1 +
> >> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >> >
> >> > diff --git a/fs/nfs/super.c b/fs/nfs/super.c
> >> > index e09b1c2..85fbb98 100644
> >> > --- a/fs/nfs/super.c
> >> > +++ b/fs/nfs/super.c
> >> > @@ -1575,6 +1575,7 @@ static int nfs_validate_mount_data(void *options,
> >> >
> >> > if (!(data->flags & NFS_MOUNT_TCP))
> >> > args->nfs_server.protocol = XPRT_TRANSPORT_UDP;
> >> > + nfs_set_transport_defaults(args);
> >>
> >> nfs_set_transport_defaults() is overkill for the legacy mount path.
> >> The bug is that the logic here assumes that nfs_server.protocol
> >> already has the default value of XPRT_TRANSPORT_TCP, but commit
> >> 8b59ea3c removed that default. The correct fix is to add
> >>
> >> args->nfs_server.protocol = XPRT_TRANSPORT_TCP;
> >>
> >> just before the 'if' statement. We should fold that into 8b59ea3c to
> >> preserve bisectability.
> >
> > NACK. You still need to set the appropriate retrans and timeo defaults.
>
> NACK squared [Bruce told me to write this].
>
> The only bug involves the transport protocol setting for NFSv2/v3 legacy mounts.
>
> The legacy mount command already sets appropriate default values for
> the timeout fields, and the code in that arm of
> nfs_validate_mount_options() _unconditionally_ copies the mount
> command's timeout settings into the nfs_parse_mount_options structure.
>
> This is how it worked before commit 8b59ea3c, and 8b59ea3c doesn't
> change this behavior.

That's utter nonsense. We _never_ relied on the mount command to set
defaults for us. I remember all too well debugging old versions of
am-utils/amd that set the TCP flag and then happily set timeout values
of 7/10 second. As far as I know, all am-utils versions since then have
used timeo=0, retrans=0.

However, that does illustrate something else:
nfs_set_transport_defaults() has never been necessary for setting timeo
and retrans, since the zero case is already covered in
nfs_init_timeout_values() (which is also where the sanity checks are
applied).

---------------------------------------------------------------------------------
From: Trond Myklebust <[email protected]>
Date: Wed, 2 Jul 2008 14:43:47 -0400
NFS: Fix the mount protocol defaults for binary mounts

Move the UDP/TCP default timeo/retrans settings for text mounts to
nfs_init_timeout_values(), which was were they were always being
initialised for binary mounts.

Ensure we do initialise the transport protocol for the legacy binary mount
case in nfs_validate_mount_data.

Ensure that we sanity check the transport protocol in the legacy binary
mount case in nfs4_validate_mount_data

Fix up the incorrect values of NFS_DEF_UDP_TIMEO, NFS_DEF_UDP_RETRANS to
match the nfs manpage documentation.

Signed-off-by: Trond Myklebust <[email protected]>
---

fs/nfs/client.c | 13 +++++++-----
fs/nfs/super.c | 53 ++++++++++++++++++++++++------------------------
include/linux/nfs_fs.h | 4 ++--
3 files changed, 37 insertions(+), 33 deletions(-)

diff --git a/fs/nfs/client.c b/fs/nfs/client.c
index f2a092c..5ee23e7 100644
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -431,14 +431,14 @@ static void nfs_init_timeout_values(struct rpc_timeout *to, int proto,
{
to->to_initval = timeo * HZ / 10;
to->to_retries = retrans;
- if (!to->to_retries)
- to->to_retries = 2;

switch (proto) {
case XPRT_TRANSPORT_TCP:
case XPRT_TRANSPORT_RDMA:
+ if (to->to_retries == 0)
+ to->to_retries = NFS_DEF_TCP_RETRANS;
if (to->to_initval == 0)
- to->to_initval = 60 * HZ;
+ to->to_initval = NFS_DEF_TCP_TIMEO * HZ / 10;
if (to->to_initval > NFS_MAX_TCP_TIMEOUT)
to->to_initval = NFS_MAX_TCP_TIMEOUT;
to->to_increment = to->to_initval;
@@ -450,14 +450,17 @@ static void nfs_init_timeout_values(struct rpc_timeout *to, int proto,
to->to_exponential = 0;
break;
case XPRT_TRANSPORT_UDP:
- default:
+ if (to->to_retries == 0)
+ to->to_retries = NFS_DEF_UDP_RETRANS;
if (!to->to_initval)
- to->to_initval = 11 * HZ / 10;
+ to->to_initval = NFS_DEF_UDP_TIMEO * HZ / 10;
if (to->to_initval > NFS_MAX_UDP_TIMEOUT)
to->to_initval = NFS_MAX_UDP_TIMEOUT;
to->to_maxval = NFS_MAX_UDP_TIMEOUT;
to->to_exponential = 1;
break;
+ default:
+ BUG();
}
}

diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index e09b1c2..47cf83e 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -819,40 +819,39 @@ static void nfs_parse_ip_address(char *string, size_t str_len,
}

/*
- * Time-out and mount transport default settings are based on the
- * specified NFS transport. For legacy mounts, these are set by
- * the mount command before mount(2) is invoked. For text-based
- * mounts, the kernel must take care to set these.
+ * Sanity check the NFS transport protocol.
+ *
*/
-static void nfs_set_transport_defaults(struct nfs_parsed_mount_data *mnt)
+static void nfs_validate_transport_protocol(struct nfs_parsed_mount_data *mnt)
{
switch (mnt->nfs_server.protocol) {
case XPRT_TRANSPORT_UDP:
- if (mnt->mount_server.protocol == 0)
- mnt->mount_server.protocol = XPRT_TRANSPORT_UDP;
- if (mnt->timeo == 0)
- mnt->timeo = NFS_DEF_UDP_TIMEO;
- if (mnt->retrans == 0)
- mnt->retrans = NFS_DEF_UDP_RETRANS;
- break;
case XPRT_TRANSPORT_TCP:
case XPRT_TRANSPORT_RDMA:
- if (mnt->mount_server.protocol == 0)
- mnt->mount_server.protocol = XPRT_TRANSPORT_TCP;
- if (mnt->timeo == 0)
- mnt->timeo = NFS_DEF_TCP_TIMEO;
- if (mnt->retrans == 0)
- mnt->retrans = NFS_DEF_TCP_RETRANS;
break;
default:
mnt->nfs_server.protocol = XPRT_TRANSPORT_TCP;
- if (mnt->mount_server.protocol == 0)
- mnt->mount_server.protocol = XPRT_TRANSPORT_UDP;
- if (mnt->timeo == 0)
- mnt->timeo = NFS_DEF_TCP_TIMEO;
- if (mnt->retrans == 0)
- mnt->retrans = NFS_DEF_TCP_RETRANS;
+ }
+}
+
+/*
+ * For text based NFSv2/v3 mounts, the mount protocol transport default
+ * settings should depend upon the specified NFS transport.
+ */
+static void nfs_set_mount_transport_protocol(struct nfs_parsed_mount_data *mnt)
+{
+ nfs_validate_transport_protocol(mnt);
+
+ if (mnt->mount_server.protocol == XPRT_TRANSPORT_UDP ||
+ mnt->mount_server.protocol == XPRT_TRANSPORT_TCP)
+ return;
+ switch (mnt->nfs_server.protocol) {
+ case XPRT_TRANSPORT_UDP:
+ mnt->mount_server.protocol = XPRT_TRANSPORT_UDP;
break;
+ case XPRT_TRANSPORT_TCP:
+ case XPRT_TRANSPORT_RDMA:
+ mnt->mount_server.protocol = XPRT_TRANSPORT_TCP;
}
}

@@ -1521,6 +1520,7 @@ static int nfs_validate_mount_data(void *options,
args->acdirmax = NFS_DEF_ACDIRMAX;
args->mount_server.port = 0; /* autobind unless user sets port */
args->nfs_server.port = 0; /* autobind unless user sets port */
+ args->nfs_server.protocol = XPRT_TRANSPORT_TCP;
args->auth_flavors[0] = RPC_AUTH_UNIX;

switch (data->version) {
@@ -1625,7 +1625,7 @@ static int nfs_validate_mount_data(void *options,
nfs_set_port((struct sockaddr *)&args->nfs_server.address,
args->nfs_server.port);

- nfs_set_transport_defaults(args);
+ nfs_set_mount_transport_protocol(args);

status = nfs_parse_devname(dev_name,
&args->nfs_server.hostname,
@@ -2235,6 +2235,7 @@ static int nfs4_validate_mount_data(void *options,
args->acdirmin = data->acdirmin;
args->acdirmax = data->acdirmax;
args->nfs_server.protocol = data->proto;
+ nfs_validate_transport_protocol(args);

break;
default: {
@@ -2250,7 +2251,7 @@ static int nfs4_validate_mount_data(void *options,
nfs_set_port((struct sockaddr *)&args->nfs_server.address,
args->nfs_server.port);

- nfs_set_transport_defaults(args);
+ nfs_validate_transport_protocol(args);

if (args->auth_flavor_len > 1)
goto out_inval_auth;
diff --git a/include/linux/nfs_fs.h b/include/linux/nfs_fs.h
index 3c4078e..29d2619 100644
--- a/include/linux/nfs_fs.h
+++ b/include/linux/nfs_fs.h
@@ -12,8 +12,8 @@
#include <linux/magic.h>

/* Default timeout values */
-#define NFS_DEF_UDP_TIMEO (7)
-#define NFS_DEF_UDP_RETRANS (5)
+#define NFS_DEF_UDP_TIMEO (11)
+#define NFS_DEF_UDP_RETRANS (3)
#define NFS_DEF_TCP_TIMEO (600)
#define NFS_DEF_TCP_RETRANS (2)


--
Trond Myklebust
Linux NFS client maintainer

NetApp
[email protected]
http://www.netapp.com

2008-07-02 23:15:28

by Chuck Lever

[permalink] [raw]
Subject: Re: inux-next: Tree for July 1

On Jul 2, 2008, at 3:02 PM, Trond Myklebust wrote:
> On Wed, 2008-07-02 at 13:43 -0400, Chuck Lever wrote:
>> On Wed, Jul 2, 2008 at 1:15 PM, Trond Myklebust
>> <[email protected]> wrote:
>>> On Wed, 2008-07-02 at 10:34 -0400, Chuck Lever wrote:
>>>> On Tue, Jul 1, 2008 at 8:49 PM, Trond Myklebust
>>>> <[email protected]> wrote:
>>>>> On Tue, 2008-07-01 at 22:36 +0200, Rafael J. Wysocki wrote:
>>>>>> I can't mount NFS shares with this kernel. I get something of
>>>>>> this sort in
>>>>>> dmesg and it seems to be 100% reproducible:
>>>>>>
>>>>>> [ 314.058858] RPC: Registered udp transport module.
>>>>>> [ 314.058863] RPC: Registered tcp transport module.
>>>>>> [ 314.490970] RPC: transport (0) not supported
>>>>>> [ 319.246987] __ratelimit: 23 messages suppressed
>>>>>
>>>>> Does this patch fix the problem for you?
>>>>> -----------------------------------------------------------------------------------
>>>>> From: Trond Myklebust <[email protected]>
>>>>> NFS: Fix the mount protocol defaults for binary mounts
>>>>>
>>>>> Signed-off-by: Trond Myklebust <[email protected]>
>>>>> ---
>>>>>
>>>>> fs/nfs/super.c | 1 +
>>>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>>>>
>>>>> diff --git a/fs/nfs/super.c b/fs/nfs/super.c
>>>>> index e09b1c2..85fbb98 100644
>>>>> --- a/fs/nfs/super.c
>>>>> +++ b/fs/nfs/super.c
>>>>> @@ -1575,6 +1575,7 @@ static int nfs_validate_mount_data(void
>>>>> *options,
>>>>>
>>>>> if (!(data->flags & NFS_MOUNT_TCP))
>>>>> args->nfs_server.protocol =
>>>>> XPRT_TRANSPORT_UDP;
>>>>> + nfs_set_transport_defaults(args);
>>>>
>>>> nfs_set_transport_defaults() is overkill for the legacy mount path.
>>>> The bug is that the logic here assumes that nfs_server.protocol
>>>> already has the default value of XPRT_TRANSPORT_TCP, but commit
>>>> 8b59ea3c removed that default. The correct fix is to add
>>>>
>>>> args->nfs_server.protocol = XPRT_TRANSPORT_TCP;
>>>>
>>>> just before the 'if' statement. We should fold that into
>>>> 8b59ea3c to
>>>> preserve bisectability.
>>>
>>> NACK. You still need to set the appropriate retrans and timeo
>>> defaults.
>>
>> NACK squared [Bruce told me to write this].
>>
>> The only bug involves the transport protocol setting for NFSv2/v3
>> legacy mounts.
>>
>> The legacy mount command already sets appropriate default values for
>> the timeout fields, and the code in that arm of
>> nfs_validate_mount_options() _unconditionally_ copies the mount
>> command's timeout settings into the nfs_parse_mount_options
>> structure.
>>
>> This is how it worked before commit 8b59ea3c, and 8b59ea3c doesn't
>> change this behavior.
>
> That's utter nonsense. We _never_ relied on the mount command to set
> defaults for us. I remember all too well debugging old versions of
> am-utils/amd that set the TCP flag and then happily set timeout values
> of 7/10 second. As far as I know, all am-utils versions since then
> have
> used timeo=0, retrans=0.

Whether or not user space sets the defaults is irrelevant. My point
is the broken commit doesn't change the behavior of copying these
values unconditionally into *data. It does break the transport
protocol setting accidentally.

> However, that does illustrate something else:
> nfs_set_transport_defaults() has never been necessary for setting
> timeo
> and retrans, since the zero case is already covered in
> nfs_init_timeout_values() (which is also where the sanity checks are
> applied).

Fine, then. You should drop 8b59ea3c (as that is only in your devel
branch and linux-next, and not upstream yet; and it appears to be
mostly based on false assumptions) and merge it with what you have
below. That would be more bisectable, easier to document, and easier
to review and demonstrate its correctness.

Also consider breaking this into smaller changes (for similar
reasons). Cleaning up nfs_init_timeout_values() and adding the macro
constants could be a separate patch, for example.

A handful of comments below.

>
>
> ---------------------------------------------------------------------------------
> From: Trond Myklebust <[email protected]>
> Date: Wed, 2 Jul 2008 14:43:47 -0400
> NFS: Fix the mount protocol defaults for binary mounts
>
> Move the UDP/TCP default timeo/retrans settings for text mounts to
> nfs_init_timeout_values(), which was were they were always being
> initialised for binary mounts.

Nit: "which was _where_ they were always"

> Ensure we do initialise the transport protocol for the legacy binary
> mount
> case in nfs_validate_mount_data.

One of the original bugs addressed by 8b59ea3c was that the text-based
mount transport protocol was not being set properly. You are cleaning
that up here as well with the addition of
nfs_set_mount_transport_protocol().

> Ensure that we sanity check the transport protocol in the legacy
> binary
> mount case in nfs4_validate_mount_data
>
> Fix up the incorrect values of NFS_DEF_UDP_TIMEO,
> NFS_DEF_UDP_RETRANS to
> match the nfs manpage documentation.

>
>
> Signed-off-by: Trond Myklebust <[email protected]>
> ---
>
> fs/nfs/client.c | 13 +++++++-----
> fs/nfs/super.c | 53 +++++++++++++++++++++++
> +------------------------
> include/linux/nfs_fs.h | 4 ++--
> 3 files changed, 37 insertions(+), 33 deletions(-)
>
> diff --git a/fs/nfs/client.c b/fs/nfs/client.c
> index f2a092c..5ee23e7 100644
> --- a/fs/nfs/client.c
> +++ b/fs/nfs/client.c
> @@ -431,14 +431,14 @@ static void nfs_init_timeout_values(struct
> rpc_timeout *to, int proto,
> {
> to->to_initval = timeo * HZ / 10;
> to->to_retries = retrans;
> - if (!to->to_retries)
> - to->to_retries = 2;
>
> switch (proto) {
> case XPRT_TRANSPORT_TCP:
> case XPRT_TRANSPORT_RDMA:
> + if (to->to_retries == 0)
> + to->to_retries = NFS_DEF_TCP_RETRANS;
> if (to->to_initval == 0)
> - to->to_initval = 60 * HZ;
> + to->to_initval = NFS_DEF_TCP_TIMEO * HZ / 10;
> if (to->to_initval > NFS_MAX_TCP_TIMEOUT)
> to->to_initval = NFS_MAX_TCP_TIMEOUT;
> to->to_increment = to->to_initval;
> @@ -450,14 +450,17 @@ static void nfs_init_timeout_values(struct
> rpc_timeout *to, int proto,
> to->to_exponential = 0;
> break;
> case XPRT_TRANSPORT_UDP:
> - default:
> + if (to->to_retries == 0)
> + to->to_retries = NFS_DEF_UDP_RETRANS;
> if (!to->to_initval)
> - to->to_initval = 11 * HZ / 10;
> + to->to_initval = NFS_DEF_UDP_TIMEO * HZ / 10;
> if (to->to_initval > NFS_MAX_UDP_TIMEOUT)
> to->to_initval = NFS_MAX_UDP_TIMEOUT;
> to->to_maxval = NFS_MAX_UDP_TIMEOUT;
> to->to_exponential = 1;
> break;
> + default:
> + BUG();

Yes, it's a software bug. But do you really need to throw an Oops
here? Logging a warning seems perfectly adequate.

>
> }
> }
>
> diff --git a/fs/nfs/super.c b/fs/nfs/super.c
> index e09b1c2..47cf83e 100644
> --- a/fs/nfs/super.c
> +++ b/fs/nfs/super.c
> @@ -819,40 +819,39 @@ static void nfs_parse_ip_address(char *string,
> size_t str_len,
> }
>
> /*
> - * Time-out and mount transport default settings are based on the
> - * specified NFS transport. For legacy mounts, these are set by
> - * the mount command before mount(2) is invoked. For text-based
> - * mounts, the kernel must take care to set these.
> + * Sanity check the NFS transport protocol.
> + *
> */
> -static void nfs_set_transport_defaults(struct nfs_parsed_mount_data
> *mnt)
> +static void nfs_validate_transport_protocol(struct
> nfs_parsed_mount_data *mnt)
> {
> switch (mnt->nfs_server.protocol) {
> case XPRT_TRANSPORT_UDP:
> - if (mnt->mount_server.protocol == 0)
> - mnt->mount_server.protocol = XPRT_TRANSPORT_UDP;
> - if (mnt->timeo == 0)
> - mnt->timeo = NFS_DEF_UDP_TIMEO;
> - if (mnt->retrans == 0)
> - mnt->retrans = NFS_DEF_UDP_RETRANS;
> - break;
> case XPRT_TRANSPORT_TCP:
> case XPRT_TRANSPORT_RDMA:
> - if (mnt->mount_server.protocol == 0)
> - mnt->mount_server.protocol = XPRT_TRANSPORT_TCP;
> - if (mnt->timeo == 0)
> - mnt->timeo = NFS_DEF_TCP_TIMEO;
> - if (mnt->retrans == 0)
> - mnt->retrans = NFS_DEF_TCP_RETRANS;
> break;
> default:
> mnt->nfs_server.protocol = XPRT_TRANSPORT_TCP;
> - if (mnt->mount_server.protocol == 0)
> - mnt->mount_server.protocol = XPRT_TRANSPORT_UDP;
> - if (mnt->timeo == 0)
> - mnt->timeo = NFS_DEF_TCP_TIMEO;
> - if (mnt->retrans == 0)
> - mnt->retrans = NFS_DEF_TCP_RETRANS;
> + }
> +}
> +
> +/*
> + * For text based NFSv2/v3 mounts, the mount protocol transport
> default
> + * settings should depend upon the specified NFS transport.
> + */
> +static void nfs_set_mount_transport_protocol(struct
> nfs_parsed_mount_data *mnt)
> +{
> + nfs_validate_transport_protocol(mnt);
> +
> + if (mnt->mount_server.protocol == XPRT_TRANSPORT_UDP ||
> + mnt->mount_server.protocol == XPRT_TRANSPORT_TCP)
> + return;
>
> + switch (mnt->nfs_server.protocol) {
> + case XPRT_TRANSPORT_UDP:
> + mnt->mount_server.protocol = XPRT_TRANSPORT_UDP;
> break;
> + case XPRT_TRANSPORT_TCP:
> + case XPRT_TRANSPORT_RDMA:
> + mnt->mount_server.protocol = XPRT_TRANSPORT_TCP;

Nit: No "break;" here is asking for trouble down the road when we add
more cases to this switch statement.

>
> }
> }
>
> @@ -1521,6 +1520,7 @@ static int nfs_validate_mount_data(void
> *options,
> args->acdirmax = NFS_DEF_ACDIRMAX;
> args->mount_server.port = 0; /* autobind unless user sets port */
> args->nfs_server.port = 0; /* autobind unless user sets port */
> + args->nfs_server.protocol = XPRT_TRANSPORT_TCP;
> args->auth_flavors[0] = RPC_AUTH_UNIX;
>
> switch (data->version) {
> @@ -1625,7 +1625,7 @@ static int nfs_validate_mount_data(void
> *options,
> nfs_set_port((struct sockaddr *)&args->nfs_server.address,
> args->nfs_server.port);
>
> - nfs_set_transport_defaults(args);
> + nfs_set_mount_transport_protocol(args);
>
> status = nfs_parse_devname(dev_name,
> &args->nfs_server.hostname,
> @@ -2235,6 +2235,7 @@ static int nfs4_validate_mount_data(void
> *options,
> args->acdirmin = data->acdirmin;
> args->acdirmax = data->acdirmax;
> args->nfs_server.protocol = data->proto;
> + nfs_validate_transport_protocol(args);
>
> break;
> default: {
> @@ -2250,7 +2251,7 @@ static int nfs4_validate_mount_data(void
> *options,
> nfs_set_port((struct sockaddr *)&args->nfs_server.address,
> args->nfs_server.port);
>
> - nfs_set_transport_defaults(args);
> + nfs_validate_transport_protocol(args);
>
> if (args->auth_flavor_len > 1)
> goto out_inval_auth;
> diff --git a/include/linux/nfs_fs.h b/include/linux/nfs_fs.h
> index 3c4078e..29d2619 100644
> --- a/include/linux/nfs_fs.h
> +++ b/include/linux/nfs_fs.h
> @@ -12,8 +12,8 @@
> #include <linux/magic.h>
>
> /* Default timeout values */
> -#define NFS_DEF_UDP_TIMEO (7)
> -#define NFS_DEF_UDP_RETRANS (5)
> +#define NFS_DEF_UDP_TIMEO (11)
> +#define NFS_DEF_UDP_RETRANS (3)
> #define NFS_DEF_TCP_TIMEO (600)
> #define NFS_DEF_TCP_RETRANS (2)


As an aside, these macro values were copied from the default settings
in the kernel's NFS mount option parser; so the values were always
incorrect for text-based mounts even before 8b59ea3c.

Before I rewrote the nfs(5) man page recently, incidentally, it did
claim that the retransmit timeout for UDP was 7 tenths of a second,
and that the default retrans setting was 5.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

2008-07-03 07:10:49

by Andrew Morton

[permalink] [raw]
Subject: Re: inux-next: Tree for July 1

On Wed, 2 Jul 2008 21:53:06 -0700 Andrew Morton <[email protected]> wrote:

> s390 allmodconfig:
>
> In file included from include/asm/pgtable.h:1087,
> from include/linux/mm.h:39,
> from arch/s390/mm/hugetlbpage.c:8:
> include/asm-generic/pgtable.h: In function '__ptep_modify_prot_start':
> include/asm-generic/pgtable.h:209: error: dereferencing pointer to incomplete type

OK, this wasn't very pretty:

--- a/include/asm-generic/pgtable.h~s390-build-fixes
+++ a/include/asm-generic/pgtable.h
@@ -197,17 +197,13 @@ static inline int pmd_none_or_clear_bad(
}
#endif /* CONFIG_MMU */

-static inline pte_t __ptep_modify_prot_start(struct mm_struct *mm,
- unsigned long addr,
- pte_t *ptep)
-{
- /*
- * Get the current pte state, but zero it out to make it
- * non-present, preventing the hardware from asynchronously
- * updating it.
- */
- return ptep_get_and_clear(mm, addr, ptep);
-}
+/*
+ * Get the current pte state, but zero it out to make it
+ * non-present, preventing the hardware from asynchronously
+ * updating it.
+ */
+#define __ptep_modify_prot_start(mm, addr, ptep) \
+ ptep_get_and_clear(mm, addr, ptep)

static inline void __ptep_modify_prot_commit(struct mm_struct *mm,
unsigned long addr,
@@ -235,12 +231,8 @@ static inline void __ptep_modify_prot_co
* queue the update to be done at some later time. The update must be
* actually committed before the pte lock is released, however.
*/
-static inline pte_t ptep_modify_prot_start(struct mm_struct *mm,
- unsigned long addr,
- pte_t *ptep)
-{
- return __ptep_modify_prot_start(mm, addr, ptep);
-}
+#define ptep_modify_prot_start(mm, addr, ptep) \
+ __ptep_modify_prot_start(mm, addr, ptep)

/*
* Commit an update to a pte, leaving any hardware-controlled bits in
_

2008-07-03 07:10:27

by Andrew Morton

[permalink] [raw]
Subject: Re: inux-next: Tree for July 1

s390 allmodconfig:

In file included from include/asm/pgtable.h:1087,
from include/linux/mm.h:39,
from arch/s390/mm/hugetlbpage.c:8:
include/asm-generic/pgtable.h: In function '__ptep_modify_prot_start':
include/asm-generic/pgtable.h:209: error: dereferencing pointer to incomplete type

2008-07-03 07:11:43

by Andrew Morton

[permalink] [raw]
Subject: Re: inux-next: Tree for July 1


arch/s390/appldata/appldata_base.c: In function 'appldata_generic_handler':
arch/s390/appldata/appldata_base.c:393: error: implicit declaration of function 'P_ERROR'

I dunno what that's all about - P_ERROR got deleted but it still has
users.

That's enough s390ing for today...

2008-07-03 12:39:26

by Joseph Fannin

[permalink] [raw]
Subject: Re: inux-next 0701 mv643xx_eth powerpc build failure

On Wed, Jul 02, 2008 at 10:21:18AM +0200, Lennert Buytenhek wrote:
> On Tue, Jul 01, 2008 at 11:11:12PM -0400, Joseph Fannin wrote:
>
> > I'm getting a build failure on 32bit powerpc in -next, but not in mainline:
> >
> > drivers/net/mv643xx_eth.c: In function 'mv643xx_eth_netpoll':
> > drivers/net/mv643xx_eth.c:2115: error: 'INT_CAUSE_EXT' undeclared
> > (first use in this function)
> > drivers/net/mv643xx_eth.c:2115: error: (Each undeclared identifier is
> > reported only once
> > drivers/net/mv643xx_eth.c:2115: error: for each function it appears in.)
>
> Does this fix it for you?

Yes, it builds fine. Thanks.

>
> Index: linux-2.6.26-rc8/drivers/net/mv643xx_eth.c
> ===================================================================
> --- linux-2.6.26-rc8.orig/drivers/net/mv643xx_eth.c
> +++ linux-2.6.26-rc8/drivers/net/mv643xx_eth.c
> @@ -2184,7 +2184,7 @@ static void mv643xx_eth_netpoll(struct n
>
> mv643xx_eth_irq(dev->irq, dev);
>
> - wrl(mp, INT_MASK(mp->port_num), INT_TX_END | INT_RX | INT_CAUSE_EXT);
> + wrl(mp, INT_MASK(mp->port_num), INT_TX_END | INT_RX | INT_EXT);
> }
> #endif
>
>
>
> > I haven't investigated any further than a quick check if this hardware
> > even makes sense on 32bit powerpc -- it seems it does.
>
> It does -- it is used on ARM, PPC and MIPS.

--
Joseph Fannin
[email protected]

2008-07-03 15:37:40

by Heiko Carstens

[permalink] [raw]
Subject: Re: inux-next: Tree for July 1

On Wed, Jul 02, 2008 at 10:11:32PM -0700, Andrew Morton wrote:
>
> arch/s390/appldata/appldata_base.c: In function 'appldata_generic_handler':
> arch/s390/appldata/appldata_base.c:393: error: implicit declaration of function 'P_ERROR'
>
> I dunno what that's all about - P_ERROR got deleted but it still has
> users.
>
> That's enough s390ing for today...

Yes... I fixed that and also yet another compile bug.
We should pay more attention when pushing out new stuff. Sorry about that.