headers
Neil Brown | 1 Mar 2005 05:53
X-Face
Picon
Picon
Favicon

Re: [PATCH 33 of 52] nfsd4: nfs4_cb_recall cleanup

On Thursday February 24, bfields <at> fieldses.org wrote:
> 
> Miscellaneous cleanup including:
> 	remove recursion
> 	use a local variable instead of dl_recall_cnt

While this is probably a lot better than it was, I feel it is still a
bit too clumsy....
> +	do {
> +		status = rpc_call_sync(clnt, &msg, RPC_TASK_SOFT);
> +		switch (status) {
> +		case 0:
> +			goto out;
> +		case -EIO:
> +			/* Network partition? */
> +			if (retries == 0) {
> +				atomic_set(&clp->cl_callback.cb_set, 0);
> +				goto out;
> +			}
> +			break;
> +		case -EBADHANDLE:
> +		case -NFS4ERR_BAD_STATEID:
> +			if (retries == 0)
> +				goto out;
> +			/* The client may have gotten the recall before the
> +			 * original delegation. */
> +			break;
> +		default:
> +			goto out;
> +		}
(Continue reading)

Permalink | Reply | 2 comments |
headers
Martin Orr | 1 Mar 2005 09:46

Segfault in svcgssd

I am running an up-to-date Debian unstable system, with a vanilla 2.6.10
kernel and NFS userspace utilities from
deb http://www.citi.umich.edu/projects/nfsv4/debian unstable main

I can set up an export, mount it and access it fine without Kerberos.
If I enable Kerberos, I can still mount it fine but attempts to access it as
non-root cause svcgssd to segfault (not always but very often).

Looking at the code in nfs-utils-1.0.7.nfsv4/utils/svcgssd/svcgssd_proc.c, I
saw that cred->cr_ngroups is not set to a value before calling
nfs4_gss_princ_to_grouplist in add_supplementary_groups.  Inserting
	    cred->cr_ngroups = NGROUPS;
before this call has fixed the segfault.

This may also be related to the mention in the getgrouplist manpage that
"The glibc 2.3.2 implementation of this function  is  broken:  it  over-
 writes memory when the actual number of groups is larger than *ngroups."

--

-- 
Martin Orr
Linux Administrator,
Methodist College Belfast
Permalink | Reply | 0 comments |
headers
David Howells | 1 Mar 2005 17:04
Picon
Favicon

[PATCH] Properly share process and session keyrings with CLONE_THREAD [try #2]


The attached patch causes process and session keyrings to be shared properly
when CLONE_THREAD is in force. It does this by moving the keyring pointers
into struct signal_struct[*].

[*] I have a patch to rename this to struct thread_group that I'll revisit
after the advent of 2.6.11.

Furthermore, once this patch is applied, process keyrings will no longer be
allocated at fork, but will instead only be allocated when needed. Allocating
them at fork was a way of half getting around the sharing across threads
problem, but that's no longer necessary.

This revision of the patch has the documentation changes patch rolled into it
and no longer abstracts the locking for signal_struct into a pair of macros.

Signed-Off-By: David Howells <dhowells <at> redhat.com>
---
warthog>diffstat -p1 keys-task-2611rc4-2.diff 
 Documentation/keys.txt       |    4 
 include/linux/key.h          |    5 +
 include/linux/sched.h        |    9 +-
 init/main.c                  |    2 
 kernel/fork.c                |    8 +
 kernel/signal.c              |    1 
 security/keys/process_keys.c |  175 ++++++++++++++++++++++++-------------------
 security/keys/request_key.c  |   46 ++++++++---
 8 files changed, 158 insertions(+), 92 deletions(-)

diff -uNr linux-2.6.11-rc4/Documentation/keys.txt linux-2.6.11-rc4-keys-task/Documentation/keys.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
J. Bruce Fields | 1 Mar 2005 21:18

linux-2.6.11-rc5-CITI_NFS4_ALL-3

http://www.citi.umich.edu/projects/nfsv4/linux/kernel-patches/2.6.11-rc5-3/
Changes since 2.6.11-rc5-CITI_NFS4_ALL-2
	* update to Trond's latest NFS_ALL
	* privacy updates

--b.
Permalink | Reply | 9 comments |
headers
Bryce Harrington | 2 Mar 2005 00:40

Re: linux-2.6.11-rc5-CITI_NFS4_ALL-3

On Tue, 1 Mar 2005, J. Bruce Fields wrote:

> http://www.citi.umich.edu/projects/nfsv4/linux/kernel-patches/2.6.11-rc5-3/
> Changes since 2.6.11-rc5-CITI_NFS4_ALL-2
> 	* update to Trond's latest NFS_ALL
> 	* privacy updates

Cross compile results look good:

http://osdl.org/plm-cgi/plm?module=patch_info&patch_id=4234

This looks fairly clean compared to the rc5 kernel.  Same PASS/FAIL's.
For warnings, mainly some strange random stuff that is probably not very
important.

On the PPC x40:

 *** Warning: "device_is_compatible" [sound/ppc/snd-powermac.ko]
     undefined!
 *** Warning: "find_devices" [sound/ppc/snd-powermac.ko] undefined!
 *** Warning: "free_dma" [drivers/block/floppy.ko] undefined!
 *** Warning: "get_property" [sound/ppc/snd-powermac.ko] undefined!
 *** Warning: "machine_is_compatible" [sound/ppc/snd-powermac.ko]
     undefined!
 *** Warning: "release_OF_resource" [sound/ppc/snd-powermac.ko]
     undefined!
 *** Warning: "request_OF_resource" [sound/ppc/snd-powermac.ko]
     undefined!
 *** Warning: "request_dma" [drivers/block/floppy.ko] undefined!
(Continue reading)

Permalink | Reply | 0 comments |
headers
J. Bruce Fields | 2 Mar 2005 02:49

Re: [PATCH 33 of 52] nfsd4: nfs4_cb_recall cleanup

On Tue, Mar 01, 2005 at 03:53:45PM +1100, Neil Brown wrote:
> The 'while (retries--)' at the bottom is guaranteed to succeed as we
> never get there if retries == 0, so the logic is confusing.

Yeah, I agree.

> I would rather cast it something like:
> 
>  while (
>         ( (status = rpc_call_sync(...))  == -EIO || /* network  partition? */
>           status == -EBADHANDLE ||        /* The client may have received the recall.. */
>           status == -NFS4ERR_BAD_STATEID) /* .. before the original delegation */
>        && retries) {
> 		set_current_state();
> 		schedule_timeout();
> 		retries--;
>    }
> 
>   if (status == -EIO) atomic_set(..., 0);
> 
> Is that any clearer to you?

Yes.  But the complex conditional with interspersed comments is a bit
hairy.  How about the following?

This is a drop-in replacement for the original patch.  The subsequent
patches in the series still apply cleanly (if occasionally offset by a
line or two).

--b.
(Continue reading)

Permalink | Reply | 1 comment |
headers
J. Bruce Fields | 2 Mar 2005 02:59

Re: [PATCH 33 of 52] nfsd4: nfs4_cb_recall cleanup

On Tue, Mar 01, 2005 at 08:49:49PM -0500, J. Bruce Fields wrote:
> Yes.  But the complex conditional with interspersed comments is a bit
> hairy.  How about the following?
> 
> This is a drop-in replacement for the original patch.  The subsequent
> patches in the series still apply cleanly (if occasionally offset by a
> line or two).

(Oh, and note I'm also taking Nishanth Aravamudan's suggestion of
converting the schedule_timeout to a ssleep.)

> --b.
> 
> Miscellaneous cleanup including:
> 	remove recursion
> 	use a local variable instead of dl_recall_cnt
> 
> Signed-off-by: J. Bruce Fields <bfields <at> citi.umich.edu>
> ---
> 
>  linux-2.6.11-rc5-bfields/fs/nfsd/nfs4callback.c |   88 +++++++++---------------
>  1 files changed, 33 insertions(+), 55 deletions(-)
> 
> diff -puN fs/nfsd/nfs4callback.c~nfsd4-callback-cleanup fs/nfsd/nfs4callback.c
> --- linux-2.6.11-rc5/fs/nfsd/nfs4callback.c~nfsd4-callback-cleanup	2005-03-01
17:04:36.000000000 -0500
> +++ linux-2.6.11-rc5-bfields/fs/nfsd/nfs4callback.c	2005-03-01 20:45:56.000000000 -0500
>  <at>  <at>  -38,6 +38,7  <at>  <at> 
>  #include <linux/list.h>
>  #include <linux/inet.h>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bryce Harrington | 2 Mar 2005 03:13

NFSv4 on SuSE 9.2 - no workie


I've been unable to get an nfsv4 server established on SuSE 9.2, and
don't know how to figure out exactly where it's failing.  I tested it
on three different kernels with the same results (2.6.10, 2.6.11-rc5,
2.6.11-rc5-CITI_NFS4_ALL-1).  I've doublechecked my installation
procedure against the documentation at the CITI site, and cannot find a
configuration problem.

Kevin suggests that even if this problem is solved, the heimdal krb5
code will probably exhibit other issues in the gssapi library.

I'm concluding that NFSv4 cannot be used on SuSE 9.2 at this time.  I
may try gentoo or debian when I get back to the office.

Bryce
Permalink | Reply | 0 comments |
headers
Bryce Harrington | 2 Mar 2005 03:34

OOPS on SuSE 9.2

Hi Bruce,

Here's the oops and asm dump for this bug:

Mar  1 16:09:23 linux rpc.gssd[8923]: processing client list
Mar  1 16:09:23 linux rpc.gssd[8936]: processing client list
Mar  1 16:09:23 linux kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000008
Mar  1 16:09:23 linux kernel:  printing eip:
Mar  1 16:09:23 linux kernel: c016800e
Mar  1 16:09:23 linux kernel: *pde = 00000000
Mar  1 16:09:23 linux kernel: Oops: 0000 [#1]
Mar  1 16:09:23 linux kernel: Modules linked in: nvram usbserial parport_pc lp parport speedstep_lib
freq_table processor snd_pcm_oss snd_mixer_oss snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd
soundcore snd_page_alloc ipt_TOS ipt_LOG ipt_limit ipt_pkttype edd ipt_state ipt_REJECT
iptable_mangle iptable_filter ip6table_mangle ip_nat_ftp iptable_nat ip_conntrack_ftp
ip_conntrack ip_tables ip6table_filter ip6_tables ipv6 joydev sg st sd_mod sr_mod scsi_mod ide_cd
cdrom uhci_hcd ehci_hcd i2c_i801 i2c_core intel_agp agpgart nfsd exportfs evdev dm_mod usbcore e1000 reiserfs
Mar  1 16:09:23 linux kernel: CPU:    0
Mar  1 16:09:23 linux kernel: EIP:    0060:[<c016800e>]    Not tainted VLI
Mar  1 16:09:23 linux kernel: EFLAGS: 00010293   (2.6.11-rc5-CITI_NFS4_ALL-1)
Mar  1 16:09:23 linux kernel: EIP is at do_add_mount+0x7e/0x120
Mar  1 16:09:23 linux kernel: eax: 00000000   ebx: eb4dbf50   ecx: 00000000   edx: dfff4c80
Mar  1 16:09:23 linux kernel: esi: dfff4c00   edi: ffffffea   ebp: 00000000   esp: eb4dbf20
Mar  1 16:09:23 linux kernel: ds: 007b   es: 007b   ss: 0068
Mar  1 16:09:23 linux kernel: Process nfs4-mount (pid: 8942, threadinfo=eb4da000 task=ee244aa0)
Mar  1 16:09:23 linux kernel: Stack: 00000000 eb4ca000 ebc9a000 eb4dbf50 00000000 c016857d 00000000 eb4ca000
Mar  1 16:09:23 linux kernel:        ebc9a000 00000000 ed8dd000 eb4ca000 eb4cbc8c dfff4c80 00000000 000000d0
Mar  1 16:09:23 linux kernel:        c0138858 00000001 00000001 00000000 00000010 c0370a8c 00000000 eb6863a4
Mar  1 16:09:23 linux kernel: Call Trace:
Mar  1 16:09:23 linux kernel:  [<c016857d>] do_mount+0x18d/0x1c0
(Continue reading)

Permalink | Reply | 7 comments |
headers
Marco Fais | 2 Mar 2005 15:37
Picon

Newbie with mapping problem

Hi,
first of all sorry for my bad english.

I'm trying to run NFSv4 with kerberos authentication but I've
encountered one problem mapping the users.
My system is configured as follows:
- MIT kerberos 1.3.3
- OpenLDAP 2.2.11
- Kernel 2.6.9 (not patched)
- nfs-utils-1.0.7pre2
I've installed nfsv4 following the instruction in the CITI pages.
Server and client are running in the same machine.

Essentially, the problem is that the directory is mounted even if the
user doesn't has the krb5 ticket. The result of the mount (with or
without ticket) is that user (root) is always mapped to nobody.
[root <at> guardian:~]#mount -tnfs4 -osec=krb5 guardian:/ /mnt/nfs/
[root <at> guardian:~]# ls /mnt/ -l
total 0
drwxrwxrwx  5 root nobody 120 2005-03-01 18:32 nfs/
[root <at> guardian:~]# ls /mnt/nfs/ -l
total 0
drwxr-xr-x  2 nobody nobody 72 2005-03-01 13:14 prova/
drwxr-xr-x  2 nobody nobody 48 2005-02-25 16:31 test/

During this operation, services shows these messages:

[root <at> guardian:~/logmount]# cat svcgssd.log 
can't open SAPI: SAPI: cannot open shared object file: No such file or directory
WARNING: unable to locate function krb5_gss_internal_release_oid in
(Continue reading)

Permalink | Reply | 2 comments |

Gmane