linux/init/do_mounts.c, branch v3.8

block: partition: msdos: provide UUIDs for partitions

2012-11-23T13:28:58Z

The MSDOS/MBR partition table includes a 32-bit unique ID, often referred to as the NT disk signature. When combined with a partition number within the table, this can form a unique ID similar in concept to EFI/GPT's partition UUID. Constructing and recording this value in struct partition_meta_info allows MSDOS partitions to be referred to on the kernel command-line using the following syntax: root=PARTUUID=0002dd75-01 Signed-off-by: Stephen Warren Cc: Tejun Heo Cc: Will Drewry Cc: Kay Sievers Signed-off-by: Andrew Morton Signed-off-by: Jens Axboe

init: reduce PARTUUID min length to 1 from 36

2012-11-23T13:28:56Z

Reduce the minimum length for a root=PARTUUID= parameter to be considered valid from 36 to 1. EFI/GPT partition UUIDs are always exactly 36 characters long, hence the previous limit. However, the next patch will support DOS/MBR UUIDs too, which have a different, shorter, format. Instead of validating any particular length, just ensure that at least some non-empty value was given by the user. Also, consider a missing UUID value to be a parsing error, in the same vein as if /PARTNROFF exists and can't be parsed. As such, make both error cases print a message and disable rootwait. Convert to pr_err while we're at it. Signed-off-by: Stephen Warren Cc: Tejun Heo Cc: Will Drewry Cc: Kay Sievers Signed-off-by: Andrew Morton Signed-off-by: Jens Axboe

block: store partition_meta_info.uuid as a string

2012-11-23T13:28:53Z

This will allow other types of UUID to be stored here, aside from true UUIDs. This also simplifies code that uses this field, since it's usually constructed from a, used as a, or compared to other, strings. Note: A simplistic approach here would be to set uuid_str[36]=0 whenever a /PARTNROFF option was found to be present. However, this modifies the input string, and causes subsequent calls to devt_from_partuuid() not to see the /PARTNROFF option, which causes different results. In order to avoid misleading future maintainers, this parameter is marked const. Signed-off-by: Stephen Warren Cc: Tejun Heo Cc: Will Drewry Cc: Kay Sievers Signed-off-by: Andrew Morton Signed-off-by: Jens Axboe

vfs: allocate page instead of names_cache buffer in mount_block_root

2012-10-12T04:32:03Z

First, it's incorrect to call putname() after __getname_gfp() since the bare __getname_gfp() call skips the auditing code, while putname() doesn't. mount_block_root allocates a PATH_MAX buffer via __getname_gfp, and then calls get_fs_names to fill the buffer. That function can call get_filesystem_list which assumes that that buffer is a full page in size. On arches where PAGE_SIZE != 4k, then this could potentially overrun. In practice, it's hard to imagine the list of filesystem names even approaching 4k, but it's best to be safe. Just allocate a page for this purpose instead. With this, we can also remove the __getname_gfp() definition since there are no more callers. Signed-off-by: Jeff Layton Signed-off-by: Al Viro

init: disable sparse checking of the mount.o source files

2012-06-01T00:49:27Z

The init/mount.o source files produce a number of sparse warnings of the type: warning: incorrect type in argument 1 (different address spaces) expected char [noderef] *dev_name got char *name This is due to the syscalls expecting some of the arguments to be user pointers but they are being passed as kernel pointers. This is harmless but adds a lot of noise to a sparse build. To limit the noise just disable the sparse checking in the relevant source files, but still display a warning so that the user knows this has been done. Since the sparse checking has been disabled we can also remove the __user __force casts that are scattered thru the source. Signed-off-by: H Hartley Sweeten Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

init: don't try mounting device as nfs root unless type fully matches

2012-05-05T17:04:40Z

Currently, we'll try mounting any device who's major device number is UNNAMED_MAJOR as NFS root. This would happen for non-NFS devices as well (such as 9p devices) but it wouldn't cause any issues since mounting the device as NFS would fail quickly and the code proceeded to doing the proper mount: [ 101.522716] VFS: Unable to mount root fs via NFS, trying floppy. [ 101.534499] VFS: Mounted root (9p filesystem) on device 0:18. Commit 6829a048102a ("NFS: Retry mounting NFSROOT") introduced retries when mounting NFS root, which means that now we don't immediately fail and instead it takes an additional 90+ seconds until we stop retrying, which has revealed the issue this patch fixes. This meant that it would take an additional 90 seconds to boot when we're not using a device type which gets detected in order before NFS. This patch modifies the NFS type check to require device type to be 'Root_NFS' instead of requiring the device to have an UNNAMED_MAJOR major. This makes boot process cleaner since we now won't go through the NFS mounting code at all when the device isn't an NFS root ("/dev/nfs"). Signed-off-by: Sasha Levin Signed-off-by: Linus Torvalds

init/do_mounts.c: print error code on mount failure

2012-03-23T23:58:38Z

Printing the error code makes it easier to debug the cause of a mount failure. For example I had the problem that the root file system could not be mounted read-writeable because my SD card was write-protected. Without an error code it looks like the SD card was not detected at all. Signed-off-by: Bernhard Walle Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Merge branch 'nfs-for-3.3' of git://git.linux-nfs.org/projects/trondmy/linux-nfs

2012-01-10T22:57:40Z

* 'nfs-for-3.3' of git://git.linux-nfs.org/projects/trondmy/linux-nfs: NFSv4: Change the default setting of the nfs4_disable_idmapping parameter NFSv4: Save the owner/group name string when doing open NFS: Remove pNFS bloat from the generic write path pnfs-obj: Must return layout on IO error pnfs-obj: pNFS errors are communicated on iodata->pnfs_error NFS: Cache state owners after files are closed NFS: Clean up nfs4_find_state_owners_locked() NFSv4: include bitmap in nfsv4 get acl data nfs: fix a minor do_div portability issue NFSv4.1: cleanup comment and debug printk NFSv4.1: change nfs4_free_slot parameters for dynamic slots NFSv4.1: cleanup init and reset of session slot tables NFSv4.1: fix backchannel slotid off-by-one bug nfs: fix regression in handling of context= option in NFSv4 NFS - fix recent breakage to NFS error handling. NFS: Retry mounting NFSROOT SUNRPC: Clean up the RPCSEC_GSS service ticket requests

vfs: prefer ->dentry->d_sb to ->mnt->mnt_sb

2012-01-07T04:16:53Z

Signed-off-by: Al Viro

NFS: Retry mounting NFSROOT

2012-01-05T15:42:39Z

Lukas Razik reports that on his SPARC system, booting with an NFS root file system stopped working after commit 56463e50 "NFS: Use super.c for NFSROOT mount option parsing." We found that the network switch to which Lukas' client was attached was delaying access to the LAN after the client's NIC driver reported that its link was up. The delay was longer than the timeouts used in the NFS client during mounting. NFSROOT worked for Lukas before commit 56463e50 because in those kernels, the client's first operation was an rpcbind request to determine which port the NFS server was listening on. When that request failed after a long timeout, the client simply selected the default NFS port (2049). By that time the switch was allowing access to the LAN, and the mount succeeded. Neither of these client behaviors is desirable, so reverting 56463e50 is really not a choice. Instead, introduce a mechanism that retries the NFSROOT mount request several times. This is the same tactic that normal user space NFS mounts employ to overcome server and network delays. Signed-off-by: Lukas Razik [ cel: match kernel coding style, add proper patch description ] [ cel: add exponential back-off ] Signed-off-by: Chuck Lever Tested-by: Lukas Razik Cc: stable@kernel.org # > 2.6.38 Signed-off-by: Trond Myklebust