- 13 Jul, 2023 19 commits
-
-
Jeff Layton authored
In later patches, we're going to change how the inode's ctime field is used. Switch to using accessor functions instead of raw accesses of inode->i_ctime. Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Jeff Layton <jlayton@kernel.org> Reviewed-by:
Jan Kara <jack@suse.cz> Message-Id: <20230705190309.579783-32-jlayton@kernel.org> Signed-off-by:
Christian Brauner <brauner@kernel.org>
-
Jeff Layton authored
In later patches, we're going to change how the inode's ctime field is used. Switch to using accessor functions instead of raw accesses of inode->i_ctime. Acked-by:
Nicolas Pitre <nico@fluxnic.net> Signed-off-by:
-
Jeff Layton authored
In later patches, we're going to change how the inode's ctime field is used. Switch to using accessor functions instead of raw accesses of inode->i_ctime. Signed-off-by:
Joel Becker <jlbec@evilplan.org> Reviewed-by:
-
Jeff Layton authored
In later patches, we're going to change how the inode's ctime field is used. Switch to using accessor functions instead of raw accesses of inode->i_ctime. Signed-off-by:
-
Jeff Layton authored
In later patches, we're going to change how the inode's ctime field is used. Switch to using accessor functions instead of raw accesses of inode->i_ctime. Reviewed-by:
Xiubo Li <xiubli@redhat.com> Signed-off-by:
-
Jeff Layton authored
In later patches, we're going to change how the inode's ctime field is used. Switch to using accessor functions instead of raw accesses of inode->i_ctime. Signed-off-by:
-
Jeff Layton authored
In later patches, we're going to change how the inode's ctime field is used. Switch to using accessor functions instead of raw accesses of inode->i_ctime. Signed-off-by:
-
Jeff Layton authored
In later patches, we're going to change how the inode's ctime field is used. Switch to using accessor functions instead of raw accesses of inode->i_ctime. Reviewed-by:
-
Jeff Layton authored
In later patches, we're going to change how the inode's ctime field is used. Switch to using accessor functions instead of raw accesses of inode->i_ctime. Reviewed-by:
Ian Kent <raven@themaw.net> Reviewed-by:
-
Jeff Layton authored
In later patches, we're going to change how the inode's ctime field is used. Switch to using accessor functions instead of raw accesses of inode->i_ctime. Reviewed-by:
-
Jeff Layton authored
In later patches, we're going to change how the inode's ctime field is used. Switch to using accessor functions instead of raw accesses of inode->i_ctime. Reviewed-by:
-
Jeff Layton authored
In later patches, we're going to change how the inode's ctime field is used. Switch to using accessor functions instead of raw accesses of inode->i_ctime. Acked-by:
David Sterba <dsterba@suse.com> Reviewed-by:
-
Jeff Layton authored
In later patches, we're going to change how the inode's ctime field is used. Switch to using accessor functions instead of raw accesses of inode->i_ctime. Reviewed-by:
-
Jeff Layton authored
In later patches, we're going to change how the inode's ctime field is used. Switch to using accessor functions instead of raw accesses of inode->i_ctime. Reviewed-by:
-
Jeff Layton authored
In later patches, we're going to change how the inode's ctime field is used. Switch to using accessor functions instead of raw accesses of inode->i_ctime. Acked-by:
-
Jeff Layton authored
In later patches, we're going to change how the inode's ctime field is used. Switch to using accessor functions instead of raw accesses of inode->i_ctime. Acked-by:
-
Jeff Layton authored
In later patches, we're going to change how the inode's ctime field is used. Switch to using accessor functions instead of raw accesses of inode->i_ctime. Reviewed-by:
Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com> Signed-off-by:
-
Jeff Layton authored
In later patches, we're going to change how the inode's ctime field is used. Switch to using accessor functions instead of raw accesses of inode->i_ctime. Reviewed-by:
-
Jeff Layton authored
In later patches, we're going to change how the inode's ctime field is used. Switch to using accessor functions instead of raw accesses of inode->i_ctime. Reviewed-by:
Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by:
-
- 10 Jul, 2023 15 commits
-
-
Jeff Layton authored
In later patches, we're going to change how the inode's ctime field is used. Switch to using accessor functions instead of raw accesses of inode->i_ctime. Acked-by:
Jeremy Kerr <jk@ozlabs.org> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Message-Id: <20230705190309.579783-13-jlayton@kernel.org> Signed-off-by:
-
Jeff Layton authored
Signed-off-by:
-
Jeff Layton authored
A rename potentially involves updating 4 different inode timestamps. Convert to the new simple_rename_timestamp helper function. Signed-off-by:
-
Jeff Layton authored
A rename potentially involves updating 4 different inode timestamps. Convert to the new simple_rename_timestamp helper function. Signed-off-by:
-
Jeff Layton authored
A rename potentially involves updating 4 different inode timestamps. Convert to the new simple_rename_timestamp helper function. Signed-off-by:
-
Jeff Layton authored
A rename potentially involves updating 4 different inode timestamps. Convert to the new simple_rename_timestamp helper function. Signed-off-by:
Zhihao Cheng <chengzhihao1@huawei.com> Message-Id: <20230705190309.579783-8-jlayton@kernel.org> Signed-off-by:
-
Jeff Layton authored
A rename potentially involves updating 4 different inode timestamps. Convert to the new simple_rename_timestamp helper function. Signed-off-by:
-
Jeff Layton authored
A rename potentially involves updating 4 different inode timestamps. Add a function that handles the details sanely, and convert the libfs.c callers to use it. Signed-off-by:
-
Jeff Layton authored
struct timespec64 has unused bits in the tv_nsec field that can be used for other purposes. In future patches, we're going to change how the inode->i_ctime is accessed in certain inodes in order to make use of them. In order to do that safely though, we'll need to eradicate raw accesses of the inode->i_ctime field from the kernel. Add new accessor functions for the ctime that we use to replace them. Reviewed-by:
Luis Chamberlain <mcgrof@kernel.org> Signed-off-by:
Damien Le Moal <dlemoal@kernel.org> Message-Id: <20230705185812.579118-2-jlayton@kernel.org> Signed-off-by:
-
Jeff Layton authored
POSIX says: "Upon successful completion, where nbyte is greater than 0, write() shall mark for update the last data modification and last file status change timestamps of the file..." Add the missing ctime update. Signed-off-by:Steve French <stfrench@microsoft.com> Message-Id: <20230705190309.579783-6-jlayton@kernel.org> Signed-off-by:
-
Jeff Layton authored
In general, when updating the mtime on an inode, one must also update the ctime. Add the missing ctime updates. Acked-by:
John Johansen <john.johansen@canonical.com> Signed-off-by:
-
Jeff Layton authored
When removing entries from a directory, the ctime must also be updated alongside the mtime. Signed-off-by:
-
Jeff Layton authored
POSIX says: "Upon successful completion, where nbyte is greater than 0, write() shall mark for update the last data modification and last file status change timestamps of the file..." Add the missing ctime update. Signed-off-by:
-
Jeff Layton authored
When adding entries to a directory, POSIX generally requires that the ctime be updated alongside the mtime. Signed-off-by:
-
Jeff Layton authored
POSIX says: "Upon successful completion, where nbyte is greater than 0, write() shall mark for update the last data modification and last file status change timestamps of the file..." Signed-off-by:
-
- 09 Jul, 2023 6 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
We just sorted the entries and fields last release, so just out of a perverse sense of curiosity, I decided to see if we can keep things ordered for even just one release. The answer is "No. No we cannot". I suggest that all kernel developers will need weekly training sessions, involving a lot of Big Bird and Sesame Street. And at the yearly maintainer summit, we will all sing the alphabet song together. I doubt I will keep doing this. At some point "perverse sense of curiosity" turns into just a cold dark place filled with sadness and despair. Repeats: 80e62bc8 ("MAINTAINERS: re-sort all entries and fields") Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.infradead.org/users/hch/dma-mappingLinus Torvalds authored
Pull dma-mapping fixes from Christoph Hellwig: - swiotlb area sizing fixes (Petr Tesarik) * tag 'dma-mapping-6.5-2023-07-09' of git://git.infradead.org/users/hch/dma-mapping: swiotlb: reduce the number of areas to match actual memory pool size swiotlb: always set the number of areas before allocating the pool
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull irq update from Borislav Petkov: - Optimize IRQ domain's name assignment * tag 'irq_urgent_for_v6.5_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqdomain: Use return value of strreplace()
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fpu fix from Borislav Petkov: - Do FPU AP initialization on Xen PV too which got missed by the recent boot reordering work * tag 'x86_urgent_for_v6.5_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/xen: Fix secondary processors' FPU initialization
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fix from Thomas Gleixner: "A single fix for the mechanism to park CPUs with an INIT IPI. On shutdown or kexec, the kernel tries to park the non-boot CPUs with an INIT IPI. But the same code path is also used by the crash utility. If the CPU which panics is not the boot CPU then it sends an INIT IPI to the boot CPU which resets the machine. Prevent this by validating that the CPU which runs the stop mechanism is the boot CPU. If not, leave the other CPUs in HLT" * tag 'x86-core-2023-07-09' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/smp: Don't send INIT to boot CPU
-
