kernel July 2009

kernel@lists.fedoraproject.org

17 participants
10 discussions

[PATCH 0/3] iwl3945 driver fixes for Fedora 11 (2.6.29)
by Stanislaw Gruszka 18 Aug '09

18 Aug '09

Due to backport of patch linux-2.6-iwl3945-report-killswitch-changes-even-if-the-interface-is-down.patch we have bunch of iwl3945 bugs (race conditions) that are not reproducible on vanilla 2.6.29. These patches address them (at least some of them). [PATCH 1/3] iwl3945: release resources before shutting down (F11 backport) Resolves RHBZ 499811 (and partially 501117), backport of upstream commit, 2.6.30 has this fix. [PATCH 2/3] iwl3945: add debugging for wrong command queue (F11 backport) Partially resolves RHBZ 501117. Backport of upstream commit, 2.6.30 has this commit. Bug is still reproducible, but after patch applied system not crash. Further work needed to fully resolve the problem, but I'm not sure is easy way to fix 501117 (DMA related memory corruption) other than rebase driver to that we have in 2.6.31. [PATCH 3/3] iwl3945: fix rfkill SW and HW mishmash Resolves RHBZ 498622. The bug is fixed in mainline from 2.6.31-rc3 due to total rewrite of rfkill framework (commit: 19d337dff95cbf76edd3ad95c0cee2732c3e1ec5 "rfkill: rewrite"). However it is reproducible on 2.6.30 as well. Perhaps I should post this patch against 2.6.30, but I'm not sure is such kind of patches, which are not backports, are acceptable in stable kernel. I tested all patches on my laptop.

5 8

[RFC PATCH] Disable alsa snd-pcsp driver
by Bill Nottingham 30 Jul '09

30 Jul '09

Because ... why would you want to use this? Ever? Bill

5 5

Re: [PATCH] build a 'full' package on i686
by Quentin Armitage 22 Jul '09

22 Jul '09

Bill Nottingham <notting redhat com> wrote: > The proposal to have the baseline be i686 + SSE2 was shot down; bare > i686 was approved. Does this mean that an i686 kernel without PAE will still be built (my laptop processor does not have PAE so I am rather interested)? I note that the latest build on Koji has not built an i686 without PAE version, and the comments against kernel.spec revision 1.1639 suggests there won't be a non-PAE kernel. On the other hand, revision 1.1640 references Source31: config-i686, although I don't see that file in CVS. Quentin

2 2

[PATCH] build a 'full' package on i686
by Bill Nottingham 20 Jul '09

20 Jul '09

This is needed for the i686-by-default feature. Bill

2 4

ASPM enabled by default - mild potential for breakage
by Matthew Garrett 16 Jul '09

16 Jul '09

I've just flicked ASPM (Active State Power Management - runtime power saving on PCIe hardware) on by default, and it'll be that way in the next rawhide kernel build. There's the potential for some buggy hardware to be upset by this. If your system no longer boots or some hardware doesn't work, try booting with the pcie_aspm=off argument. If that fixes things please file a bug against the kernel and assign it to me (mjg(a)redhat.com) Include dmesg and the output of lspci -n. There's some reasonable heuristics in the kernel to detect supported hardware, so I'm hoping that people shouldn't see any adverse affects. -- Matthew Garrett | mjg59(a)srcf.ucam.org

1 0

Re: Fw: Kernel Loading Sequence
by Ahmad Al-Yaman 13 Jul '09

13 Jul '09

