On Mon, 2018-01-15 at 07:01 -0800, Hellwig, Christoph wrote:
> Laurence, I'm a little confused. Is this the same issue we just
> fixed,
> or is this an issue showing up with the fix?
>
> E.g. what kernel versions or trees are affected?
Hello Christoph
This showed up on a combined tree of Mikes
Laurence, I'm a little confused. Is this the same issue we just fixed,
or is this an issue showing up with the fix?
E.g. what kernel versions or trees are affected?
On Mon, 2018-01-15 at 20:17 +0800, Ming Lei wrote:
> On Sun, Jan 14, 2018 at 06:40:40PM -0500, Laurence Oberman wrote:
> > On Thu, 2018-01-04 at 14:32 -0800, Vinson Lee wrote:
> > > Hi.
> > >
> > > HP ProLiant DL360p Gen8 with Smart Array P420i boots to the log
On Sun, Jan 14, 2018 at 06:40:40PM -0500, Laurence Oberman wrote:
> On Thu, 2018-01-04 at 14:32 -0800, Vinson Lee wrote:
> > Hi.
> >
> > HP ProLiant DL360p Gen8 with Smart Array P420i boots to the login
> > prompt and hangs with Linux 4.13 or later. I cannot log in on
Hi,
I have a reproducer program. It takes about 3-5 minutes to trigger the
hang. The only calls are mmap, open, write, and readahead and the
writes are fairly small (512 bytes).
Reproducer Program: https://pastebin.com/cx1cgABc
Report: https://pastebin.com/uGTAw45E
Logs: https://pastebin.com/EaiE
Hi,
I am fuzzing the kernel 4.13-rc7 with Syzkaller with Reiserfs. I am
getting the following crash:
INFO: task kworker/0:3:1103 blocked for more than 120 seconds.
Here is the full stack trace. I noticed that there are a few tasks
holding a sbi->lock. Below are a report and a log of all the pro
Larry Finger writes:
> On 09/21/2017 06:37 AM, Zwindl wrote:
>> Hi, I've reported to archlinux's bugzilla, and finally found out the
>> flag which caused that issue, it's the
>> `CONFIG_INTEL_IOMMU_DEFAULT_ON=y` flag, I think may this is a kernel
>> bug, more details at https://bugs.archlinux.org
On 09/21/2017 06:37 AM, Zwindl wrote:
Hi, I've reported to archlinux's bugzilla, and finally found out the flag which
caused that issue, it's the `CONFIG_INTEL_IOMMU_DEFAULT_ON=y` flag, I think may
this is a kernel bug, more details at https://bugs.archlinux.org/task/55665
My standard kernel h
On Mon, Sep 18, 2017 at 04:19:08PM +0200, Arnd Bergmann wrote:
> On Mon, Sep 18, 2017 at 12:57 PM, kernelci.org bot wrote:
> >
> > stable-rc/linux-4.13.y build: 208 builds: 0 failed, 208 passed, 29 warnings
> > (v4.13.2-53-gb857b6dfc252)
>
> Same as v4.9, please backp
On Mon, Sep 18, 2017 at 12:57 PM, kernelci.org bot wrote:
>
> stable-rc/linux-4.13.y build: 208 builds: 0 failed, 208 passed, 29 warnings
> (v4.13.2-53-gb857b6dfc252)
Same as v4.9, please backport
7bf7a193a90c ("xfs: fix compiler warnings")
Arnd
On 09/16/2017 06:27 AM, Zwindl wrote:
Hi, I've done the test, and the weird thing happened. The kernel buit with this
config file https://ptpb.pw/HF1g which is from
https://aur.archlinux.org/packages/linux-git/ can run properly, the wifi can
connect, despite which version it is, but, with this
On 09/15/2017 12:12 PM, Zwindl wrote:
Thanks for your patient and advice, I'll keep that in mind.
I do want help, and I got 1 day to build the system, but I can't recall how to
compile it, The last time I compile kernel is 2013, so, maybe I'll ask you so
many stupid questions during the build t
On 09/15/2017 05:10 AM, Zwindl wrote:
Original Message
Subject: Re: RTL8192EE PCIe Wireless Network Adapter crashed with linux-4.13
Local Time: 14 September 2017 6:05 PM
UTC Time: 14 September 2017 18:05
From: larry.fin...@lwfinger.net
To: Zwindl , linux-wirel
On 09/14/2017 08:30 AM, Zwindl wrote:
Dear developers:
I'm using Arch Linux with testing enabled, the current kernel version and
details are
`Linux zwindl 4.13.2-1-ARCH #1 SMP PREEMPT Thu Sep 14 02:57:34 UTC 2017 x86_64
GNU/Linux`.
The wireless card can't work properly from the kernel 4.13. Her
Update to iproute2 utility to support new features in Linux 4.13.
This is a larger than usual release because of lots of updates for BPF
and the new RDMA utility. Lots of cleanups and Coverity reported
potential issues as well.
Source:
https://www.kernel.org/pub/linux/utils/net/iproute2
Oh, and a side note on the merge window for 4.14 that obviously opened
as a result of the 4.13 release..
Tomorrow being Labor Day(*) in the US, I'm likely not merging as much
as I usually try to do early in the merge window. I'll probably do
some early pull requests today, do _some_ stuff tomorrow
eference on state and tmpl sort
Krzysztof Kozlowski (1):
c6x: defconfig: Cleanup from old Kconfig options
Linus Torvalds (3):
page waitqueue: always add new entries at the end
Revert "rmap: do not call mmu_notifier_invalidate_page() under ptl"
Linux 4.13
Lorenzo Co
On Sun, Sep 3, 2017 at 2:36 AM, Thorsten Leemhuis
wrote:
>
> [x86/mm/gup] e585513b76: will-it-scale.per_thread_ops -6.9% regression
> Status: Asked on the list, but looks like issue gets ignored by everyone
> Note: I'm a bit unsure if adding this issue to this list was a good
> idea. Side note: Wa
Hi! Find below my fifth regression report for Linux 4.13. It lists 4
regressions I'm currently aware of. There are no new ones; 2 got fixed
since the last report.
You can also find the report at http://bit.ly/lnxregrep413 where I try
to update it every now and then.
As always: Are you awa
Hi! Find below my fourth regression report for Linux 4.13. It lists 6
regressions I'm currently aware of. 1 of them is new, 5 got fixed since
the last report (that was two weeks ago; didn't find time for compiling
one last week; sorry). You can also find the report at
http://bit.ly/ln
1: Fix to remove BBAT_CONT register from chip model"
Linus Torvalds (5):
Revert "pty: fix the cached path of the pty slave file
descriptor in the master"
Clarify (and fix) MAX_LFS_FILESIZE macros
Minor page waitqueue cleanups
Avoid page waitqueue race leaving po
audio_clkout naming conflict
Laura Abbott (1):
mm/vmalloc.c: don't unconditonally use __GFP_HIGHMEM
Linus Torvalds (3):
pty: fix the cached path of the pty slave file descriptor in the master
Sanitize 'move_pages()' permission checks
Linux 4.13-rc6
Lionel Lan
Hi! Find below my third regression report for Linux 4.13. It lists 11
regressions I'm currently aware of (or 10 if you count the two scsi-mq
regressions discussions as one). 4 regressions are new; 3 got fixed
since last weeks report (two others didn't even make it to the report,
as
B/core: Allow QP state transition from reset to error"
RDMA/uverbs: Prevent leak of reserved field
RDMA/mlx5: Fix existence check for extended address vector
Linus Lüssing (1):
batman-adv: fix TT sync flag inconsistencies
Linus Torvalds (1):
Linux 4.13-rc5
Lionel
On 8/6/17 9:59 AM, Thorsten Leemhuis wrote:
> Hi! Find below my second regression report for Linux 4.13. It lists 10
> regressions I'm currently aware of (albeit in one case it's not entirely
> clear yet if it's a regression in 4.13). One regression got fixed since
>
On Wed, Aug 9, 2017 at 11:56 PM, Pavel Machek wrote:
> Hi!
>
>> >[You seem to have a stale linux-pm address in your address book,
>> >I replaced it with the current one in the CC list.]
>
> Thanks, fixed.
>
>> >>ACPI S3, right. Machine still wakes up properly when I hit a key on
>> >>USB keyboard.
Hi!
> >[You seem to have a stale linux-pm address in your address book,
> >I replaced it with the current one in the CC list.]
Thanks, fixed.
> >>ACPI S3, right. Machine still wakes up properly when I hit a key on
> >>USB keyboard.
> >
> >OK, so my guess would be a driver issue. What driver is
On Wed, Aug 9, 2017 at 11:15 PM, Hisashi T Fujinaka wrote:
> On Wed, 9 Aug 2017, Rafael J. Wysocki wrote:
>
>> [You seem to have a stale linux-pm address in your address book,
>> I replaced it with the current one in the CC list.]
>>
>> On Wednesday, August 9, 2017 8:42:31 AM CEST Pavel Machek wro
On Wed, 9 Aug 2017, Rafael J. Wysocki wrote:
[You seem to have a stale linux-pm address in your address book,
I replaced it with the current one in the CC list.]
On Wednesday, August 9, 2017 8:42:31 AM CEST Pavel Machek wrote:
On Wed 2017-08-09 02:45:54, Rafael J. Wysocki wrote:
On Tuesday, A
[You seem to have a stale linux-pm address in your address book,
I replaced it with the current one in the CC list.]
On Wednesday, August 9, 2017 8:42:31 AM CEST Pavel Machek wrote:
> On Wed 2017-08-09 02:45:54, Rafael J. Wysocki wrote:
> > On Tuesday, August 8, 2017 11:00:53 AM CEST Pavel Machek
On Wed 2017-08-09 02:45:54, Rafael J. Wysocki wrote:
> On Tuesday, August 8, 2017 11:00:53 AM CEST Pavel Machek wrote:
> > Hi!
> >
> > Perhaps you should get regressi...@kernel.org alias, or something like that?
> >
> > > As always: Are you aware of any other regressions? Then please let me
> > >
On Tuesday, August 8, 2017 11:00:53 AM CEST Pavel Machek wrote:
> Hi!
>
> Perhaps you should get regressi...@kernel.org alias, or something like that?
>
> > As always: Are you aware of any other regressions? Then please let me
> > know. For details see http://bit.ly/lnxregtrackid And please tell
Hi!
Perhaps you should get regressi...@kernel.org alias, or something like that?
> As always: Are you aware of any other regressions? Then please let me
> know. For details see http://bit.ly/lnxregtrackid And please tell me if
> there is anything in the report that shouldn't be there.
I am using
Hi!
> Hi! Find below my second regression report for Linux 4.13. It lists 10
> regressions I'm currently aware of (albeit in one case it's not entirely
> clear yet if it's a regression in 4.13). One regression got fixed since
> last weeks report. You can also find th
hang
on Exynos4412
Kuninori Morimoto (2):
arm64: renesas: salvator-common: sound clock-frequency needs
descending order
ASoC: sh: hac: add missing "int ret"
Kuppuswamy Sathyanarayanan (1):
MAINTAINERS: Add entry for Whiskey Cove PMIC GPIO driver
Larry Finger (1):
Hi! Find below my second regression report for Linux 4.13. It lists 10
regressions I'm currently aware of (albeit in one case it's not entirely
clear yet if it's a regression in 4.13). One regression got fixed since
last weeks report. You can also find the report at
http://bit.
On Tue, 2017-08-01 at 13:50 -0400, da...@codemonkey.org.uk wrote:
> On Tue, Aug 01, 2017 at 10:20:31AM -0700, Linus Torvalds wrote:
>
> > So I think the 'pathname' part may actually be entirely a red
> herring,
> > and it's the underlying access itself that just picks up a random
> > pointer fr
On Tue, Aug 1, 2017 at 10:20 AM, Linus Torvalds
wrote:
>
> So I think the 'pathname' part may actually be entirely a red herring,
> and it's the underlying access itself that just picks up a random
> pointer from a stack that now contains something different. And KASAN
> didn't notice the stale st
On Tue, Aug 01, 2017 at 10:20:31AM -0700, Linus Torvalds wrote:
> So I think the 'pathname' part may actually be entirely a red herring,
> and it's the underlying access itself that just picks up a random
> pointer from a stack that now contains something different. And KASAN
> didn't notice t
On Tue, 2017-08-01 at 10:20 -0700, Linus Torvalds wrote:
> On Tue, Aug 1, 2017 at 8:51 AM, da...@codemonkey.org.uk
> wrote:
> > On Mon, Jul 31, 2017 at 10:35:45PM -0700, Linus Torvalds wrote:
> > > Any chance of getting the output from
> > >
> > >./scripts/faddr2line vmlinux
> > nfs4_exchan
On Tue, Aug 1, 2017 at 8:51 AM, da...@codemonkey.org.uk
wrote:
> On Mon, Jul 31, 2017 at 10:35:45PM -0700, Linus Torvalds wrote:
> > Any chance of getting the output from
> >
> >./scripts/faddr2line vmlinux nfs4_exchange_id_done+0x3d7/0x8e0
>
>
> Hm, that points to this..
>
> 7463
On Mon, Jul 31, 2017 at 10:35:45PM -0700, Linus Torvalds wrote:
> On Mon, Jul 31, 2017 at 8:43 AM, da...@codemonkey.org.uk
> wrote:
> > Another NFSv4 KASAN splat, this time from rc3.
> >
> > BUG: KASAN: use-after-free in nfs4_exchange_id_done+0x3d7/0x8e0 [nfsv4]
>
> Ugh. It's really hard t
On Mon, Jul 31, 2017 at 8:43 AM, da...@codemonkey.org.uk
wrote:
> Another NFSv4 KASAN splat, this time from rc3.
>
> BUG: KASAN: use-after-free in nfs4_exchange_id_done+0x3d7/0x8e0 [nfsv4]
Ugh. It's really hard to tell what access that it - KASAN doesn't
actually give enough information. There's
Another NFSv4 KASAN splat, this time from rc3.
==
BUG: KASAN: use-after-free in nfs4_exchange_id_done+0x3d7/0x8e0 [nfsv4]
Read of size 8 at addr 8804508af528 by task kworker/2:1/34
CPU: 2 PID: 34 Comm: kworker/2:1 Not tainted 4.
ng reconfig remove
Liang Li (1):
virtio-balloon: deflate via a page list
Lin Ma (2):
tools/kvm_stat: use variables instead of hard paths in help output
tools/kvm_stat: add '-f help' to get the available event list
Linus Torvalds (1):
Linux 4.13-rc3
Maarten
On Sun, Jul 30, 2017 at 4:49 PM, Thorsten Leemhuis
wrote:
> Hi! Find below my first regression report for Linux 4.13. It lists 8
> regressions I'm currently aware of (a few others I had on my list got
> fixed in the past few days). You can also find it at
> http://bit.ly/lnxregr
Hi! Find below my first regression report for Linux 4.13. It lists 8
regressions I'm currently aware of (a few others I had on my list got
fixed in the past few days). You can also find it at
http://bit.ly/lnxregrep413 where I try to update it every now and then.
As always: Are you aware o
On Sun, Jul 23, 2017 at 4:48 PM, Linus Torvalds
wrote:
> Things are chugging along, and we actually had a reasonably active rc2.
.. and Konstantin just noticed that I had forgotten to push out the
actual tag, so the scripts that generate the diffs and tar-balls
didn't run.
So the git trees conta
ate flag
IB/mlx5: Clean mr_cache debugfs in case of failure
Levin, Alexander (1):
wireless: wext: terminate ifr name coming from userspace
Linus Torvalds (4):
x86: mark kprobe templates as character arrays, not single characters
Fix up MAINTAINERS file problems
Properly a
On Sun, Jul 16, 2017 at 8:05 PM, da...@codemonkey.org.uk
wrote:
> On Sun, Jul 16, 2017 at 10:57:27PM +, Trond Myklebust wrote:
>
> > > BUG: KASAN: global-out-of-bounds in call_start+0x93/0x100
> > > Read of size 8 at addr 8d582588 by task kworker/0:1/22
> >
> > Does the following p
Hi all,
As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)
(No merge commits counted, next-20170704 was the first linux-next after
the merge window opened.)
Commits in v4.13-rc1 (relative to v4.12): 11258
Commits in next-20170704:
On Sun, Jul 16, 2017 at 10:57:27PM +, Trond Myklebust wrote:
> > BUG: KASAN: global-out-of-bounds in call_start+0x93/0x100
> > Read of size 8 at addr 8d582588 by task kworker/0:1/22
>
> Does the following patch fix it?
Yep, seems to do the trick!
Dave
Hi Dave,
On Sun, 2017-07-16 at 17:15 -0400, Dave Jones wrote:
> On Fri, Jul 14, 2017 at 10:25:43AM -0400, Dave Jones wrote:
> > On Thu, Jul 13, 2017 at 05:16:24PM -0400, Anna Schumaker wrote:
> > > Hi Linus,
> > >
> > > The following changes since commit
> 32c1431eea4881a6b17bd7c639315010a
On Fri, Jul 14, 2017 at 10:25:43AM -0400, Dave Jones wrote:
> On Thu, Jul 13, 2017 at 05:16:24PM -0400, Anna Schumaker wrote:
> > Hi Linus,
> >
> > The following changes since commit
> 32c1431eea4881a6b17bd7c639315010aeefa452:
> >
> > Linux 4.12-rc5 (2017-06-11 16:48:20 -0700)
>
Ok, normally I do this on Sunday afternoon, but occasionally it
happens a day early like now to avoid people timing me.
In fact, I was planning on doing it yesterday evening this time around
because I was so annoyed with lots of late pull requests on Friday
(and some today), but ended up going to
> I find "hardening" code that adds bugs to be particularly bad and
> ugly, the same way that I absolutely *hate* debugging code that turns
> out to make debugging impossible (we had that with the "better" stack
> tracing code that caused kernel panics to kill the machine entirely
> rather than sho
> The reason q_size isn't used is because it doesn't yet prevent read
> overflow. The commit message mentions that among the current
> limitations
> along with __builtin_object_size(ptr, 1).
Er rather, in strlcat, the q_size is unused after the fast path is
because strnlen obtains the constant aga
On Fri, 2017-07-14 at 13:50 -0700, Linus Torvalds wrote:
> On Fri, Jul 14, 2017 at 1:38 PM, Daniel Micay
> wrote:
> >
> > If strscpy treats the count parameter as a *guarantee* of the dest
> > size
> > rather than a limit,
>
> No, it's a *limit*.
>
> And by a *limit*, I mean that we know that w
> My initial patch used strlcpy there, because I wasn't aware of strscpy
> before it was suggested:
>
> http://www.openwall.com/lists/kernel-hardening/2017/05/04/11
>
> I was wrong to move it to strscpy. It could be switched back to
> strlcpy
> again unless the kernel considers the count paramete
On Fri, Jul 14, 2017 at 1:38 PM, Daniel Micay wrote:
>
> If strscpy treats the count parameter as a *guarantee* of the dest size
> rather than a limit,
No, it's a *limit*.
And by a *limit*, I mean that we know that we can access both source
and destination within that limit.
> My initial patch
On Fri, 2017-07-14 at 12:58 -0700, Linus Torvalds wrote:
> On Fri, Jul 14, 2017 at 12:43 PM, Andrey Ryabinin
> wrote:
> >
> > > yet when I look at the generated code for __ip_map_lookup, I see
> > >
> > >movl$32, %edx #,
> > >movq%r13, %rsi # class,
> > >
On 07/14/2017 10:58 PM, Linus Torvalds wrote:
> On Fri, Jul 14, 2017 at 12:43 PM, Andrey Ryabinin
> wrote:
>>
>>> yet when I look at the generated code for __ip_map_lookup, I see
>>>
>>>movl$32, %edx #,
>>>movq%r13, %rsi # class,
>>>leaq48(%rax), %r
On Fri, Jul 14, 2017 at 12:43 PM, Andrey Ryabinin
wrote:
>
>> yet when I look at the generated code for __ip_map_lookup, I see
>>
>>movl$32, %edx #,
>>movq%r13, %rsi # class,
>>leaq48(%rax), %rdi #, tmp126
>>callstrscpy #
>>
>> what's the
On Fri, Jul 14, 2017 at 12:05:02PM -0700, Linus Torvalds wrote:
> On Fri, Jul 14, 2017 at 7:25 AM, Dave Jones wrote:
> > On Thu, Jul 13, 2017 at 05:16:24PM -0400, Anna Schumaker wrote:
> > >
> > > git://git.linux-nfs.org/projects/anna/linux-nfs.git
> > tags/nfs-for-4.13-1
> >
> > Since
On 07/14/2017 10:05 PM, Linus Torvalds wrote:
> On Fri, Jul 14, 2017 at 7:25 AM, Dave Jones wrote:
>> On Thu, Jul 13, 2017 at 05:16:24PM -0400, Anna Schumaker wrote:
>> >
>> > git://git.linux-nfs.org/projects/anna/linux-nfs.git tags/nfs-for-4.13-1
>>
>> Since this landed, I'm seeing this dur
On Fri, Jul 14, 2017 at 7:25 AM, Dave Jones wrote:
> On Thu, Jul 13, 2017 at 05:16:24PM -0400, Anna Schumaker wrote:
> >
> > git://git.linux-nfs.org/projects/anna/linux-nfs.git tags/nfs-for-4.13-1
>
> Since this landed, I'm seeing this during boot..
>
> ===
On Fri, Jul 14, 2017 at 10:25:43AM -0400, Dave Jones wrote:
> On Thu, Jul 13, 2017 at 05:16:24PM -0400, Anna Schumaker wrote:
> > Hi Linus,
> >
> > The following changes since commit
> 32c1431eea4881a6b17bd7c639315010aeefa452:
> >
> > Linux 4.12-rc5 (2017-06-11 16:48:20 -0700)
> >
> >
On Thu, Jul 13, 2017 at 05:16:24PM -0400, Anna Schumaker wrote:
> Hi Linus,
>
> The following changes since commit 32c1431eea4881a6b17bd7c639315010aeefa452:
>
> Linux 4.12-rc5 (2017-06-11 16:48:20 -0700)
>
> are available in the git repository at:
>
> git://git.linux-nfs.org/projec
On 07/14/2017 03:09 AM, Christoph Hellwig wrote:
> On Thu, Jul 13, 2017 at 02:43:14PM -0700, Linus Torvalds wrote:
>> On Thu, Jul 13, 2017 at 2:16 PM, Anna Schumaker
>> wrote:
>>>
>>> git://git.linux-nfs.org/projects/anna/linux-nfs.git tags/nfs-for-4.13-1
>>
>> Btw, your key seems to have expi
Hi Linus,
Very little activity in the befs file system this time since I'm busy
settling into a new job.
Hence the new-car-smell shiny address [0].
Merged one patch from Tommy Nguyen related to documentation.
Thank you very much,
Luis
[0] https://lkml.org/lkml/2017/7/9/37
The following chang
On Thu, Jul 13, 2017 at 02:43:14PM -0700, Linus Torvalds wrote:
> On Thu, Jul 13, 2017 at 2:16 PM, Anna Schumaker
> wrote:
> >
> > git://git.linux-nfs.org/projects/anna/linux-nfs.git tags/nfs-for-4.13-1
>
> Btw, your key seems to have expired, and doing a refresh on it doesn't fix it.
>
> I'm
On Thu, Jul 13, 2017 at 2:16 PM, Anna Schumaker
wrote:
>
> git://git.linux-nfs.org/projects/anna/linux-nfs.git tags/nfs-for-4.13-1
Btw, your key seems to have expired, and doing a refresh on it doesn't fix it.
I'm sure you've refreshed your key, but apparently that refresh hasn't
been percolat
Hi Linus,
The following changes since commit 32c1431eea4881a6b17bd7c639315010aeefa452:
Linux 4.12-rc5 (2017-06-11 16:48:20 -0700)
are available in the git repository at:
git://git.linux-nfs.org/projects/anna/linux-nfs.git tags/nfs-for-4.13-1
for you to fetch changes up to b4f937cffa66b3d56
73 matches
Mail list logo
