Changeset View
Standalone View
sys/fs/tmpfs/tmpfs.h
| Show First 20 Lines • Show All 210 Lines • ▼ Show 20 Lines | struct tmpfs_node { | ||||
| gid_t tn_gid; /* (v) */ | gid_t tn_gid; /* (v) */ | ||||
| mode_t tn_mode; /* (v) */ | mode_t tn_mode; /* (v) */ | ||||
| int tn_links; /* (v) */ | int tn_links; /* (v) */ | ||||
| u_long tn_flags; /* (v) */ | u_long tn_flags; /* (v) */ | ||||
| struct timespec tn_atime; /* (vi) */ | struct timespec tn_atime; /* (vi) */ | ||||
| struct timespec tn_mtime; /* (vi) */ | struct timespec tn_mtime; /* (vi) */ | ||||
| struct timespec tn_ctime; /* (vi) */ | struct timespec tn_ctime; /* (vi) */ | ||||
| struct timespec tn_birthtime; /* (v) */ | struct timespec tn_birthtime; /* (v) */ | ||||
| unsigned long tn_gen; /* (c) */ | unsigned int tn_gen; /* (c) */ | ||||
rmacklem: Although this field is initialized by arc4random(),
it is also incremented.
--> Having it… | |||||
| /* | /* | ||||
| * As there is a single vnode for each active file within the | * As there is a single vnode for each active file within the | ||||
| * system, care has to be taken to avoid allocating more than one | * system, care has to be taken to avoid allocating more than one | ||||
| * vnode per file. In order to do this, a bidirectional association | * vnode per file. In order to do this, a bidirectional association | ||||
| * is kept between vnodes and nodes. | * is kept between vnodes and nodes. | ||||
| * | * | ||||
| * Whenever a vnode is allocated, its v_data field is updated to | * Whenever a vnode is allocated, its v_data field is updated to | ||||
| ▲ Show 20 Lines • Show All 215 Lines • ▼ Show 20 Lines | |||||
| #define TMPFS_UNLOCK(tm) mtx_unlock(&(tm)->tm_allnode_lock) | #define TMPFS_UNLOCK(tm) mtx_unlock(&(tm)->tm_allnode_lock) | ||||
| #define TMPFS_MP_ASSERT_LOCKED(tm) mtx_assert(&(tm)->tm_allnode_lock, MA_OWNED) | #define TMPFS_MP_ASSERT_LOCKED(tm) mtx_assert(&(tm)->tm_allnode_lock, MA_OWNED) | ||||
| /* | /* | ||||
| * This structure maps a file identifier to a tmpfs node. Used by the | * This structure maps a file identifier to a tmpfs node. Used by the | ||||
| * NFS code. | * NFS code. | ||||
| */ | */ | ||||
| struct tmpfs_fid_data { | struct tmpfs_fid_data { | ||||
| unsigned short tfd_len; | |||||
markjUnsubmitted Done Inline ActionsI would suggest adding an explicit pad field here, like the generic structure. markj: I would suggest adding an explicit pad field here, like the generic structure. | |||||
olceAuthorUnsubmitted Done Inline ActionsStructure is now packed. That said, I'd really want to simply remove the padding field fid_data0 of struct fid, enlarging fid_data to compensate, with the aim to really give freedom to FS about the content (going further, I'd remove also fid_len). Strictly speaking, this is an API break (but not an ABI one), but maybe it would still be acceptable to MFC it as nobody is supposed to ever use fid_data0 directly? olce: Structure is now packed. That said, I'd really want to simply remove the padding field… | |||||
markjUnsubmitted Done Inline ActionsI don't have strong feelings about it. tmpfs filesystems are ephemeral, so probably are not commonly NFS-exported, and clients will need to remount them if the server reboots anyway. So, some of the downsides of changing the layout aren't really relevant for tmpfs. But, as I understand, this change does not fix any extant bug, so might not be worth the risk of merging to a stable branch. markj: I don't have strong feelings about it. tmpfs filesystems are ephemeral, so probably are not… | |||||
olceAuthorUnsubmitted Done Inline ActionsMmm... It seems the risks are quite low (changes are very limited; there might be compiler bugs). I can for example avoid MFCing this revision to stable/13, as the code slush is approaching for 13.5. With the risk assessment written above in mind, I don't see much reason not to MFC to stable/13 after 13.5's branch and to stable/14 relatively soon as the next release from it is far away. I'll be personally testing the patch on stable/14 at the beginning of January. Or do you think the risk assessment above is incomplete or too optimistic? olce: Mmm... It seems the risks are quite low (changes are very limited; there might be compiler… | |||||
markjUnsubmitted Not Done Inline ActionsI would not merge this change to stable/13 at all. IMO we should not merge there unless fixing a concrete bug, which this change does not. The change is probably low-risk, but I have no experience exporting tmpfs filesystems with NFS, and we have no regression tests covering that case. markj: I would not merge this change to stable/13 at all. IMO we should not merge there unless fixing… | |||||
| unsigned int tfd_gen; | |||||
| ino_t tfd_id; | ino_t tfd_id; | ||||
| unsigned long tfd_gen; | |||||
| }; | }; | ||||
| _Static_assert(sizeof(struct tmpfs_fid_data) <= MAXFIDSZ, | |||||
| "(struct tmpfs_fid_data) is larger than (struct fid).fid_data"); | |||||
| struct tmpfs_dir_cursor { | struct tmpfs_dir_cursor { | ||||
| struct tmpfs_dirent *tdc_current; | struct tmpfs_dirent *tdc_current; | ||||
| struct tmpfs_dirent *tdc_tree; | struct tmpfs_dirent *tdc_tree; | ||||
| }; | }; | ||||
| #ifdef _KERNEL | #ifdef _KERNEL | ||||
| /* | /* | ||||
| ▲ Show 20 Lines • Show All 208 Lines • Show Last 20 Lines | |||||
Although this field is initialized by arc4random(),
it is also incremented.
--> Having it 64bits guarantees it will not wrap around to zero.