I was able to find out the messages that are displayed before plymouth starts, but I still have no idea what's causing them: [ INFO: possible circular locking dependency detected ] 2.6.29.5-191.eeepc.fc11.i686.PAE #1 ------------------------------------------------------- plymouthd/746 is trying to acquire lock: (&fb_info->lock){--..}, at: [<c05288bc>] fb_mmap+0x83/0x153 but task is already holding lock: (&mm->mmap_sem){----}, at: [<c0406a3c>] sys_mmap2+0x44/0x7b which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (&mm->mmap_sem){----}: [<c04463fa>] __lock_acquire+0x1068/0x137e [<c044676e>] lock_acquire+0x5e/0x7a [<c046ddb4>] might_fault+0x68/0x88 [<c0510de3>] copy_to_user+0x2f/0x106 [<c0489920>] filldir+0x80/0xbb [<c04b8a3d>] sysfs_readdir+0x104/0x138 [<c0489a99>] vfs_readdir+0x68/0x94 [<c0489bd2>] sys_getdents+0x60/0xa4 [<c0403202>] syscall_call+0x7/0xb [<ffffffff>] 0xffffffff -> #2 (sysfs_mutex){--..}: [<c04463fa>] __lock_acquire+0x1068/0x137e [<c044676e>] lock_acquire+0x5e/0x7a [<c07c919f>] mutex_lock_nested+0xe0/0x267 [<c04b8cf4>] sysfs_addrm_start+0x23/0x95 [<c04b919d>] create_dir+0x3a/0x76 [<c04b9206>] sysfs_create_dir+0x2d/0x3d [<c050c198>] kobject_add_internal+0xaa/0x159 [<c050c2ee>] kobject_add_varg+0x31/0x3d [<c050c364>] kobject_add+0x43/0x49 [<c05ad349>] device_add+0x79/0x3fb [<c05ad6dd>] device_register+0x12/0x15 [<c05ad757>] device_create_vargs+0x77/0xa0 [<c05ad79b>] device_create+0x1b/0x1d [<c056f49e>] register_con_driver+0xdd/0x137 [<c0570637>] take_over_console+0x14/0x35 [<c0532c59>] fbcon_takeover+0x5f/0x92 [<c053336f>] fbcon_event_notify+0x3b7/0x726 [<c043ab5c>] notifier_call_chain+0x51/0x78 [<c043ad1d>] __blocking_notifier_call_chain+0x37/0x4c [<c043ad3e>] blocking_notifier_call_chain+0xc/0xe [<c05283fd>] fb_notifier_call_chain+0x11/0x13 [<c0529198>] register_framebuffer+0x1e2/0x1f3 [<c05a01b6>] intelfb_probe+0x491/0x4fb [<c0586cc5>] drm_helper_initial_config+0x148/0x152 [<c05902b5>] i915_driver_load+0x8b2/0x912 [<c057fb7b>] drm_get_dev+0x343/0x405 [<c07b6741>] i915_pci_probe+0xd/0xf [<c051aee2>] local_pci_probe+0xe/0x10 [<c051b84d>] pci_device_probe+0x46/0x69 [<c05aedd5>] driver_probe_device+0xa2/0x11d [<c05aee9c>] __driver_attach+0x4c/0x6b [<c05ae7f1>] bus_for_each_dev+0x3b/0x63 [<c05aec76>] driver_attach+0x14/0x16 [<c05ae28c>] bus_add_driver+0x98/0x1ab [<c05af033>] driver_register+0x6f/0xd3 [<c051bb3d>] __pci_register_driver+0x46/0xa5 [<c057c3f4>] drm_init+0x5b/0xb3 [<c0a39544>] i915_init+0x46/0x48 [<c0401132>] _stext+0x4a/0x111 [<c0a1e386>] kernel_init+0x17f/0x1d0 [<c0403a37>] kernel_thread_helper+0x7/0x10 [<ffffffff>] 0xffffffff -> #1 ((fb_notifier_list).rwsem){..--}: [<c04463fa>] __lock_acquire+0x1068/0x137e [<c044676e>] lock_acquire+0x5e/0x7a [<c07c98db>] down_read+0x2a/0x3e [<c043ad0a>] __blocking_notifier_call_chain+0x24/0x4c [<c043ad3e>] blocking_notifier_call_chain+0xc/0xe [<c05283fd>] fb_notifier_call_chain+0x11/0x13 [<c0529198>] register_framebuffer+0x1e2/0x1f3 [<c05a01b6>] intelfb_probe+0x491/0x4fb [<c0586cc5>] drm_helper_initial_config+0x148/0x152 [<c05902b5>] i915_driver_load+0x8b2/0x912 [<c057fb7b>] drm_get_dev+0x343/0x405 [<c07b6741>] i915_pci_probe+0xd/0xf [<c051aee2>] local_pci_probe+0xe/0x10 [<c051b84d>] pci_device_probe+0x46/0x69 [<c05aedd5>] driver_probe_device+0xa2/0x11d [<c05aee9c>] __driver_attach+0x4c/0x6b [<c05ae7f1>] bus_for_each_dev+0x3b/0x63 [<c05aec76>] driver_attach+0x14/0x16 [<c05ae28c>] bus_add_driver+0x98/0x1ab [<c05af033>] driver_register+0x6f/0xd3 [<c051bb3d>] __pci_register_driver+0x46/0xa5 [<c057c3f4>] drm_init+0x5b/0xb3 [<c0a39544>] i915_init+0x46/0x48 [<c0401132>] _stext+0x4a/0x111 [<c0a1e386>] kernel_init+0x17f/0x1d0 [<c0403a37>] kernel_thread_helper+0x7/0x10 [<ffffffff>] 0xffffffff -> #0 (&fb_info->lock){--..}: [<c04460d9>] __lock_acquire+0xd47/0x137e [<c044676e>] lock_acquire+0x5e/0x7a [<c07c919f>] mutex_lock_nested+0xe0/0x267 [<c05288bc>] fb_mmap+0x83/0x153 [<c0473ab7>] mmap_region+0x21c/0x3ab [<c0473e96>] do_mmap_pgoff+0x250/0x2a2 [<c0406a52>] sys_mmap2+0x5a/0x7b [<c0403202>] syscall_call+0x7/0xb [<ffffffff>] 0xffffffff other info that might help us debug this: 1 lock held by plymouthd/746: #0: (&mm->mmap_sem){----}, at: [<c0406a3c>] sys_mmap2+0x44/0x7b stack backtrace: Pid: 746, comm: plymouthd Not tainted 2.6.29.5-191.eeepc.fc11.i686.PAE #1 Call Trace: [<c07c7b14>] ? printk+0xf/0x11 [<c0445054>] print_circular_bug_tail+0xab/0xb6 [<c04460d9>] __lock_acquire+0xd47/0x137e [<c05288bc>] ? fb_mmap+0x83/0x153 [<c044676e>] lock_acquire+0x5e/0x7a [<c05288bc>] ? fb_mmap+0x83/0x153 [<c07c919f>] mutex_lock_nested+0xe0/0x267 [<c05288bc>] ? fb_mmap+0x83/0x153 [<c05288bc>] ? fb_mmap+0x83/0x153 [<c05288bc>] fb_mmap+0x83/0x153 [<c0473ab7>] mmap_region+0x21c/0x3ab [<c0473e96>] do_mmap_pgoff+0x250/0x2a2 [<c0406a52>] sys_mmap2+0x5a/0x7b [<c0403202>] syscall_call+0x7/0xb Any ideas what could be causing this and how to solve it? Ahmad ________________________________ From: Ahmad Al-Yaman <ahmad221284(a)yahoo.com> To: Dave Airlie <airlied(a)redhat.com> Cc: fedora-kernel-list(a)redhat.com Sent: Tuesday, July 7, 2009 12:53:23 AM Subject: Re: Fw: Kernel Loading Sequence I just checked and quiet is not missing. As for the patches adding that output, I highly doubt it since none of them has an output and they're quite simple, they adjust a few things in some drivers, nothing major. Besides, the messages are displayed before "Welcome to Fedora init", if the problem was with the patches, shouldn't the messages come up after that? Ahmad ________________________________ From: Dave Airlie <airlied(a)redhat.com> To: Ahmad Al-Yaman <ahmad221284(a)yahoo.com> Cc: fedora-kernel-list(a)redhat.com Sent: Tuesday, July 7, 2009 12:17:46 AM Subject: Re: Fw: Kernel Loading Sequence On Mon, 2009-07-06 at 13:39 -0700, Ahmad Al-Yaman wrote: > It's an F11 kernel + my patches. I obtained the SRPM from koji, added a couple of patches, and modified the config file to suit my hardware. Either got quiet missing or some of the patches add output that doesn't respect quiet. Dave. > > > > ----- Forwarded Message ---- > From: Jarod Wilson <jarod(a)redhat.com> > To: fedora-kernel-list(a)redhat.com > Sent: Monday, July 6, 2009 10:59:15 PM > Subject: Re: Kernel Loading Sequence > > On Monday 06 July 2009 11:57:47 Ahmad Al-Yaman wrote: > > Hi all, > > > > I came across a problem when trying to compile a custom kernel for F11: both the stock kernel and my custom kernel have i915 modesetting enabled by default. In the stock kernel the loading screen starts up immediately when the kernel starts loading, but using the custom kernel, some text is displayed before the loading screen starts up (the kernel finishes loading without problems). I'm trying to figure out the reason for this and if there's a way to fix it so that the user doesn't see this text. Could the reason be the order in which different parts of the kernel are loaded? If yes, how can I control which parts load first? > > Is your 'custom kernel' an F11 kernel + your patches, or starting from > an upstream tarball + your patches? (In which case, its lacking all the > patches Fedora has added, and therein probably lies your answer to why > things are behaving differently). > > > _______________________________________________ Fedora-kernel-list mailing list Fedora-kernel-list(a)redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list

