On Fri, Oct 20, 2023 at 12:10:38AM -0700, syzbot wrote:
> syzbot has bisected this issue to:
>
> commit 0abd1557e21c617bd13fc18f7725fc6363c05913
> Author: Al Viro
> Date: Mon Oct 2 02:33:44 2023 +
>
> gfs2: fix an oops in gfs2_permission
>
On Tue, Aug 29, 2023 at 08:43:31PM -0400, Jeff Layton wrote:
> On Wed, 2023-08-30 at 01:02 +0100, Al Viro wrote:
> > On Tue, Aug 29, 2023 at 06:58:47PM -0400, Jeff Layton wrote:
> > > On Tue, 2023-08-29 at 23:44 +0100, Al Viro wrote:
> > > > On Tue, Jul 25, 2023 at
On Wed, Jul 05, 2023 at 02:58:11PM -0400, Jeff Layton wrote:
> + * POSIX mandates that the old and new parent directories have their ctime
> and
> + * mtime updated, and that inodes of @old_dentry and @new_dentry (if any),
> have
> + * their ctime updated.
APPLICATION USAGE
Some
On Tue, Aug 29, 2023 at 06:58:47PM -0400, Jeff Layton wrote:
> On Tue, 2023-08-29 at 23:44 +0100, Al Viro wrote:
> > On Tue, Jul 25, 2023 at 10:58:14AM -0400, Jeff Layton wrote:
> > > generic_fillattr just fills in the entire stat struct indiscriminately
> > > today,
On Tue, Jul 25, 2023 at 10:58:14AM -0400, Jeff Layton wrote:
> generic_fillattr just fills in the entire stat struct indiscriminately
> today, copying data from the inode. There is at least one attribute
> (STATX_CHANGE_COOKIE) that can have side effects when it is reported,
> and we're looking at
On Mon, Aug 28, 2023 at 02:30:23PM +0200, Christoph Hellwig wrote:
> On Sun, Aug 27, 2023 at 08:41:22PM +0100, Al Viro wrote:
> > That part is somewhat fishy - there's a case where you return a positive
> > value
> > and advance ->ki_pos by more than that amount.
On Mon, Aug 28, 2023 at 02:32:59PM +0200, Christoph Hellwig wrote:
> On Sun, Aug 27, 2023 at 10:45:18PM +0100, Al Viro wrote:
> > IOW, I suspect that the right thing to do would be something along the lines
> > of
>
> The idea looks sensible to me, but
On Sun, Aug 27, 2023 at 08:41:22PM +0100, Al Viro wrote:
> That part is somewhat fishy - there's a case where you return a positive value
> and advance ->ki_pos by more than that amount. I really wonder if all callers
> of ->write_iter() are OK with that.
Speaking of which, in c
On Sun, Aug 27, 2023 at 08:41:22PM +0100, Al Viro wrote:
> On Thu, Jun 01, 2023 at 04:58:55PM +0200, Christoph Hellwig wrote:
> > All callers of generic_perform_write need to updated ki_pos, move it into
> > common code.
>
> > @@ -4034,7 +4037,6 @@ ssize_t __generic_file
On Thu, Jun 01, 2023 at 04:58:55PM +0200, Christoph Hellwig wrote:
> All callers of generic_perform_write need to updated ki_pos, move it into
> common code.
> @@ -4034,7 +4037,6 @@ ssize_t __generic_file_write_iter(struct kiocb *iocb,
> struct iov_iter *from)
> endbyte = pos +
On Fri, Mar 10, 2023 at 11:51:21AM +0800, Yangtao Li wrote:
> Hi AI,
>
> > Umm... What's the branchpoint for that series?
> > Not the mainline - there we have i_blocksize() open-coded...
>
> Sorry, I'm based on the latest branch of the erofs repository.
>
>
On Fri, Mar 10, 2023 at 03:19:40AM +, Al Viro wrote:
> On Thu, Mar 09, 2023 at 11:21:25PM +0800, Yangtao Li wrote:
> > Use i_blockmask() to simplify code.
> >
> > Signed-off-by: Yangtao Li
> > ---
> > v3:
> > -none
> > v2:
> > -convert to i_
On Thu, Mar 09, 2023 at 11:21:26PM +0800, Yangtao Li wrote:
> Use i_blockmask() to simplify code. BTW convert ocfs2_is_io_unaligned
> to return bool type.
>
> Signed-off-by: Yangtao Li
> ---
> v3:
> -none
> fs/ocfs2/file.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>
On Thu, Mar 09, 2023 at 11:21:23PM +0800, Yangtao Li wrote:
> Use i_blockmask() to simplify code.
Umm... What's the branchpoint for that series? Not the mainline -
there we have i_blocksize() open-coded...
> Signed-off-by: Yangtao Li
> ---
> v3:
> -none
> v2:
> -convert to i_blockmask()
>
On Thu, Mar 09, 2023 at 11:21:25PM +0800, Yangtao Li wrote:
> Use i_blockmask() to simplify code.
>
> Signed-off-by: Yangtao Li
> ---
> v3:
> -none
> v2:
> -convert to i_blockmask()
> fs/ext4/inode.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/ext4/inode.c
On Thu, Jan 05, 2023 at 04:19:29PM -0500, Jeff Layton wrote:
> The file locking definitions have lived in fs.h since the dawn of time,
> but they are only used by a small subset of the source files that
> include it.
>
> Move the file locking definitions to a new header file, and add the
>
On Fri, Nov 25, 2022 at 08:23:45AM -0500, Jeff Layton wrote:
> I left it in fs.h for now. Some of the file_operations prototypes need
> that typedef, and I figure that anyone who is including filelock.h will
> almost certainly need to include fs.h anyway. We could move it into a
> separate header
On Tue, Nov 22, 2022 at 03:51:31AM +, Matthew Wilcox wrote:
> On Sun, Nov 20, 2022 at 03:59:57PM -0500, Jeff Layton wrote:
> > Move the file locking definitions to a new header file, and add the
> > appropriate #include directives to the source files that need them. By
> > doing this we trim
On Sun, Nov 20, 2022 at 03:59:57PM -0500, Jeff Layton wrote:
> --- /dev/null
> +++ b/include/linux/filelock.h
> @@ -0,0 +1,428 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _LINUX_FILELOCK_H
> +#define _LINUX_FILELOCK_H
> +
> +#include
> +#include
Umm... I'd add a comment along the
On Fri, Sep 02, 2022 at 09:32:53AM +0800, Zhang Yi wrote:
> On 2022/9/2 8:30, Al Viro wrote:
> > On Thu, Sep 01, 2022 at 09:35:04PM +0800, Zhang Yi wrote:
> >> bh_submit_read() and the uptodate check logic in bh_uptodate_or_lock()
> >> has been integrated in bh_read
On Thu, Sep 01, 2022 at 09:35:04PM +0800, Zhang Yi wrote:
> bh_submit_read() and the uptodate check logic in bh_uptodate_or_lock()
> has been integrated in bh_read() helper, so switch to use it directly.
s/bh_read_locked/bh_read/ in the summary?
On Sat, Jan 22, 2022 at 01:28:20PM -0500, Alexander Aring wrote:
> Hi,
>
> On Fri, Jan 21, 2022 at 9:45 PM kernel test robot wrote:
> >
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > master
> > head: 9b57f458985742bd1c585f4c7f36d04634ce1143
> > commit:
On Fri, Sep 03, 2021 at 08:52:00AM -0700, Linus Torvalds wrote:
> On Wed, Sep 1, 2021 at 12:53 PM Andreas Gruenbacher
> wrote:
> >
> > So there's a minor merge conflict between Christoph's iomap_iter
> > conversion and this patch queue now, and I should probably clarify the
> > description of
On Tue, Aug 31, 2021 at 02:54:50PM +0100, Catalin Marinas wrote:
> An arm64-specific workaround would be for pagefault_disable() to disable
> tag checking. It's a pretty big hammer, weakening the out of bounds
> access detection of MTE. My preference would be a fix in the btrfs code.
>
> A btrfs
On Sun, Aug 29, 2021 at 08:44:04PM +0200, Thomas Gleixner wrote:
> On Sat, Aug 28 2021 at 22:51, Al Viro wrote:
> > @@ -345,7 +346,7 @@ static inline int xsave_to_user_sigframe(struct
> > xregs_state __user *buf)
> > */
> > err = __clear_user(
On Fri, Aug 27, 2021 at 09:48:55PM +, Al Viro wrote:
> So we have 3 callers where we want all-or-nothing semantics - two in
> arch/x86/kernel/fpu/signal.c and one in btrfs. HWPOISON will be a problem
> for all 3, AFAICS...
>
> IOW, it looks like we have two different things m
On Sat, Aug 28, 2021 at 10:19:04PM +, Al Viro wrote:
> How about taking __clear_user() out of copy_fpregs_to_sigframe()
> and replacing the call of fault_in_pages_writeable() with
> if (!clear_user(buf_fx, fpu_user_xstate_size))
> goto retry;
>
On Sat, Aug 28, 2021 at 10:11:36PM +, Al Viro wrote:
> On Sat, Aug 28, 2021 at 10:04:41PM +0000, Al Viro wrote:
> > On Sat, Aug 28, 2021 at 11:47:03PM +0200, Thomas Gleixner wrote:
> >
> > > /* Try to handle #PF, but anything else is fatal. */
> > > if (
On Sat, Aug 28, 2021 at 10:04:41PM +, Al Viro wrote:
> On Sat, Aug 28, 2021 at 11:47:03PM +0200, Thomas Gleixner wrote:
>
> > /* Try to handle #PF, but anything else is fatal. */
> > if (ret != -EFAULT)
> > return -EINVAL;
>
> > which all end up in u
On Sat, Aug 28, 2021 at 11:47:03PM +0200, Thomas Gleixner wrote:
> /* Try to handle #PF, but anything else is fatal. */
> if (ret != -EFAULT)
> return -EINVAL;
> which all end up in user_insn(). user_insn() returns 0 or the negated
> trap number, which results in -EFAULT for #PF, but
AFAICS, a48b73eca4ce "btrfs: fix potential deadlock in the search ioctl"
has introduced a bug at least on arm64.
Relevant bits: in search_ioctl() we have
while (1) {
ret = fault_in_pages_writeable(ubuf + sk_offset,
On Fri, Aug 27, 2021 at 09:48:55PM +, Al Viro wrote:
> [btrfs]search_ioctl()
> Broken with memory poisoning, for either variant of semantics. Same for
> arm64 sub-page permission differences, I think.
> So we have 3 callers where we want all-or-nothing semantics - two i
On Fri, Aug 27, 2021 at 07:37:25PM +, Al Viro wrote:
> On Fri, Aug 27, 2021 at 12:33:00PM -0700, Linus Torvalds wrote:
> > On Fri, Aug 27, 2021 at 12:23 PM Al Viro wrote:
> > >
> > > Could you show the cases where "partial copy, so it's OK"
On Fri, Aug 27, 2021 at 12:33:00PM -0700, Linus Torvalds wrote:
> On Fri, Aug 27, 2021 at 12:23 PM Al Viro wrote:
> >
> > Could you show the cases where "partial copy, so it's OK" behaviour would
> > break anything?
>
> Absolutely.
>
> Fo
On Fri, Aug 27, 2021 at 12:05:32PM -0700, Linus Torvalds wrote:
> But see above. People *need* that ternary result, and "bytes/pages
> uncopied" is not only the traditional one we use elsewhere in similar
> situations, it's the one that has the easiest error tests for existing
> users (because
On Fri, Aug 27, 2021 at 11:57:19AM -0700, Linus Torvalds wrote:
> On Fri, Aug 27, 2021 at 11:53 AM Al Viro wrote:
> >
> > I really disagree with these calling conventions. "Number not faulted in"
> > is bloody useless
>
> It's what we already have for
On Fri, Aug 27, 2021 at 06:49:10PM +0200, Andreas Gruenbacher wrote:
> Turn fault_in_pages_{readable,writeable} into versions that return the
> number of bytes not faulted in (similar to copy_to_user) instead of
> returning a non-zero value when any of the requested pages couldn't be
> faulted in.
On Fri, Aug 27, 2021 at 06:49:11PM +0200, Andreas Gruenbacher wrote:
> Turn iov_iter_fault_in_readable into a function that returns the number
> of bytes not faulted in (similar to copy_to_user) instead of returning a
> non-zero value when any of the requested pages couldn't be faulted in.
> This
On Fri, Aug 27, 2021 at 06:49:12PM +0200, Andreas Gruenbacher wrote:
> Introduce a new fault_in_iov_iter_writeable helper for safely faulting
> in an iterator for writing. Uses get_user_pages() to fault in the pages
> without actually writing to them, which would be destructive.
>
> We'll use
On Fri, Aug 27, 2021 at 06:49:25PM +0200, Andreas Gruenbacher wrote:
> Introduce a new nofault flag to indicate to get_user_pages to use the
> FOLL_NOFAULT flag. This will cause get_user_pages to fail when it
> would otherwise fault in a page.
>
> Currently, the noio flag is only checked in
On Fri, Aug 20, 2021 at 12:39:19PM -0400, Jeff Layton wrote:
> diff --git a/fs/locks.c b/fs/locks.c
> @@ -2857,8 +2744,7 @@ static void lock_get_status(struct seq_file *f, struct
> file_lock *fl,
> seq_puts(f, "POSIX ");
>
> seq_printf(f, " %s ",
> -
On Tue, Aug 03, 2021 at 09:18:09PM +0200, Andreas Gruenbacher wrote:
> Turn fault_in_pages_{readable,writeable} into versions that return the number
> of bytes faulted in instead of returning a non-zero value when any of the
> requested pages couldn't be faulted in. This supports the existing
On Sun, Jul 25, 2021 at 12:06:41AM +0200, Andreas Gruenbacher wrote:
> On Sat, Jul 24, 2021 at 11:57 PM Al Viro wrote:
> > On Sat, Jul 24, 2021 at 11:38:20PM +0200, Andreas Gruenbacher wrote:
> >
> > > Hmm, how could we have sub-page failure areas when this is abou
On Sat, Jul 24, 2021 at 11:38:20PM +0200, Andreas Gruenbacher wrote:
> Hmm, how could we have sub-page failure areas when this is about if
> and how pages are mapped? If we return the number of bytes that are
> accessible, then users will know if they got nothing, something, or
> everything, and
On Sat, Jul 24, 2021 at 12:52:34PM -0700, Linus Torvalds wrote:
> ...
> > + if (fault_in_user_pages(start, len, true) != len)
> > + return -EFAULT;
>
> Looking at this once more, I think this is likely wrong.
>
> Why?
>
> Because any user
On Fri, Jul 23, 2021 at 10:58:34PM +0200, Andreas Gruenbacher wrote:
> Introduce a new fault_in_iov_iter helper for manually faulting in an iterator.
> Other than fault_in_pages_writeable(), this function is non-destructive.
>
> We'll use fault_in_iov_iter in gfs2 once we've determined that the
On Mon, Jul 19, 2021 at 12:39:26AM +0200, Andreas Gruenbacher wrote:
> Hi Linus et al.,
>
> here's an update to the gfs2 mmap + page faults fix that implements
> Linus's suggestion of disabling page faults while we're holding the
> inode glock.
>
> This passes fstests except for test
On Mon, Jul 19, 2021 at 12:29:35PM -0700, Linus Torvalds wrote:
> On Sun, Jul 18, 2021 at 3:40 PM Andreas Gruenbacher
> wrote:
> >
> > Introduce a new ITER_FLAG_FAST_ONLY flag
>
> I think the code is fine, but I think it might be best to call this
> "ITER_FLAG_NOIO" or something like that.
>
>
On Sat, Jun 12, 2021 at 04:17:30PM -0700, Linus Torvalds wrote:
> On Sat, Jun 12, 2021 at 2:47 PM Al Viro wrote:
> >
> > O_DIRECT case is a PITA - there we use GUP and there's no way
> > to tell GUP that in the current situation we do *NOT* want to hit
> > -&g
On Sat, Jun 12, 2021 at 02:33:31PM -0700, Linus Torvalds wrote:
> That said, reads are obviously much easier, and I'd probably prefer
> the model for writes to be to not necessarily pre-fault anything at
> all, but just write to user space with page faults disabled.
*nod*
I don't like that write
On Sat, Jun 12, 2021 at 09:05:40PM +, Al Viro wrote:
> Is the above an accurate description of the mainline situation there?
> In particular, normal read doesn't seem to bother with locks at all.
> What exactly are those cluster locks for in O_DIRECT read?
BTW, assuming
On Mon, May 31, 2021 at 05:12:31PM +, Al Viro wrote:
> > +int iov_iter_fault_in_writeable(struct iov_iter *i, size_t bytes)
> > +{
> > + size_t skip = i->iov_offset;
> > + const struct iovec *iov;
> > + int err;
> > + struct iovec v;
> > +
On Fri, Jun 11, 2021 at 04:25:10PM +, Al Viro wrote:
> On Wed, Jun 02, 2021 at 01:16:32PM +0200, Andreas Gruenbacher wrote:
>
> > Well, iomap_file_buffered_write() does that by using
> > iov_iter_fault_in_readable() and iov_iter_copy_from_user_atomic() as
> &
On Wed, Jun 02, 2021 at 01:16:32PM +0200, Andreas Gruenbacher wrote:
> Well, iomap_file_buffered_write() does that by using
> iov_iter_fault_in_readable() and iov_iter_copy_from_user_atomic() as
> in iomap_write_actor(), but the read and direct I/O side doesn't seem
> to have equivalents. I
On Mon, May 31, 2021 at 07:01:19PM +0200, Andreas Gruenbacher wrote:
> Add the equivalent of iov_iter_fault_in_readable(), but for pages that
> will be written to.
>
> While at it, fix an indentation error in iov_iter_fault_in_readable().
> +int iov_iter_fault_in_writeable(struct iov_iter *i,
On Tue, Jun 25, 2019 at 07:32:18PM -0700, Darrick J. Wong wrote:
> --- a/fs/btrfs/ioctl.c
> +++ b/fs/btrfs/ioctl.c
> @@ -373,10 +373,9 @@ static int check_xflags(unsigned int flags)
> static int btrfs_ioctl_fsgetxattr(struct file *file, void __user *arg)
> {
> struct btrfs_inode *binode =
On Tue, Jun 25, 2019 at 07:32:10PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> Create a generic function to check incoming FS_IOC_SETFLAGS flag values
> and later prepare the inode for updates so that we can standardize the
> implementations that follow ext4's flag values.
Change
On Thu, Nov 22, 2018 at 02:40:50PM +0900, Eiichi Tsukata wrote:
> 2018年11月21日(水) 13:54 Al Viro :
> >
> > On Wed, Nov 21, 2018 at 11:43:56AM +0900, Eiichi Tsukata wrote:
> > > Some file systems (including ext4, xfs, ramfs ...) have the following
> > > problem as I'v
On Wed, Nov 21, 2018 at 11:43:56AM +0900, Eiichi Tsukata wrote:
> Some file systems (including ext4, xfs, ramfs ...) have the following
> problem as I've described in the commit message of the 1/4 patch.
>
> The commit ef3d0fd27e90 ("vfs: do (nearly) lockless generic_file_llseek")
> removed
On Mon, Oct 09, 2017 at 11:13:18AM +0200, Andreas Gruenbacher wrote:
> In the code added to function submit_page_section by commit b1058b981,
> sdio->bio can currently be NULL when calling dio_bio_submit. This then
> leads to a NULL pointer access in dio_bio_submit, so check for a NULL
> bio in
On Sat, Oct 07, 2017 at 09:59:41AM +0800, Jia-Ju Bai wrote:
> According to fs/dlm/lock.c, the kernel may sleep under a spinlock,
> and the function call path is:
> dlm_master_lookup (acquire the spinlock)
> dlm_send_rcom_lookup_dump
> create_rcom
> dlm_lowcomms_get_buffer
>
On Tue, Aug 02, 2016 at 07:58:28PM +0800, Eryu Guan wrote:
> In most cases, EPERM is returned on immutable inode, and there're only a
> few places returning EACCES. I noticed this when running LTP on
> overlayfs, setxattr03 failed due to unexpected EACCES on immutable
> inode.
>
> So converting
On Wed, Apr 13, 2016 at 11:43:19PM -0500, Steve French wrote:
> If you are planning to merge it in next few weeks (they fix bugs, and
> are safe so why not), I can simply just back out my changes from
> cifs-2.6.git for-next branch and let you merge the trivial checkpatch
> cleanup attached.
Do
On Wed, Apr 13, 2016 at 11:26:24PM -0500, Steve French wrote:
> Thanks for spotting this - merged into cifs-2.6.git. checkpatch
> spotted and old indentation issue so I cleaned that up in a followon
> patch that I will send.
*ugh*
And in the meanwhile I'd picked those into my queue... Could
On Mon, Mar 16, 2015 at 04:33:48AM -0700, Omar Sandoval wrote:
Hi,
Al, here's some cleanup that you mentioned back in December that I got
around to (https://lkml.org/lkml/2014/12/15/28).
Applied. See #for-next
On Tue, Mar 17, 2015 at 10:31:51AM +0100, David Sterba wrote:
Agreed, but the proposed define is rather cryptic and I was not able to
understand the meaning on the first glance.
#define iov_iter_rw(i) ((0 ? (struct iov_iter *)0 : (i))-type RW_MASK)
This worked for me, does not compile
On Mon, Mar 16, 2015 at 04:33:49AM -0700, Omar Sandoval wrote:
Get either READ or WRITE out of iter-type.
Umm...
+ * Get one of READ or WRITE out of iter-type without any other flags OR'd in
+ * with it.
+ */
+static inline int iov_iter_rw(const struct iov_iter *i)
+{
+ return
On Mon, Mar 16, 2015 at 04:33:48AM -0700, Omar Sandoval wrote:
Hi,
Al, here's some cleanup that you mentioned back in December that I got
around to (https://lkml.org/lkml/2014/12/15/28).
In summary, the rw parameter to a_ops-direct_IO() is redundant with
.type in struct iov_iter.
Signed-off-by: Al Viro v...@zeniv.linux.org.uk
---
fs/gfs2/inode.c |5 +
1 file changed, 5 insertions(+)
diff --git a/fs/gfs2/inode.c b/fs/gfs2/inode.c
index c4ed823..310e248 100644
--- a/fs/gfs2/inode.c
+++ b/fs/gfs2/inode.c
@@ -624,6 +624,11 @@ static int gfs2_create_inode(struct inode
.
Shortlog:
Al Viro (3):
gfs2: bugger off early if O_CREAT open finds a directory
gfs2_create_inode(): don't bother with d_splice_alias()
gfs2_atomic_open(): simplify the use of finish_no_open()
Diffstat:
fs/gfs2/inode.c | 26 +-
1 file changed, 9 insertions
In -atomic_open(inode, dentry, file, opened) calling finish_no_open(file, NULL)
is equivalent to dget(dentry); return finish_no_open(file, dentry);
No need to open-code that...
Signed-off-by: Al Viro v...@zeniv.linux.org.uk
---
fs/gfs2/inode.c |7 ++-
1 file changed, 2 insertions(+), 5
-by: Al Viro v...@zeniv.linux.org.uk
---
fs/gfs2/inode.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/fs/gfs2/inode.c b/fs/gfs2/inode.c
index 310e248..ce0cf9a 100644
--- a/fs/gfs2/inode.c
+++ b/fs/gfs2/inode.c
@@ -596,7 +596,6 @@ static int gfs2_create_inode
On Wed, Nov 19, 2014 at 03:33:29PM -0500, Bob Peterson wrote:
- Original Message -
Signed-off-by: Al Viro v...@zeniv.linux.org.uk
---
fs/gfs2/inode.c |5 +
1 file changed, 5 insertions(+)
diff --git a/fs/gfs2/inode.c b/fs/gfs2/inode.c
index c4ed823..310e248 100644
Signed-off-by: Al Viro v...@zeniv.linux.org.uk
---
fs/gfs2/dir.c | 40
fs/gfs2/quota.c |9 ++---
2 files changed, 10 insertions(+), 39 deletions(-)
diff --git a/fs/gfs2/dir.c b/fs/gfs2/dir.c
index 5d4261f..c247fed 100644
--- a/fs/gfs2/dir.c
vfree() is allowed under spinlock these days, but it's cheaper when
it doesn't step into deferred case and here it's very easy to avoid.
Signed-off-by: Al Viro v...@zeniv.linux.org.uk
---
fs/gfs2/dir.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/gfs2/dir.c b
On Sat, Oct 11, 2014 at 06:34:52AM -0700, Christoph Hellwig wrote:
I still very much disagree with the s_inode_fields indirection. Please
find a patch below to remove it, and use a get_dquots super_block
operation instead. This leads to less and better readable code,
and serves 4 bytes in
On Thu, Jun 06, 2013 at 03:50:12PM +0100, Steven Whitehouse wrote:
The following patch implements atomic_open for GFS2. This is mostly
straightforward, however there is one corner case which I've had to
deal with, beyond what would normally be expected for a local
filesystem.
Broken - what
77 matches
Mail list logo
