On Fri, Dec 20, 2024 at 9:07 AM Haichi Wang wrote:
>
> Dear Linux maintainers and reviewers:
>
> We are reporting a Linux kernel bug titled **KASAN: slab-out-of-bounds Read
> in jfs_readdir**, discovered using a modified version of Syzkaller.
>
Hello Haichi,
Unfortunately right now the bug is n
On Thu, May 09, 2024 at 02:26:24PM +0800, Ubisectech Sirius wrote:
> Hello.
> We are Ubisectech Sirius Team, the vulnerability lab of China ValiantSec.
> Recently, our team has discovered a issue in Linux kernel 6.7. Attached to
> the email were a PoC file of the issue.
This (and several of your
On Tue, Apr 20, 2021 at 02:56:30PM +0800, kernel test robot wrote:
> Hi Paul,
>
> FYI, the error/warning still remains.
>
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 7af08140979a6e7e12b78c93b8625c8d25b084e2
> commit: e21408ceec2de5be418efa39feb
On Wed, 31 Mar 2021 22:45:12 +0800 Muchun Song wrote:
>
> Hi Andrew,
>
> Now we have two choices to fix this issue.
>
> 1) Send a v6 patchset (Use obj_cgroup APIs to charge kmem pages)
> to fix this issue.
> 2) Send a separate fix patch (Just like above).
>
> Both ways are ok for me. But
On Wed, Mar 31, 2021 at 2:22 PM Christian Borntraeger
wrote:
>
>
>
> On 30.03.21 18:25, Muchun Song wrote:
> > On Tue, Mar 30, 2021 at 11:10 PM Christian Borntraeger
> > wrote:
> >>
> >>
> >> On 30.03.21 15:49, Muchun Song wrote:
> >>> On Tue, Mar 30, 2021 at 9:27 PM Christian Borntraeger
> >>>
On Wed, Mar 31, 2021 at 2:22 PM Christian Borntraeger
wrote:
>
>
>
> On 30.03.21 18:25, Muchun Song wrote:
> > On Tue, Mar 30, 2021 at 11:10 PM Christian Borntraeger
> > wrote:
> >>
> >>
> >> On 30.03.21 15:49, Muchun Song wrote:
> >>> On Tue, Mar 30, 2021 at 9:27 PM Christian Borntraeger
> >>>
On Wed, Mar 31, 2021 at 02:15:41PM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 5e46d1b78a03d52306f21f77a4e4a144b6d31486
> commit: 826bfeb37bb4302ee6042f330c4c0c757152bdb8 preempt/dynamic: Support
> dynamic preempt
On 30.03.21 18:25, Muchun Song wrote:
On Tue, Mar 30, 2021 at 11:10 PM Christian Borntraeger
wrote:
On 30.03.21 15:49, Muchun Song wrote:
On Tue, Mar 30, 2021 at 9:27 PM Christian Borntraeger
wrote:
So bisect shows this for belows warning:
Thanks for your effort on this. Can you shar
On Tue, Mar 30, 2021 at 11:10 PM Christian Borntraeger
wrote:
>
>
> On 30.03.21 15:49, Muchun Song wrote:
> > On Tue, Mar 30, 2021 at 9:27 PM Christian Borntraeger
> > wrote:
> >>
> >> So bisect shows this for belows warning:
> >
> > Thanks for your effort on this. Can you share your config?
>
>
On 30.03.21 15:49, Muchun Song wrote:
On Tue, Mar 30, 2021 at 9:27 PM Christian Borntraeger
wrote:
So bisect shows this for belows warning:
Thanks for your effort on this. Can you share your config?
attached (but its s390x) for next-20210330
The problem goes away when I add
cgroup_contro
On Tue, Mar 30, 2021 at 9:27 PM Christian Borntraeger
wrote:
>
> So bisect shows this for belows warning:
Thanks for your effort on this. Can you share your config?
>
> 636c3ef8229ecb4e7d045e86f36505d24a8f019a is the first bad commit
> commit 636c3ef8229ecb4e7d045e86f36505d24a8f019a
> Author: Mu
So bisect shows this for belows warning:
636c3ef8229ecb4e7d045e86f36505d24a8f019a is the first bad commit
commit 636c3ef8229ecb4e7d045e86f36505d24a8f019a
Author: Muchun Song
Date: Mon Mar 29 11:12:06 2021 +1100
mm: memcontrol: use obj_cgroup APIs to charge kmem pages
Since Roman'
Not sure why I didn't hit this in testing but the problem is obvious: I missed
that revoke_iomem() calls devmem_is_allowed() which on x86 calls
region_intersects(). I guess I must have forgotten to do a boot test with
CONFIG_IO_STRICT_DEVMEM. Will put a fix together.
- Alistair
On Monday, 29
On Mon, Mar 22, 2021 at 11:37 AM Muni Sekhar wrote:
>
> What are some good Linux projects in kernel space for final year
> computer.science engineering students?
> Could someone help and share your ideas on this please.
Hedging deployed cryptography.
Hedging can be used to keep the state of a ma
On Mon, Mar 15, 2021 at 1:09 PM Catalin Marinas wrote:
>
> On Mon, Mar 15, 2021 at 08:08:06AM +0100, Dmitry Vyukov wrote:
> > On Wed, Feb 3, 2021 at 6:59 AM syzbot
> > wrote:
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:3aaf0a27 Merge tag 'clang-format-for-linux-v5.11-rc
On Mon, Mar 15, 2021 at 08:08:06AM +0100, Dmitry Vyukov wrote:
> On Wed, Feb 3, 2021 at 6:59 AM syzbot
> wrote:
> > syzbot found the following issue on:
> >
> > HEAD commit:3aaf0a27 Merge tag 'clang-format-for-linux-v5.11-rc7' of g..
> > git tree: upstream
> > console output: https://syz
On Wed, Feb 3, 2021 at 6:59 AM syzbot
wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:3aaf0a27 Merge tag 'clang-format-for-linux-v5.11-rc7' of g..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=17ef6108d0
> kernel config:
> The kernel stack is not very useful in this case, it's a common faulting
> stack.
> Maybe it will shed some light if you install gdb in the image, attach
> it to the systemd process, then trigger the segfault and then unwind
> stack in the systemd process at the time of fault, dump registers,
>
On Wed, Mar 10, 2021 at 10:02 AM Palash Oswal wrote:
>
> On Tue, Mar 9, 2021 at 7:58 PM Al Viro wrote:
> > Lovely. So something in that sequence of syscalls manages to trigger
> > segfault in unrelated process. What happens if you put it to sleep
> > right after open_by_handle_at() (e.g. by rea
On Tue, Mar 9, 2021 at 7:58 PM Al Viro wrote:
> Lovely. So something in that sequence of syscalls manages to trigger
> segfault in unrelated process. What happens if you put it to sleep
> right after open_by_handle_at() (e.g. by read(2) from fd 0, etc.)?
Added read(2) call in the reproducer, an
On Tue, Mar 9, 2021 at 8:36 PM Dmitry Vyukov wrote:
> FWIW the code looks reasonable:
>
> All code
>
>0: 00 00add%al,(%rax)
>2: 00 00add%al,(%rax)
>4: 41 57push %r15
>6: 41 56push %r14
>8: 41 5
Al Viro writes:
> On Tue, Mar 09, 2021 at 11:29:14AM +0530, Palash Oswal wrote:
>
>> I observe the following result(notice the segfault in systemd):
>> root@sandbox:~# ./repro
>> [9.457767] got to 221
>> [9.457791] got to 183
>> [9.459144] got to 201
>> [9.459471] got to 208
>> [
On Tue, Mar 9, 2021 at 3:31 PM Al Viro wrote:
> > I observe the following result(notice the segfault in systemd):
> > root@sandbox:~# ./repro
> > [9.457767] got to 221
> > [9.457791] got to 183
> > [9.459144] got to 201
> > [9.459471] got to 208
> > [9.459773] got to 210
> > [
On Tue, Mar 09, 2021 at 11:29:14AM +0530, Palash Oswal wrote:
> I observe the following result(notice the segfault in systemd):
> root@sandbox:~# ./repro
> [9.457767] got to 221
> [9.457791] got to 183
> [9.459144] got to 201
> [9.459471] got to 208
> [9.459773] got to 210
> [
On Mon, Mar 8, 2021 at 10:50 PM Al Viro wrote:
> I'd suggest to add printk(KERN_ERR "got to %d", __LINE__); in fs/fhandle.c at
> beginning of do_handle_open()
> right before each copy_from_user() in handle_to_path()
> right before and right after the call of do_handle_to_p
On Mon, Mar 08, 2021 at 10:06:10PM +0530, Palash Oswal wrote:
> I was running syzkaller and I found the following issue :
> Head Commit : 27e543cca13fab05689b2d0d61d200a83cfb00b6 ( v5.11.2 )
> Git Tree : stable
>
> Console Logs:
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x
ent List
>
> Subject: Re: kernel BUG at mm/zswap.c:1275! (rc6 - git 61556703b610)
>
> Hello.
>
> On Thu, Feb 11, 2021 at 10:43:18AM +, Song Bao Hua (Barry Song) wrote:
> > Are you using zsmalloc? There is a known bug on the combination
> > of zsmalloc and zswa
Hello.
On Thu, Feb 11, 2021 at 10:43:18AM +, Song Bao Hua (Barry Song) wrote:
> Are you using zsmalloc? There is a known bug on the combination
> of zsmalloc and zswap, fixed by patches of tiantao:
>
> mm: set the sleep_mapped to true for zbud and z3fold
> mm/zswap: fix variable 'entry' is un
> -Original Message-
> From: Mikhail Gavrilov [mailto:mikhail.v.gavri...@gmail.com]
> Sent: Thursday, February 11, 2021 9:58 PM
> To: sjenn...@linux.vnet.ibm.com; Song Bao Hua (Barry Song)
>
> Cc: Linux List Kernel Mailing ; Linux Memory
> Management List
> Subject: kernel BUG at mm/zsw
Em Sat, 6 Feb 2021 11:18:15 +0100
Hans Verkuil escreveu:
> >> Yes, driver "version" means nothing, so functionality is the correct way
> >> to handle this.
> >>
> >> Any chance you all can just drop the kernel version stuff and just
> >> report a static number that never goes up to allow people t
On 06/02/2021 10:48, Mauro Carvalho Chehab wrote:
> Em Sat, 6 Feb 2021 10:29:10 +0100
> Greg Kroah-Hartman escreveu:
>
>> On Sat, Feb 06, 2021 at 10:24:02AM +0100, Mauro Carvalho Chehab wrote:
>>> Em Sat, 6 Feb 2021 08:20:45 +0100
>>> Greg Kroah-Hartman escreveu:
>>>
On Fri, Feb 05, 2021
Em Sat, 6 Feb 2021 10:29:10 +0100
Greg Kroah-Hartman escreveu:
> On Sat, Feb 06, 2021 at 10:24:02AM +0100, Mauro Carvalho Chehab wrote:
> > Em Sat, 6 Feb 2021 08:20:45 +0100
> > Greg Kroah-Hartman escreveu:
> >
> > > On Fri, Feb 05, 2021 at 07:11:05PM +0100, Mauro Carvalho Chehab wrote:
> >
On Sat, Feb 06, 2021 at 10:24:02AM +0100, Mauro Carvalho Chehab wrote:
> Em Sat, 6 Feb 2021 08:20:45 +0100
> Greg Kroah-Hartman escreveu:
>
> > On Fri, Feb 05, 2021 at 07:11:05PM +0100, Mauro Carvalho Chehab wrote:
> > > Em Fri, 5 Feb 2021 12:31:05 -0500
> > > Tony Battersby escreveu:
> > >
>
Em Sat, 6 Feb 2021 08:20:45 +0100
Greg Kroah-Hartman escreveu:
> On Fri, Feb 05, 2021 at 07:11:05PM +0100, Mauro Carvalho Chehab wrote:
> > Em Fri, 5 Feb 2021 12:31:05 -0500
> > Tony Battersby escreveu:
> >
> > > On 2/4/21 6:00 AM, Jiri Slaby wrote:
> > > > Agreed. But currently, sublevel w
On Fri, Feb 05, 2021 at 07:44:12PM +0100, Pavel Machek wrote:
> Hi!
>
> > > > Ugh, I thought this was an internal representation, not an external one
> > > > :(
> > > >
> > > > > It might work somewhere, but there are a lot of (X * 65536 + Y * 256
> > > > > + Z)
> > > > > assumptions all around
On Fri, Feb 05, 2021 at 12:31:05PM -0500, Tony Battersby wrote:
> On 2/4/21 6:00 AM, Jiri Slaby wrote:
> > Agreed. But currently, sublevel won't "wrap", it will "overflow" to
> > patchlevel. And that might be a problem. So we might need to update the
> > header generation using e.g. "sublevel & 0
On Fri, Feb 05, 2021 at 07:11:05PM +0100, Mauro Carvalho Chehab wrote:
> Em Fri, 5 Feb 2021 12:31:05 -0500
> Tony Battersby escreveu:
>
> > On 2/4/21 6:00 AM, Jiri Slaby wrote:
> > > Agreed. But currently, sublevel won't "wrap", it will "overflow" to
> > > patchlevel. And that might be a problem
Em Fri, 5 Feb 2021 12:31:05 -0500
Tony Battersby escreveu:
> On 2/4/21 6:00 AM, Jiri Slaby wrote:
> > Agreed. But currently, sublevel won't "wrap", it will "overflow" to
> > patchlevel. And that might be a problem. So we might need to update the
> > header generation using e.g. "sublevel & 0xff
Hi!
> > > Ugh, I thought this was an internal representation, not an external one
> > > :(
> > >
> > > > It might work somewhere, but there are a lot of (X * 65536 + Y * 256 +
> > > > Z)
> > > > assumptions all around the world. So this doesn't look like a good idea.
> > >
> > > Ok, so what hap
On 2/4/21 6:00 AM, Jiri Slaby wrote:
> Agreed. But currently, sublevel won't "wrap", it will "overflow" to
> patchlevel. And that might be a problem. So we might need to update the
> header generation using e.g. "sublevel & 0xff" (wrap around) or
> "sublevel > 255 : 255 : sublevel" (be monotonic
On Fri, Feb 05, 2021 at 10:06:59AM +0100, Pavel Machek wrote:
> On Thu 2021-02-04 09:51:03, Greg Kroah-Hartman wrote:
> > On Thu, Feb 04, 2021 at 08:26:04AM +0100, Jiri Slaby wrote:
> > > On 04. 02. 21, 7:20, Greg Kroah-Hartman wrote:
> > > > On Thu, Feb 04, 2021 at 05:59:42AM +, Jari Ruusu wro
On Thu 2021-02-04 09:51:03, Greg Kroah-Hartman wrote:
> On Thu, Feb 04, 2021 at 08:26:04AM +0100, Jiri Slaby wrote:
> > On 04. 02. 21, 7:20, Greg Kroah-Hartman wrote:
> > > On Thu, Feb 04, 2021 at 05:59:42AM +, Jari Ruusu wrote:
> > > > Greg,
> > > > I hope that your linux kernel release script
On Thu, Feb 04, 2021 at 09:19:33PM +0100, Christoph Biedl wrote:
> David Laight wrote...
>
> > A full wrap might catch checks for less than (say) 4.4.2 which
> > might be present to avoid very early versions.
> > So sticking at 255 or wrapping onto (say) 128 to 255 might be better.
>
> Hitting su
David Laight wrote...
> A full wrap might catch checks for less than (say) 4.4.2 which
> might be present to avoid very early versions.
> So sticking at 255 or wrapping onto (say) 128 to 255 might be better.
Hitting such version checks still might happen, though.
Also, any wrapping introduces a
On Thu, Feb 04, 2021 at 04:28:19PM +, David Laight wrote:
> From: Jiri Slaby
> > Sent: 04 February 2021 11:01
> >
> > On 04. 02. 21, 9:51, Greg Kroah-Hartman wrote:
> > >> It might work somewhere, but there are a lot of (X * 65536 + Y * 256 + Z)
> > >> assumptions all around the world. So this
From: Jiri Slaby
> Sent: 04 February 2021 11:01
>
> On 04. 02. 21, 9:51, Greg Kroah-Hartman wrote:
> >> It might work somewhere, but there are a lot of (X * 65536 + Y * 256 + Z)
> >> assumptions all around the world. So this doesn't look like a good idea.
> >
> > Ok, so what happens if we "wrap"?
On 04. 02. 21, 9:51, Greg Kroah-Hartman wrote:
It might work somewhere, but there are a lot of (X * 65536 + Y * 256 + Z)
assumptions all around the world. So this doesn't look like a good idea.
Ok, so what happens if we "wrap"? What will break with that? At first
glance, I can't see anything
On Thu, Feb 04, 2021 at 08:26:04AM +0100, Jiri Slaby wrote:
> On 04. 02. 21, 7:20, Greg Kroah-Hartman wrote:
> > On Thu, Feb 04, 2021 at 05:59:42AM +, Jari Ruusu wrote:
> > > Greg,
> > > I hope that your linux kernel release scripts are
> > > implemented in a way that understands that PATCHLEVE
On 04. 02. 21, 7:20, Greg Kroah-Hartman wrote:
On Thu, Feb 04, 2021 at 05:59:42AM +, Jari Ruusu wrote:
Greg,
I hope that your linux kernel release scripts are
implemented in a way that understands that PATCHLEVEL= and
SUBLEVEL= numbers in top-level linux Makefile are encoded
as 8-bit numbers
On Thu, Feb 04, 2021 at 05:59:42AM +, Jari Ruusu wrote:
> Greg,
> I hope that your linux kernel release scripts are
> implemented in a way that understands that PATCHLEVEL= and
> SUBLEVEL= numbers in top-level linux Makefile are encoded
> as 8-bit numbers for LINUX_VERSION_CODE and
> KERNEL_VER
On Tue 2021-02-02 21:59:17, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:3aaf0a27 Merge tag 'clang-format-for-linux-v5.11-rc7' of g..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=17ef6108d0
> kernel config: http
On 1/24/21 8:01 PM, syzbot wrote:
Hello,
syzbot found the following issue on:
HEAD commit:647060f3 Add linux-next specific files for 20210120
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16f0353f50
kernel config: https://syzkaller.appspot.com/
On Tue, Nov 24, 2020 at 5:14 AM Matthew Wilcox wrote:
>
> On Mon, Nov 23, 2020 at 07:42:30PM -0800, Andrew Morton wrote:
> > Matthew's series "Overhaul multi-page lookups for THP" chnages the
> > shmem code quite a bit, and in the area of truncate. Matthew, could
> > you please fire up that repro
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger any
issue:
Reported-and-tested-by: syzbot+2393580080a2da190...@syzkaller.appspotmail.com
Tested on:
commit: 3a30363e net: sit: unregister_netdevice on newlink's error..
git tree: git://git.kernel.org/p
On Wed, 13 Jan 2021 02:27:27 -0800 syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:c49243e8 Merge branch 'net-fix-issues-around-register_netd..
> git tree: net
> console output: https://syzkaller.appspot.com/x/log.txt?x=11da7ba8d0
> kernel config: ht
On Tue, Jan 12, 2021 at 2:44 AM Jan Kara wrote:
>
> On Fri 08-01-21 18:04:21, Linus Torvalds wrote:
> >
> > Oh, and Michael Larabel (of phoronix) reports that that one-liner does
> > something bad to a few PostgreSQL tests, on the order of 5-10%
> > regression on some machines (but apparently not
On Fri 08-01-21 18:04:21, Linus Torvalds wrote:
> On Tue, Jan 5, 2021 at 11:53 AM Linus Torvalds
> wrote:
> >
> > I took your "way to go" statement as an ack, and made it all be commit
> > c2407cf7d22d ("mm: make wait_on_page_writeback() wait for multiple
> > pending writebacks").
>
> Oh, and Mic
On Fri, Jan 8, 2021 at 12:40 PM syzbot
wrote:
>
> syzbot suspects this issue was fixed by commit:
>
> commit d24396c5290ba8ab04ba505176874c4e04a2d53c
> Author: Rustam Kovhaev
> Date: Sun Nov 1 14:09:58 2020 +
>
> reiserfs: add check for an invalid ih_entry_count
>
> bisection log: http
On Sun, Jan 10, 2021 at 10:34 PM syzbot
wrote:
>
> syzbot suspects this issue was fixed by commit:
>
> commit 537cf4e3cc2f6cc9088dcd6162de573f603adc29
> Author: Magnus Karlsson
> Date: Fri Nov 20 11:53:39 2020 +
>
> xsk: Fix umem cleanup bug at socket destruct
>
> bisection log: https:
syzbot suspects this issue was fixed by commit:
commit 537cf4e3cc2f6cc9088dcd6162de573f603adc29
Author: Magnus Karlsson
Date: Fri Nov 20 11:53:39 2020 +
xsk: Fix umem cleanup bug at socket destruct
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=139f3dfb50
start commi
On Tue, Jan 5, 2021 at 11:53 AM Linus Torvalds
wrote:
>
> I took your "way to go" statement as an ack, and made it all be commit
> c2407cf7d22d ("mm: make wait_on_page_writeback() wait for multiple
> pending writebacks").
Oh, and Michael Larabel (of phoronix) reports that that one-liner does
some
syzbot suspects this issue was fixed by commit:
commit d24396c5290ba8ab04ba505176874c4e04a2d53c
Author: Rustam Kovhaev
Date: Sun Nov 1 14:09:58 2020 +
reiserfs: add check for an invalid ih_entry_count
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1731e8f750
start co
On Tue, Jan 05, 2021 at 01:22:49PM -0800, Linus Torvalds wrote:
> On Tue, Jan 5, 2021 at 1:13 PM Hugh Dickins wrote:
> >
> > I was going to raise a question, whether you should now revert
> > 073861ed77b6 ("mm: fix VM_BUG_ON(PageTail) and BUG_ON(PageWriteback)"):
> > which would not have gone in l
On Tue, Jan 5, 2021 at 1:13 PM Hugh Dickins wrote:
>
> I was going to raise a question, whether you should now revert
> 073861ed77b6 ("mm: fix VM_BUG_ON(PageTail) and BUG_ON(PageWriteback)"):
> which would not have gone in like that if c2407cf7d22d were already in.
Honestly, even if it wasn't for
On Tue, 5 Jan 2021, Linus Torvalds wrote:
> On Tue, Jan 5, 2021 at 11:31 AM Linus Torvalds
> wrote:
> > On Mon, Jan 4, 2021 at 7:29 PM Hugh Dickins wrote:
> > >
> > > > So the one-liner of changing the "if" to "while" in
> > > > wait_on_page_writeback() should get us back to what we used to do.
>
On Tue, Jan 5, 2021 at 11:31 AM Linus Torvalds
wrote:
>
> On Mon, Jan 4, 2021 at 7:29 PM Hugh Dickins wrote:
> >
> > > So the one-liner of changing the "if" to "while" in
> > > wait_on_page_writeback() should get us back to what we used to do.
> >
> > I think that is the realistic way to go.
>
>
On Mon, Jan 4, 2021 at 7:29 PM Hugh Dickins wrote:
>
> > But I feel it's really that end_page_writeback() itself is
> > fundamentally buggy, because the "wakeup" is not atomic with the bit
> > clearing _and_ it doesn't actually hold the page lock that is
> > allegedly serializing this all.
>
> And
On Mon, 4 Jan 2021, Linus Torvalds wrote:
> On Mon, Jan 4, 2021 at 12:41 PM Andrew Morton
> wrote:
>
> > Linus, how confident are you in those wait_on_page_bit_common()
> > changes?
>
> Pretty confident. The atomicity of the bitops themselves is fairly simple.
>
> But in the writeback bit? No.
On Mon, Jan 4, 2021 at 12:41 PM Andrew Morton wrote:
>
> >
> > kernel BUG at mm/page-writeback.c:2241!
> > Call Trace:
> > mpage_writepages+0xd8/0x230 fs/mpage.c:714
> > do_writepages+0xec/0x290 mm/page-writeback.c:2352
> > __filemap_fdatawrite_range+0x2a1/0x380 mm/filemap.c:422
> > fat_cont_e
On Sun, 03 Jan 2021 06:19:15 -0800 syzbot
wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:139711f0 Merge branch 'akpm' (patches from Andrew)
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=11648e9350
> kernel config: http
On Tue, Dec 22, 2020 at 11:07 PM Florian Westphal wrote:
>
> Linus Torvalds wrote:
> > On Tue, Dec 22, 2020 at 6:44 AM syzbot
> > wrote:
> > >
> > > The issue was bisected to:
> > >
> > > commit 2f78788b55ba ("ilog2: improve ilog2 for constant arguments")
> >
> > That looks unlikely, although po
Linus Torvalds wrote:
> On Tue, Dec 22, 2020 at 6:44 AM syzbot
> wrote:
> >
> > The issue was bisected to:
> >
> > commit 2f78788b55ba ("ilog2: improve ilog2 for constant arguments")
>
> That looks unlikely, although possibly some constant folding
> improvement might make the fortify code notice
On Tue, Dec 22, 2020 at 6:44 AM syzbot
wrote:
>
> The issue was bisected to:
>
> commit 2f78788b55ba ("ilog2: improve ilog2 for constant arguments")
That looks unlikely, although possibly some constant folding
improvement might make the fortify code notice something with it.
> detected buffer ov
On Sat, Dec 19, 2020 at 3:50 AM syzbot
wrote:
>
> syzbot suspects this issue was fixed by commit:
>
> commit e722a295cf493388dae474745d30e91e1a2ec549
> Author: Greg Kroah-Hartman
> Date: Thu Aug 27 12:36:27 2020 +
>
> staging: ion: remove from the tree
>
> bisection log: https://syzkal
syzbot suspects this issue was fixed by commit:
commit e722a295cf493388dae474745d30e91e1a2ec549
Author: Greg Kroah-Hartman
Date: Thu Aug 27 12:36:27 2020 +
staging: ion: remove from the tree
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17d4f13750
start commit: ab
On Wed 09-12-20 17:15:02, Miklos Szeredi wrote:
> On Wed, Dec 9, 2020 at 2:59 PM Jan Kara wrote:
> >
> > On Wed 09-12-20 14:38:42, Jan Kara wrote:
> > > Hello!
> > >
> > > so I was debugging the dnotify crash below (it's 100% reproducible for me)
> > > and I came to the following. The reproducer o
On Wed, Dec 9, 2020 at 2:59 PM Jan Kara wrote:
>
> On Wed 09-12-20 14:38:42, Jan Kara wrote:
> > Hello!
> >
> > so I was debugging the dnotify crash below (it's 100% reproducible for me)
> > and I came to the following. The reproducer opens 'file0' on FUSE
> > filesystem which is a directory at th
On Wed 09-12-20 14:38:42, Jan Kara wrote:
> Hello!
>
> so I was debugging the dnotify crash below (it's 100% reproducible for me)
> and I came to the following. The reproducer opens 'file0' on FUSE
> filesystem which is a directory at that point. Then it attached dnotify
> mark to the directory 'f
Hello!
so I was debugging the dnotify crash below (it's 100% reproducible for me)
and I came to the following. The reproducer opens 'file0' on FUSE
filesystem which is a directory at that point. Then it attached dnotify
mark to the directory 'file0' and then it does something to the FUSE fs
which
On Wed, Nov 25, 2020 at 1:30 PM Linus Torvalds
wrote:
>
> I'm not sure I'm willing to write and test the real patch, but it
> doesn't look _too_ nasty from just looking at the code. The bookmark
> thing makes it important to only actually clear the bit at the end (as
> does the handoff case anyway
On Tue, Nov 24, 2020 at 3:24 PM Linus Torvalds
wrote:
>
> I've applied your second patch (the smaller one that just takes a ref
> around the critical section). If somebody comes up with some great
> alternative, we can always revisit this.
Hmm.
I'm not sure about "great alternative", but it stri
On 2020-11-25 00:46:32 [+], Matthew Wilcox wrote:
>
> Thanks for debugging this! I didn't realise start1 was allowed to be
> less than start2. Try this ... (systemd is sabotaging my efforts to
> test an i386 kernel)
You are welcome.
Reviewed-by: Sebastian Andrzej Siewior
Sebastian
On Wed, 25 Nov 2020 at 06:16, Matthew Wilcox wrote:
>
> On Tue, Nov 24, 2020 at 06:16:28PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2020-11-24 18:52:44 [+0530], Naresh Kamboju wrote:
> > > While running LTP test case access01 the following kernel BUG
> > > noticed on linux next 20201124 tag
On Tue 24-11-20 12:19:12, Matthew Wilcox wrote:
> On Mon, Nov 23, 2020 at 08:07:24PM -0800, Hugh Dickins wrote:
> > Twice now, when exercising ext4 looped on shmem huge pages, I have crashed
> > on the PF_ONLY_HEAD check inside PageWaiters(): ext4_finish_bio() calling
> > end_page_writeback() calli
On Tue, Nov 24, 2020 at 06:16:28PM +0100, Sebastian Andrzej Siewior wrote:
> On 2020-11-24 18:52:44 [+0530], Naresh Kamboju wrote:
> > While running LTP test case access01 the following kernel BUG
> > noticed on linux next 20201124 tag kernel on i386.
> >
> > git short log:
> >
>
On Tue, Nov 24, 2020 at 1:47 PM Hugh Dickins wrote:
>
> I think the unreferenced struct page asks for trouble.
I do agree.
I've applied your second patch (the smaller one that just takes a ref
around the critical section). If somebody comes up with some great
alternative, we can always revisit t
On Tue, 24 Nov 2020, Linus Torvalds wrote:
> On Tue, Nov 24, 2020 at 12:16 PM Matthew Wilcox wrote:
> >
> > So my s/if/while/ suggestion is wrong and we need to do something to
> > prevent spurious wakeups. Unless we bury the spurious wakeup logic
> > inside wait_on_page_writeback() ...
>
> We c
On Tue, Nov 24, 2020 at 12:16 PM Matthew Wilcox wrote:
>
> So my s/if/while/ suggestion is wrong and we need to do something to
> prevent spurious wakeups. Unless we bury the spurious wakeup logic
> inside wait_on_page_writeback() ...
We can certainly make the "if()" in that loop be a "while()'.
On Tue, Nov 24, 2020 at 11:00:42AM -0800, Linus Torvalds wrote:
> On Tue, Nov 24, 2020 at 10:33 AM Matthew Wilcox wrote:
> >
> > We could fix this by turning that 'if' into a 'while' in
> > write_cache_pages().
>
> That might be the simplest patch indeed.
>
> At the same time, I do worry about o
On Tue, Nov 24, 2020 at 10:33 AM Matthew Wilcox wrote:
>
> We could fix this by turning that 'if' into a 'while' in
> write_cache_pages().
That might be the simplest patch indeed.
At the same time, I do worry about other cases like this: while
spurious wakeup events are normal and happen in othe
On Tue, Nov 24, 2020 at 08:28:16AM -0800, Hugh Dickins wrote:
> On Tue, 24 Nov 2020, Matthew Wilcox wrote:
> > On Mon, Nov 23, 2020 at 08:07:24PM -0800, Hugh Dickins wrote:
> > >
> > > Then on crashing a second time, realized there's a stronger reason against
> > > that approach. If my testing ju
On 2020-11-24 18:52:44 [+0530], Naresh Kamboju wrote:
> While running LTP test case access01 the following kernel BUG
> noticed on linux next 20201124 tag kernel on i386.
>
> git short log:
>
> git log --oneline next-20201120..next-20201124 -- mm/highmem.c
> d9927d46febf Merge bra
On Mon, 23 Nov 2020, Hugh Dickins wrote:
> On Mon, 23 Nov 2020, Linus Torvalds wrote:
> >
> > IOW, why couldn't we just make the __test_set_page_writeback()
> > increment the page count if the writeback flag wasn't already set, and
> > then make the end_page_writeback() do a put_page() after it al
On Tue, 24 Nov 2020, Matthew Wilcox wrote:
> On Mon, Nov 23, 2020 at 08:07:24PM -0800, Hugh Dickins wrote:
> >
> > Then on crashing a second time, realized there's a stronger reason against
> > that approach. If my testing just occasionally crashes on that check,
> > when the page is reused for p
On Mon, Nov 23, 2020 at 08:07:24PM -0800, Hugh Dickins wrote:
> Twice now, when exercising ext4 looped on shmem huge pages, I have crashed
> on the PF_ONLY_HEAD check inside PageWaiters(): ext4_finish_bio() calling
> end_page_writeback() calling wake_up_page() on tail of a shmem huge page,
> no lon
On Mon, 23 Nov 2020, Linus Torvalds wrote:
> On Mon, Nov 23, 2020 at 8:07 PM Hugh Dickins wrote:
> >
> > The problem is that PageWriteback is not accompanied by a page reference
> > (as the NOTE at the end of test_clear_page_writeback() acknowledges): as
> > soon as TestClearPageWriteback has been
On Mon, Nov 23, 2020 at 8:07 PM Hugh Dickins wrote:
>
> Then on crashing a second time, realized there's a stronger reason against
> that approach. If my testing just occasionally crashes on that check,
> when the page is reused for part of a compound page, wouldn't it be much
> more common for t
On Mon, Nov 23, 2020 at 8:07 PM Hugh Dickins wrote:
>
> The problem is that PageWriteback is not accompanied by a page reference
> (as the NOTE at the end of test_clear_page_writeback() acknowledges): as
> soon as TestClearPageWriteback has been done, that page could be removed
> from page cache,
On Mon, Nov 23, 2020 at 07:42:30PM -0800, Andrew Morton wrote:
> Matthew's series "Overhaul multi-page lookups for THP" chnages the
> shmem code quite a bit, and in the area of truncate. Matthew, could
> you please fire up that reproducer?
Almost certainly my fault. I was trying to get the shmem
On Mon, 30 Aug 2020, Linus Torvalds wrote:
> On Mon, Aug 31, 2020 at 3:03 AM Jan Kara wrote:
> >
> > On Fri 28-08-20 12:07:55, Jan Kara wrote:
> > >
> > > Doh, so this is:
> > >
> > > wait_on_page_writeback(page);
> > > >>> BUG_ON(PageWriteback(page));
>
1 - 100 of 3548 matches
Mail list logo