3 5

Two kernels on a SINGLE machine
by real yr 13 Jul '09

13 Jul '09

There is a smp-machine, I want to run two kernels on this machine. For example, I want to split the cpus and others resources( if needed) into two collections: Collection A and Collection B. In Collection A, I run a linux kernel, and in Collection B, I load another linux kernel. I don't know if this is right. Thanks in advance.

1 0

[PATCH] NFS V4 - Dynamic Pseudo Root
by Steve Dickson 07 Jul '09

07 Jul '09

Hey, I would like to apply the following patch to the rawhide kernel that will make exports for NFS v4 mount work just list exports for v3 and v2 mounts. In a nutshell, for NFS v4 mounts to work like v3/2 mounts the '/ *(ro,fsid=0)' entry has to be added to the /etc/exports file. This patch eliminates the need for that entry. The history, reasoning and evolution of this patch can be found at: http://linux-nfs.org/pipermail/nfsv4/2009-June/010724.html Over the weekend, I pounded on this code with 4 clients continuously running the cthon test suite, which tests every part of the protocol including mounting... In the end, this is the first major step toward making NFS v4 the default protocol. steved. Date: Tue Jul 7, 2009 Author: Steve Dickson Kernel support needed to implement dynamic pseudo root support which will allow v3 and v2 exports accessible to NFS v4 clients without any configuration changes. Signed-Off-By: Steve Dickson <steved(a)redhat.com> ---------------------------------------------------- diff -up linux-2.6.30.noarch/fs/nfsd/export.c.save linux-2.6.30.noarch/fs/nfsd/export.c --- linux-2.6.30.noarch/fs/nfsd/export.c.save 2009-07-02 11:34:38.000000000 -0400 +++ linux-2.6.30.noarch/fs/nfsd/export.c 2009-07-02 11:35:44.000000000 -0400 @@ -104,6 +104,7 @@ static int expkey_parse(struct cache_det if (mesg[mlen-1] != '\n') return -EINVAL; mesg[mlen-1] = 0; + dprintk("expkey_parse: '%s'\n", mesg); buf = kmalloc(PAGE_SIZE, GFP_KERNEL); err = -ENOMEM; @@ -181,6 +182,8 @@ static int expkey_parse(struct cache_det if (dom) auth_domain_put(dom); kfree(buf); + if (err) + dprintk("expkey_parse: err %d\n", err); return err; } @@ -351,7 +354,10 @@ static void svc_export_request(struct ca (*bpp)[0] = '\n'; return; } + qword_add(bpp, blen, pth); + dprintk("svc_export_request: pth %s\n", pth); + (*bpp)[-1] = '\n'; } @@ -500,6 +506,7 @@ static int svc_export_parse(struct cache if (mesg[mlen-1] != '\n') return -EINVAL; mesg[mlen-1] = 0; + dprintk("svc_export_parse: '%s'\n", mesg); buf = kmalloc(PAGE_SIZE, GFP_KERNEL); if (!buf) @@ -619,6 +626,8 @@ out1: auth_domain_put(dom); out: kfree(buf); + if (err) + dprintk("svc_export_parse: err %d\n", err); return err; } @@ -1413,6 +1422,7 @@ static struct flags { { NFSEXP_CROSSMOUNT, {"crossmnt", ""}}, { NFSEXP_NOSUBTREECHECK, {"no_subtree_check", ""}}, { NFSEXP_NOAUTHNLM, {"insecure_locks", ""}}, + { NFSEXP_V4ROOT, {"v4root", ""}}, #ifdef MSNFS { NFSEXP_MSNFS, {"msnfs", ""}}, #endif @@ -1493,7 +1503,7 @@ static int e_show(struct seq_file *m, vo struct svc_export *exp = container_of(cp, struct svc_export, h); if (p == SEQ_START_TOKEN) { - seq_puts(m, "# Version 1.1\n"); + seq_puts(m, "# Version 1.2\n"); seq_puts(m, "# Path Client(Flags) # IPs\n"); return 0; } diff -up linux-2.6.30.noarch/fs/nfsd/nfs4xdr.c.save linux-2.6.30.noarch/fs/nfsd/nfs4xdr.c --- linux-2.6.30.noarch/fs/nfsd/nfs4xdr.c.save 2009-07-02 11:34:38.000000000 -0400 +++ linux-2.6.30.noarch/fs/nfsd/nfs4xdr.c 2009-07-02 11:35:31.000000000 -0400 @@ -2176,28 +2176,62 @@ static inline int attributes_need_mount( return 0; } -static __be32 -nfsd4_encode_dirent_fattr(struct nfsd4_readdir *cd, - const char *name, int namlen, __be32 *p, int *buflen) +struct dentry * +nfsd_check_export(struct nfsd4_readdir *cd, const char *name, int namlen) { struct svc_export *exp = cd->rd_fhp->fh_export; struct dentry *dentry; - __be32 nfserr; - int ignore_crossmnt = 0; + int err; dentry = lookup_one_len(name, cd->rd_fhp->fh_dentry, namlen); if (IS_ERR(dentry)) - return nfserrno(PTR_ERR(dentry)); + return dentry; if (!dentry->d_inode) { - /* - * nfsd_buffered_readdir drops the i_mutex between - * readdir and calling this callback, leaving a window - * where this directory entry could have gone away. - */ dput(dentry); - return nfserr_noent; + return ERR_PTR(-ENOENT); + } + + /* + * Check to see if this dentry is part + * of the psuedo root + */ + if ((exp->ex_flags & NFSEXP_V4ROOT) == 0) + return dentry; + + /* + * Only exported directories are visable + * on psuedo exports + */ + if (!S_ISDIR(dentry->d_inode->i_mode)) { + dput(dentry); + return ERR_PTR(-ENOENT); } + /* + * Make the upcall to see if this directory + * is exported. + */ + exp_get(exp); + err = nfsd_export_lookup(cd->rd_rqstp, dentry, exp); + if (err) { + exp_put(exp); + dput(dentry); + return ERR_PTR(err); + } + exp_put(exp); + + return dentry; +} + +static __be32 +nfsd4_encode_dirent_fattr(struct nfsd4_readdir *cd, + struct dentry *dentry, __be32 *p, int *buflen) +{ + struct svc_export *exp = cd->rd_fhp->fh_export; + __be32 nfserr; + int ignore_crossmnt = 0; + int err, v4root = (exp->ex_flags & NFSEXP_V4ROOT); + exp_get(exp); /* * In the case of a mountpoint, the client may be asking for @@ -2208,18 +2242,29 @@ nfsd4_encode_dirent_fattr(struct nfsd4_r */ if (d_mountpoint(dentry) && !attributes_need_mount(cd->rd_bmval)) ignore_crossmnt = 1; - else if (d_mountpoint(dentry)) { - int err; - + else if (d_mountpoint(dentry) || v4root) { + /* + * Make sure the dentry is viewable on the psuedo export + */ + v4root = (dentry->d_inode && v4root); + if (v4root) { + err = nfsd_export_lookup(cd->rd_rqstp, dentry, exp); + if (err) { + nfserr = nfserrno(err); + goto out_put; + } + } /* * Why the heck aren't we just using nfsd_lookup?? * Different "."/".." handling? Something else? * At least, add a comment here to explain.... */ - err = nfsd_cross_mnt(cd->rd_rqstp, &dentry, &exp); - if (err) { - nfserr = nfserrno(err); - goto out_put; + if (d_mountpoint(dentry) || v4root) { + err = nfsd_cross_mnt(cd->rd_rqstp, &dentry, &exp); + if (err) { + nfserr = nfserrno(err); + goto out_put; + } } nfserr = check_nfsd_access(exp, cd->rd_rqstp); if (nfserr) @@ -2258,6 +2303,7 @@ nfsd4_encode_dirent(void *ccdv, const ch struct readdir_cd *ccd = ccdv; struct nfsd4_readdir *cd = container_of(ccd, struct nfsd4_readdir, common); int buflen; + struct dentry *dentry; __be32 *p = cd->buffer; __be32 *cookiep; __be32 nfserr = nfserr_toosmall; @@ -2268,19 +2314,40 @@ nfsd4_encode_dirent(void *ccdv, const ch return 0; } + /* + * Do the lookup and make sure the dentry is + * visible on the exported directory + */ + dentry = nfsd_check_export(cd, name, namlen); + if (IS_ERR(dentry)) { + if (PTR_ERR(dentry) == -ENOENT) { + cd->common.err = nfs_ok; + return 0; + } + cd->common.err = nfserrno(PTR_ERR(dentry)); + return -EINVAL; + } + if (cd->offset) xdr_encode_hyper(cd->offset, (u64) offset); buflen = cd->buflen - 4 - XDR_QUADLEN(namlen); - if (buflen < 0) + if (buflen < 0) { + dput(dentry); goto fail; + } *p++ = xdr_one; /* mark entry present */ cookiep = p; p = xdr_encode_hyper(p, NFS_OFFSET_MAX); /* offset of next entry */ p = xdr_encode_array(p, name, namlen); /* name length & name */ - nfserr = nfsd4_encode_dirent_fattr(cd, name, namlen, p, &buflen); + /* + * Note: the dput() on the dentry is done in + * nfsd4_encode_dirent_fattr() since the dentry can + * change when crossing a mount point. + */ + nfserr = nfsd4_encode_dirent_fattr(cd, dentry, p, &buflen); switch (nfserr) { case nfs_ok: p += buflen; diff -up linux-2.6.30.noarch/fs/nfsd/nfsfh.c.save linux-2.6.30.noarch/fs/nfsd/nfsfh.c --- linux-2.6.30.noarch/fs/nfsd/nfsfh.c.save 2009-07-02 11:34:38.000000000 -0400 +++ linux-2.6.30.noarch/fs/nfsd/nfsfh.c 2009-07-02 11:35:48.000000000 -0400 @@ -109,6 +109,34 @@ static __be32 nfsd_setuser_and_check_por return nfserrno(nfsd_setuser(rqstp, exp)); } +static inline __be32 check_pseudo_root(struct svc_rqst *rqstp, + struct dentry *dentry, struct svc_export *exp) +{ + int error; + + /* + * Only interested in pseudo roots + */ + if (!(exp->ex_flags & NFSEXP_V4ROOT)) + return nfs_ok; + + /* + * Only directories should be on the pseudo root + */ + if (unlikely(!S_ISDIR(dentry->d_inode->i_mode))) + return nfserr_stale; + /* + * Check non-root directories to make sure + * they are truly exported + */ + if (unlikely(dentry->d_name.len > 1)) { + error = nfsd_export_lookup(rqstp, dentry, exp); + return nfserrno(error); + } + + return nfs_ok; +} + /* * Use the given filehandle to look up the corresponding export and * dentry. On success, the results are used to set fh_export and @@ -315,6 +343,14 @@ fh_verify(struct svc_rqst *rqstp, struct error = nfsd_setuser_and_check_port(rqstp, exp); if (error) goto out; + + /* + * Do some spoof checking if we are on the pseudo root + */ + error = check_pseudo_root(rqstp, dentry, exp); + if (error) + goto out; + } error = nfsd_mode_check(rqstp, dentry->d_inode->i_mode, type); diff -up linux-2.6.30.noarch/fs/nfsd/vfs.c.save linux-2.6.30.noarch/fs/nfsd/vfs.c --- linux-2.6.30.noarch/fs/nfsd/vfs.c.save 2009-07-02 11:34:38.000000000 -0400 +++ linux-2.6.30.noarch/fs/nfsd/vfs.c 2009-07-02 11:35:39.000000000 -0400 @@ -89,6 +89,12 @@ struct raparm_hbucket { #define RAPARM_HASH_MASK (RAPARM_HASH_SIZE-1) static struct raparm_hbucket raparm_hash[RAPARM_HASH_SIZE]; +static inline int +nfsd_v4client(struct svc_rqst *rq) +{ + return((rq->rq_prog == NFS_PROGRAM) && (rq->rq_vers == 4)); +} + /* * Called from nfsd_lookup and encode_dirent. Check if we have crossed * a mount point. @@ -115,7 +121,8 @@ nfsd_cross_mnt(struct svc_rqst *rqstp, s path_put(&path); goto out; } - if ((exp->ex_flags & NFSEXP_CROSSMOUNT) || EX_NOHIDE(exp2)) { + if (nfsd_v4client(rqstp) || + (exp->ex_flags & NFSEXP_CROSSMOUNT) || EX_NOHIDE(exp2)) { /* successfully crossed mount point */ /* * This is subtle: path.dentry is *not* on path.mnt @@ -134,6 +141,55 @@ out: return err; } +/* + * Lookup the export the dentry is on. To be + * viewable on an pseudo export, the dentry + * has to be an exported directory. + */ +int +nfsd_export_lookup(struct svc_rqst *rqstp, struct dentry *dentry, + struct svc_export *exp) +{ + struct svc_export *exp2 = NULL; + struct path path; + int err = 0; + + if ((exp->ex_flags & NFSEXP_V4ROOT) == 0) + return 0; + + /* + * Make sure the export is the parent of the dentry + */ + if (dentry->d_parent != exp->ex_path.dentry) + return 0; + + /* + * Only directories are seen on psuedo exports + */ + if (!S_ISDIR(dentry->d_inode->i_mode)) + return -ENOENT; + + /* + * Make the upcall + */ + path.mnt = mntget(exp->ex_path.mnt); + path.dentry = dget(dentry); + while (d_mountpoint(path.dentry) && follow_down(&path)); + + exp2 = rqst_exp_get_by_name(rqstp, &path); + if (IS_ERR(exp2)) + err = PTR_ERR(exp2); + else { + /* + * The export exist so allow the access + */ + exp_put(exp2); + } + + dput(path.dentry); + mntput(path.mnt); + return err; +} __be32 nfsd_lookup_dentry(struct svc_rqst *rqstp, struct svc_fh *fhp, const char *name, unsigned int len, @@ -143,7 +199,7 @@ nfsd_lookup_dentry(struct svc_rqst *rqst struct dentry *dparent; struct dentry *dentry; __be32 err; - int host_err; + int host_err, v4root; dprintk("nfsd: nfsd_lookup(fh %s, %.*s)\n", SVCFH_fmt(fhp), len,name); @@ -155,6 +211,7 @@ nfsd_lookup_dentry(struct svc_rqst *rqst dparent = fhp->fh_dentry; exp = fhp->fh_export; exp_get(exp); + v4root = (exp->ex_flags & NFSEXP_V4ROOT); /* Lookup the name, but don't follow links */ if (isdotent(name, len)) { @@ -199,9 +256,21 @@ nfsd_lookup_dentry(struct svc_rqst *rqst if (IS_ERR(dentry)) goto out_nfserr; /* + * The export is a pseudo one, make sure the + * dentry is accessible + */ + v4root = (dentry->d_inode && v4root); + if (v4root) { + host_err = nfsd_export_lookup(rqstp, dentry, exp); + if (host_err) { + dput(dentry); + goto out_nfserr; + } + } + /* * check if we have crossed a mount point ... */ - if (d_mountpoint(dentry)) { + if (d_mountpoint(dentry) || v4root) { if ((host_err = nfsd_cross_mnt(rqstp, &dentry, &exp))) { dput(dentry); goto out_nfserr; diff -up linux-2.6.30.noarch/include/linux/nfsd/export.h.save linux-2.6.30.noarch/include/linux/nfsd/export.h --- linux-2.6.30.noarch/include/linux/nfsd/export.h.save 2009-07-02 11:34:38.000000000 -0400 +++ linux-2.6.30.noarch/include/linux/nfsd/export.h 2009-07-02 11:35:22.000000000 -0400 @@ -39,7 +39,8 @@ #define NFSEXP_FSID 0x2000 #define NFSEXP_CROSSMOUNT 0x4000 #define NFSEXP_NOACL 0x8000 /* reserved for possible ACL related use */ -#define NFSEXP_ALLFLAGS 0xFE3F +#define NFSEXP_V4ROOT 0x10000 +#define NFSEXP_ALLFLAGS 0x1FE3F /* The flags that may vary depending on security flavor: */ #define NFSEXP_SECINFO_FLAGS (NFSEXP_READONLY | NFSEXP_ROOTSQUASH \ diff -up linux-2.6.30.noarch/include/linux/nfsd/nfsd.h.save linux-2.6.30.noarch/include/linux/nfsd/nfsd.h --- linux-2.6.30.noarch/include/linux/nfsd/nfsd.h.save 2009-07-02 11:34:38.000000000 -0400 +++ linux-2.6.30.noarch/include/linux/nfsd/nfsd.h 2009-07-02 11:35:27.000000000 -0400 @@ -76,6 +76,8 @@ int nfsd_racache_init(int); void nfsd_racache_shutdown(void); int nfsd_cross_mnt(struct svc_rqst *rqstp, struct dentry **dpp, struct svc_export **expp); +int nfsd_export_lookup(struct svc_rqst *rqstp, struct dentry *dpp, + struct svc_export *exp); __be32 nfsd_lookup(struct svc_rqst *, struct svc_fh *, const char *, unsigned int, struct svc_fh *); __be32 nfsd_lookup_dentry(struct svc_rqst *, struct svc_fh *,

