[PATCH 0/3] iwl3945 driver fixes for Fedora 11 (2.6.29)
by Stanislaw Gruszka
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.
14 years, 7 months
Re: [PATCH] build a 'full' package on i686
by Quentin Armitage
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
14 years, 8 months
ASPM enabled by default - mild potential for breakage
by Matthew Garrett
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
14 years, 8 months
Re: Fw: Kernel Loading Sequence
by Ahmad Al-Yaman
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
14 years, 8 months
Two kernels on a SINGLE machine
by real yr
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.
14 years, 8 months
[PATCH] NFS V4 - Dynamic Pseudo Root
by Steve Dickson
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 *,
14 years, 8 months
Kernel Loading Sequence
by Ahmad Al-Yaman
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.
14 years, 8 months
Re: Time for 2.6.30 in F-11?
by Thorsten Leemhuis
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
14 years, 8 months