On Wed, Jul 26, 2023 at 06:45:55PM +0300, Dmitry Baryshkov wrote:
> > > bisection log:
> > > https://syzkaller.appspot.com/x/bisect.txt?x=17b48111a8
...
> > > dashboard link:
> > > https://syzkaller.appspot.com/bug?extid=3f6a670108ce43356017
> I highly suspect that the bisect was wrong he
gt; Signed-off-by: Christoph Hellwig
> Reviewed-by: Hannes Reinecke
> Reviewed-by: Darrick J. Wong
Acked-by: Theodore Ts'o
Reinecke
> Acked-by: Darrick J. Wong
Acked-by: Theodore Ts'o
On Mon, Jan 23, 2023 at 11:05:56AM +0100, Jan Kara wrote:
> Thanks for the heads up. So we had kind of a similar issue for ext4 but it
> got caught by Ted during his regression runs so we've basically done what
> GFS2 is doing for the merge window and now there's patchset pending to
> convert the d
y others. So stop using ll_rw_block() in
> journal_get_superblock(). We also switch to new bh_readahead_batch()
> for the buffer array readahead path.
>
> Signed-off-by: Zhang Yi
Thanks, looks good.
Reviewed-by: Theodore Ts'o
- Ted
/linux-mm/20180103100430.ge4...@quack2.suse.cz
[2] https://lore.kernel.org/r/yg0m6ijcnmfas...@google.com
Reported-by:
syzbot+d59332e2db681cf18f0318a06e994ebbb529a...@syzkaller.appspotmail.com
Reported-by: Lee Jones
Signed-off-by: Theodore Ts'o
---
-v5 Argh, sent the wrong version of this
/linux-mm/20180103100430.ge4...@quack2.suse.cz
[2] https://lore.kernel.org/r/yg0m6ijcnmfas...@google.com
Reported-by:
syzbot+d59332e2db681cf18f0318a06e994ebbb529a...@syzkaller.appspotmail.com
Reported-by: Lee Jones
Signed-off-by: Theodore Ts'o
Cc: sta...@kernel.org
---
v4 - only changes t
On Fri, Feb 25, 2022 at 08:40:36PM -0500, Theodore Ts'o wrote:
> Well, that makes it process_vm_writev()'s is that it needs to know
> when to call pin_user_file_pages().
Sorry, typed too fast. What I was trying to say is this make it
process_vm_writev()'s problem to figu
On Fri, Feb 25, 2022 at 04:41:14PM -0800, John Hubbard wrote:
>
> > f2fs and btrfs's compressed file write support, by making things work
> > much like the write(2) system call. Imagine if we had a
> > "pin_user_pages_local()" which calls write_begin(), and a
> > "unpin_user_pages_local()" which
On Fri, Feb 25, 2022 at 01:33:33PM -0800, John Hubbard wrote:
> On 2/25/22 13:23, Theodore Ts'o wrote:
> > [un]pin_user_pages_remote is dirtying pages without properly warning
> > the file system in advance. This was noted by Jan Kara in 2018[1] and
>
> In 2018, [un]pin
: Theodore Ts'o
---
fs/ext4/inode.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 01c9e4f743ba..008fe8750109 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -1993,6 +1993,15 @@ static int ext4_writ
On Fri, Feb 25, 2022 at 12:51:28PM -0800, Eric Biggers wrote:
> >
> > [1] https://www.spinics.net/lists/linux-mm/msg142700.html
>
> Can you use a lore link
> (https://lore.kernel.org/linux-mm/20180103100430.ge4...@quack2.suse.cz/T/#u)?
Sure, thanks for finding the lore link! I did try searching
/msg142700.html
[2] https://lore.kernel.org/r/yg0m6ijcnmfas...@google.com
Reported-by:
syzbot+d59332e2db681cf18f0318a06e994ebbb529a...@syzkaller.appspotmail.com
Reported-by: Lee Jones
Signed-off-by: Theodore Ts'o
---
fs/ext4/inode.c | 27 ++-
1 file changed, 26 inser
On Wed, Feb 23, 2022 at 04:44:07PM -0800, John Hubbard wrote:
>
> Actually...I can confirm that real customers really are doing *exactly*
> that! Despite the kernel crashes--because the crashes don't always
> happen unless you have a large (supercomputer-sized) installation. And
> even then it
On Thu, Feb 24, 2022 at 12:48:42PM +1100, Dave Chinner wrote:
> > Fair enough; on the other hand, we could also view this as making ext4
> > more robust against buggy code in other subsystems, and while other
> > file systems may be losing user data if they are actually trying to do
> > remote memo
On Fri, Feb 18, 2022 at 08:51:54AM +0100, Greg Kroah-Hartman wrote:
> > The challenge is that fixing this "the right away" is probably not
> > something we can backport into an LTS kernel, whether it's 5.15 or
> > 5.10... or 4.19.
>
> Don't worry about stable backports to start with. Do it the "r
On Thu, Feb 17, 2022 at 10:33:34PM -0800, John Hubbard wrote:
>
> Just a small thing I'll say once, to get it out of my system. No action
> required here, I just want it understood:
>
> Before commit 803e4572d7c5 ("mm/process_vm_access: set FOLL_PIN via
> pin_user_pages_remote()"), you would have
On Fri, Feb 18, 2022 at 04:24:20AM +, Matthew Wilcox wrote:
> On Thu, Feb 17, 2022 at 09:54:30PM -0500, Theodore Ts'o wrote:
> > process_vm_writev() uses [un]pin_user_pages_remote() which is the same
> > interface uses for RDMA. But it's not clear this is ever suppos
, I'm pretty sure they are't either using RDMA,
and I suspect they are probably masking out the process_vm_writev(2)
system call (at least, for Android O and newer). So if the goal is to
just to close some Syzbot bugs, what do folks think about this?
On Wed, Feb 16, 2022 at 04:31:36PM +, Lee Jones wrote:
>
> After recently receiving a bug report from Syzbot [0] which was raised
> specifically against the Android v5.10 kernel, I spent some time
> trying to get to the crux. Firstly I reproduced the issue on the
> reported kernel, then did t
On Mon, Oct 25, 2021 at 08:24:26PM +0200, Andreas Gruenbacher wrote:
> > For generic_perform_write() Dave Hansen attempted to move the fault-in
> > after the uaccess in commit 998ef75ddb57 ("fs: do not prefault
> > sys_write() user buffer pages"). This was reverted as it was exposing an
> > ext4 bu
On Fri, Jan 27, 2017 at 10:37:35AM +0100, Michal Hocko wrote:
> If this ever turn out to be a problem and with the vmapped stacks we
> have good chances to get a proper stack traces on a potential overflow
> we can add the scope API around the problematic code path with the
> explanation why it is
On Thu, Jan 26, 2017 at 08:44:55AM +0100, Michal Hocko wrote:
> > > I'm convinced the current series is OK, only real life will tell us
> > > whether
> > > we missed something or not ;)
> >
> > I would like to extend the changelog of "jbd2: mark the transaction
> > context with the scope GFP_NOFS
On Tue, Jan 17, 2017 at 04:18:17PM +0100, Michal Hocko wrote:
>
> OK, so I've been staring into the code and AFAIU current->journal_info
> can contain my stored information. I could either hijack part of the
> word as the ref counting is only consuming low 12b. But that looks too
> ugly to live. O
On Fri, Jan 06, 2017 at 03:11:06PM +0100, Michal Hocko wrote:
> From: Michal Hocko
>
> This reverts commit c45653c341f5c8a0ce19c8f0ad4678640849cb86 because
> sb_getblk_gfp is not really needed as
> sb_getblk
> __getblk_gfp
> __getblk_slow
> grow_buffers
> grow_dev_page
>
On Fri, Jan 06, 2017 at 03:11:07PM +0100, Michal Hocko wrote:
> From: Michal Hocko
>
> This reverts commit 216553c4b7f3e3e2beb4981cddca9b2027523928. Now that
> the transaction context uses memalloc_nofs_save and all allocations
> within the this context inherit GFP_NOFS automatically, there is no
On Tue, Nov 04, 2014 at 12:19:49PM +0100, Jan Kara wrote:
> CC: linux-e...@vger.kernel.org
> CC: "Theodore Ts'o"
> Signed-off-by: Jan Kara
Acked-by: Theodore Ts'o
- Ted
On Thu, Mar 13, 2014 at 07:33:02PM -0500, Steve French wrote:
> On Thu, Mar 13, 2014 at 9:20 AM, Theodore Ts'o wrote:
> > Previously, the no-op "mount -o mount /dev/xxx" operation when the
> > file system is already mounted read-write causes an implied,
> >
On Thu, Mar 13, 2014 at 04:28:23PM +, Steven Whitehouse wrote:
>
> I guess the same is true for other file systems which are mounted ro
> too. So maybe a check for MS_RDONLY before doing the sync in those
> cases?
My original patch moved the sync_filesystem into the check for
MS_RDONLY in the
e to read-only, and there are some file systems where this is
not needed at all (for example, for a pseudo-filesystem or something
like romfs).
Signed-off-by: "Theodore Ts'o"
Cc: linux-fsde...@vger.kernel.org
Cc: Christoph Hellwig
Cc: Artem Bityutskiy
Cc: Adrian Hunter
Cc: Ev
On Wed, Jun 19, 2013 at 12:15:53PM -0700, Joe Perches wrote:
> Don't emit OOM warnings when k.alloc calls fail when
> there there is a v.alloc immediately afterwards.
>
> Signed-off-by: Joe Perches
For fs/ext4/super.c:
Acked-by: "Theodore Ts'o"
- Ted
On Tue, Apr 09, 2013 at 11:14:17AM +0200, Lukas Czerner wrote:
> ->invalidatepage() aop now accepts range to invalidate so we can make
> use of it in gfs2_invalidatepage().
>
> Signed-off-by: Lukas Czerner
> Cc: cluster-devel@redhat.com
To the gfs2 development team,
Since half of this patch se
On Tue, Apr 23, 2013 at 10:16:31AM -0400, Theodore Ts'o wrote:
> On Tue, Apr 09, 2013 at 11:14:17AM +0200, Lukas Czerner wrote:
> > ->invalidatepage() aop now accepts range to invalidate so we can make
> > use of it in gfs2_invalidatepage().
> >
> > Signed-off
33 matches
Mail list logo
