Re: CVS commit: src/sys/ufs/ufs
Hi David Holland: I'm not entirely clear on how this structure is actually used, which is why I hadn't yet made this change myself after the issue came up. :-/ My observation in sys/fs/cd9660 is probably the initial cause for this change. PR kern/48799. I could produce a problem by exporting to NFS an ISO-9960 filesystem which gets 64-bit inodes due to high storage loacations of its directory records. NFS uses these structs to identify files in the original filesystem. cd9660 then uses the struct ifid member ifid_ino to fulfill this wish ... if no 32-bit bottleneck prevents it. So if the fix in ufs causes problems, could you please also have a look at the fix of kern/48799 ? Have a nice day :) Thomas
Re: CVS commit: src/sys/ufs/ufs
On Fri, May 16, 2014 at 12:12:00AM +0200, Joerg Sonnenberger wrote: I don't think it is a problem by itself as the file handle is opaque, but it is certainly wasteful to not put ufid_ino first. That is not possible, the first few bytes of the structure must match struct fid from fstypes.h. The structure is only used to construct opaque tokens for filehandles, and the encoding includes the size, so I see no problem. Indeed rebooting with an updated kernel will give active NFS clients problems, but I am not sure we should realy care nor how we could possibly avoid this one time issue. We have changed encoding of filehandles before (at least once). Martin
Re: CVS commit: src
On 05/16/14 01:48, Mindaugas Rasiukevicius wrote: Module Name:src Committed By: rmind Date: Fri May 16 00:48:41 UTC 2014 Modified Files: src/share/man/man9: pcu.9 src/sys/arch/alpha/alpha: fp_complete.c src/sys/arch/alpha/include: alpha.h src/sys/arch/amd64/amd64: locore.S src/sys/arch/arm/vfp: vfp_init.c src/sys/arch/mips/mips: mips_dsp.c mips_fpu.c src/sys/arch/powerpc/booke: spe.c src/sys/arch/powerpc/oea: altivec.c src/sys/arch/powerpc/powerpc: fpu.c src/sys/kern: subr_pcu.c src/sys/sys: pcu.h Log Message: pcu(9): - Remove PCU_KERNEL (hi matt!) and significantly simplify the code. This experimental feature was tried on ARM did not meet the expectations. It may be revived one day, but it should be done in a much simpler way. - Add a message structure for xcall function, pass the LWP ower and thus optimise a race condition: if LWP is discarding its state on a remote CPU, but another LWP already did it - do not cause an unecessary re-faulting. - Reduce the variety of flags for PCU operations (only PCU_VALID and PCU_REENABLE are used now), pass them only to the pcu_state_load(). - Rename pcu_used_p() to pcu_valid_p(); hopefully it is less confusing. - pcu_save_all_on_cpu: SPL ought to be used here. - Update and improve the pcu(9) man page; it needs wizd(8) though. I think you forgot the lwp.h change. Nick
Re: CVS commit: src/sys/ufs/ufs
On Fri, May 16, 2014 at 03:54:44PM +, David Holland wrote: Indeed rebooting with an updated kernel will give active NFS clients problems, but I am not sure we should realy care nor how we could possibly avoid this one time issue. We have changed encoding of filehandles before (at least once). I don't think this is a problem, but maybe I'll put a note in UPDATING. Never mind that problem. Consider what happens if you reboot with a different CD in the drive! I once fixed a filesystem to use different faked inode numbers every time a filesystem was mounted. Without that NFS clients would write to the wrong file in the wrong FS. The 'impossible to get rid of' retries for hard mounts were something up with which I had to put. (A preposition is something you should not end a sentence with.) David -- David Laight: da...@l8s.co.uk
Re: CVS commit: src/sys/ufs/ufs
On Fri, May 16, 2014 at 06:48:06PM +, Martin Husemann wrote: The problem is that the tokens are memcmp'd, so if they include struct padding this may not work. All filesystems I've seen init the struct with a full memset to 0, so all padding fields should be initialized as well. Ok, but... However, we can swap the last two fields in the ufid case, if you prefer. ...may as well, I guess. -- David A. Holland dholl...@netbsd.org