2 2

Kernel Loading Sequence
by Ahmad Al-Yaman 06 Jul '09

06 Jul '09

Hi all, I came across a problem when trying to compile a custom kernel for F11: both the stock kernel and my custom kernel have i915 modesetting enabled by default. In the stock kernel the loading screen starts up immediately when the kernel starts loading, but using the custom kernel, some text is displayed before the loading screen starts up (the kernel finishes loading without problems). I'm trying to figure out the reason for this and if there's a way to fix it so that the user doesn't see this text. Could the reason be the order in which different parts of the kernel are loaded? If yes, how can I control which parts load first? I tried to see the text or find it in one of the logs in order to give a more complete description of the problem but I couldn't, so if anyone has a tip on how or where I can find it (in case it's relevant to the solution) I'd highly appreciate it. Thank you.

3 4

Re: Time for 2.6.30 in F-11?
by Thorsten Leemhuis 05 Jul '09

05 Jul '09

CCing #fedora-kernel-list On 04.07.2009 16:12, Kevin Kofler wrote: > Bojan Smojver wrote: >> Now that .1 is out, is there anything in particular stopping F-11 from >> having this kernel? > And why is F10 still stuck on 2.6.27? 2.6.29 has been in updates-testing for > ages now. Good question. Seems the "ship state-of-the-art/nearly latest kernel versions from kernel.org as regular update for Fedora" worked much better in the past. Is that for a specific reason or just a side effect of something (maintainer/responsibly changes maybe?). And yes, I know it's a lot of work to prepare updates from 2.6.x.y to 2.6.(x+1).y. So thx for that work -- it IMHO is definitely worth it as it makes people get drivers for new hardware without forcing them to switch to rawhide. That, btw and afaics, for quite some people was one of the reasons to chose Fedora. I for example use Fedora for testing at work mainly because I got latest kernels on Fedora automatically. Cu knurd

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel July 2009