On Tue, May 14, 2019 at 08:51:28AM +0200, Marc Haber wrote:
> On Mon, May 13, 2019 at 04:10:35PM +0200, Radim Krčmář wrote:
> > 2019-05-12 13:53+0200, Marc Haber:
> > > since updating my home desktop machine to kernel 5.1.1, KVM guests
> > > started on that machine segfault after booting:
> > [...]
On Thu, May 02, 2019 at 05:10:55PM +0200, Martin Schwidefsky wrote:
> On Thu, 2 May 2019 16:31:10 +0200
> Greg KH wrote:
>
> > On Thu, May 02, 2019 at 04:17:58PM +0200, Martin Schwidefsky wrote:
> > > On Thu, 2 May 2019 14:21:28 +0200
> > > Greg KH wrote:
> > >
> > > > On Mon, Apr 15, 2019 at
On Fri, May 17, 2019 at 10:41:28AM +0200, Ard Biesheuvel wrote:
> Returning an error here is not going to make much difference, given
> that the caller of efi_call_phys_prolog() does not bother to check it,
> and passes the result straight into efi_call_phys_epilog(), which
> happily attempts to de
save_pgd is allocated by kmalloc_array. And it is dereferenced in the
following codes. However, memory allocation functions such as
kmalloc_array may fail. Dereferencing this save_pgd null pointer may
cause the kernel go wrong. Thus we should check this allocation and add
error handling code.
Sig
Announcing a new -ck release, 5.1-ck1 with the latest version of the
Multiple Queue Skiplist Scheduler, version 0.192. These are patches
designed to improve system responsiveness and interactivity with
specific emphasis on the desktop, but configurable for any workload.
linux-5.1-ck1:
-ck1
On Thu, May 16, 2019 at 10:49:43AM +0200, Takashi Iwai wrote:
> On Thu, 16 May 2019 10:40:03 +0200,
> Gen Zhang wrote:
> >
> > tree->root and tree->nodes are allocated by memory allocation
> > functions. And tree is also an allocated memory. When allocation of
> > tree->root and tree->nodes fail
On Thu, 16 May 2019 10:40:03 +0200,
Gen Zhang wrote:
>
> tree->root and tree->nodes are allocated by memory allocation
> functions. And tree is also an allocated memory. When allocation of
> tree->root and tree->nodes fails, not freeing tree will leak memory.
> Thus we should free tree in this
tree->root and tree->nodes are allocated by memory allocation
functions. And tree is also an allocated memory. When allocation of
tree->root and tree->nodes fails, not freeing tree will leak memory.
Thus we should free tree in this situation.
Signed-off-by: Gen Zhang
---
diff --git a/sound/hd
On Sun, May 12, 2019 at 09:32:03PM +0200, Marc Haber wrote:
> I regret to inform you that I have now the third crippling issue in
> Linux 5.1, with the fourth one in the process of being isolated.
I had GPIOLIB missing in my kernel configuration. That was not
autodetected and resulted jus
On Mon, May 13, 2019 at 04:10:35PM +0200, Radim Krčmář wrote:
> 2019-05-12 13:53+0200, Marc Haber:
> > since updating my home desktop machine to kernel 5.1.1, KVM guests
> > started on that machine segfault after booting:
> [...]
> > Any idea short of bisecting?
>
> It has also been spotted by Bor
2019-05-12 13:53+0200, Marc Haber:
> since updating my home desktop machine to kernel 5.1.1, KVM guests
> started on that machine segfault after booting:
[...]
> Any idea short of bisecting?
It has also been spotted by Borislav and the fix [1] should land in the
next kernel update, thanks for the
On Sun, May 12, 2019 at 01:53:02PM +0200, Marc Haber wrote:
> Hi,
>
> since updating my home desktop machine to kernel 5.1.1, KVM guests
> started on that machine segfault after booting:
> general protection fault: [#1] PREEMPT SMP NOPTI
> CPU: 0 PID: 13 Comm: kworker/0:1 Not tainted 5.0.13-z
Hi,
I regret to inform you that I have now the third crippling issue in
Linux 5.1, with the fourth one in the process of being isolated.
This time, it's a PC Engines APU2 running in circles right after
booting:
May 12 20:56:01 prom kernel: CPU: 2 PID: 657 Comm: kworker/2:2 Tainted: G
Hi,
since updating my home desktop machine to kernel 5.1.1, KVM guests
started on that machine segfault after booting:
general protection fault: [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 13 Comm: kworker/0:1 Not tainted 5.0.13-zgsrv20080
#5.0.13.20190505.0
Hardware name: QEMU Standard PC (i440FX +
On Tue, May 7, 2019 at 3:40 PM David Binderman wrote:
>
> Hello there,
>
>
> linux-5.1/drivers/thermal/qcom/tsens-v2.c:54]: (style) Assignment
> 'last_temp=last_temp2' is redundant with condition 'last_temp==last_temp2'.
>
> Source code
s on s390 and MIPS due to bad ZERO_PAGE use
x86: make ZERO_PAGE() at least parse its argument
gcc-9: silence 'address-of-packed-member' warning
gcc-9: don't warn about uninitialized variable
gcc-9: properly declare the {pv,hv}clock_page storage
gcc-9: don't
ix build errors on s390 and MIPS due to bad ZERO_PAGE use
x86: make ZERO_PAGE() at least parse its argument
gcc-9: silence 'address-of-packed-member' warning
gcc-9: don't warn about uninitialized variable
gcc-9: properly declare the {pv,hv}clock_page storage
gcc-
On Thu, 2 May 2019 16:31:10 +0200
Greg KH wrote:
> On Thu, May 02, 2019 at 04:17:58PM +0200, Martin Schwidefsky wrote:
> > On Thu, 2 May 2019 14:21:28 +0200
> > Greg KH wrote:
> >
> > > On Mon, Apr 15, 2019 at 09:17:10AM -0700, Linus Torvalds wrote:
> > > > On Sun, Apr 14, 2019 at 10:19 PM
On Mon, Apr 29, 2019 at 07:21:36AM +0200, Michal Kubecek wrote:
> v5.1-rc7 fails to build on s390x due to
>
> vmf->page = ZERO_PAGE(vmf->vm_start);
>
> from commit 67f269b37f9b ("RDMA/ucontext: Fix regression with
> disassociate"). This is not a problem on x86_64 where ZERO_PAGE()
>
v5.1-rc7 fails to build on s390x due to
vmf->page = ZERO_PAGE(vmf->vm_start);
from commit 67f269b37f9b ("RDMA/ucontext: Fix regression with
disassociate"). This is not a problem on x86_64 where ZERO_PAGE()
doesn't use its argument but s390 version does.
I suppose the line should
Julian Anastasov (1):
ipvs: do not schedule icmp errors from tunnels
Jérôme Glisse (2):
cifs: fix page reference leak with readv/writev
zram: pass down the bvec we need to read into in the work struct
Lijun Ou (1):
RDMA/hns: Bugfix for mapping user db
Linus Torvalds (2):
The pull request you sent on Tue, 16 Apr 2019 15:41:40 +0200:
> https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b5de3c5026f52b6b409904a1c37f590a6c0e44c5
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
Linus,
The following changes since commit 771acc7e4a6e5dba779cb1a7fd851a164bc81033:
Bluetooth: btusb: request wake pin with NOAUTOEN (2019-04-09 17:38:24 -1000)
are available in the git repository at:
https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus
for you to fetch changes u
Linus,
The following changes since commit 771acc7e4a6e5dba779cb1a7fd851a164bc81033:
Bluetooth: btusb: request wake pin with NOAUTOEN (2019-04-09 17:38:24 -1000)
are available in the git repository at:
https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus
for you to fetch changes u
> Kuninori Morimoto (2):
> ASoC: audio-graph-card: don't select DPCM via audio-graph-card
> ASoC: simple-card: don't select DPCM via simple-audio-card
>
> Lendacky, Thomas (3):
> x86/perf/amd: Resolve race condition when disabling PMC
> x86/perf/am
heck tighter and more explicit
mm: add 'try_get_page()' helper function
mm: prevent get_user_pages() from overflowing page refcount
Linux 5.1-rc5
Longpeng (1):
virtio_pci: fix a NULL pointer reference in vp_del_vqs
Lorenzo Bianconi (2):
net: ip_gre: fix possib
On 4/3/19 7:34 PM, shuah wrote:
Hi Linus,
Please pull the following Kselftest update for Linux 5.1-rc4
This Kselftest update for Linux 5.1-rc4 consists of fixes to rseq,
cgroup, and efivarfs tests.
diff is attached.
thanks,
-- Shuah
Hi Linus,
I just noticed that one commit in this pull
RongQing (1):
net: ethtool: not call vzalloc for zero sized memory request
Linus Torvalds (2):
pin iocb through aio.
Linux 5.1-rc4
Liu Jian (1):
mtd: cfi: fix deadloop in cfi_cmdset_0002.c do_write_buffer
Liubin Shu (1):
net: hns: fix KASAN: use-after-free in hns_nic_n
The pull request you sent on Sat, 6 Apr 2019 00:45:47 +0200:
> https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/bc5725f97408ce78e61735858a113f514738ba3b
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
Linus,
The following changes since commit 79a3aaa7b82e3106be97842dedfd8429248896e6:
Linux 5.1-rc3 (2019-03-31 14:39:29 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus
for you to fetch changes up to
Hi Linus,
Please pull the following Kselftest update for Linux 5.1-rc4
This Kselftest update for Linux 5.1-rc4 consists of fixes to rseq,
cgroup, and efivarfs tests.
diff is attached.
thanks,
-- Shuah
The following changes
Quectel EM12
Lars Persson (1):
mm/migrate.c: add missing flush_dcache_page for non-mapped page migrate
Leslie Monis (1):
net: sched: Kconfig: update reference link for PIE
Li RongQing (1):
ieee802154: hwsim: propagate genlmsg_reply return code
Lin Yi (1):
USB: seri
The pull request you sent on Sun, 31 Mar 2019 16:31:31 +0200:
> https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/63fc9c23488d6cf34e4c233e24ba59b7e5548412
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
Linus,
The following changes since commit 8c2ffd9174779014c3fe1f96d9dc3641d9175f00:
Linux 5.1-rc2 (2019-03-24 14:02:26 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus
for you to fetch changes up to
On Wed, 27 Mar 2019, Kees Cook wrote:
> > There should be no problem except some TOMOYO messages are printed.
>
> Okay, so I should send my latest version of the patch to James? Or do
> you explicitly want TOMOYO removed from all the CONFIG_LSM default
> lines except when selected by CONFIG_DEFAU
Hi all,
As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)
(No merge commits counted, next-20190304 was the first linux-next after
the merge window opened.)
Commits in v5.1-rc1 (relative to v5.0):11241
Commits in next-20190304:
On 3/27/2019 3:55 PM, Randy Dunlap wrote:
On 3/27/19 3:23 PM, Casey Schaufler wrote:
On 3/27/2019 3:05 PM, Tetsuo Handa wrote:
On 2019/03/28 6:43, Kees Cook wrote:
I don't see problems for an exclusive LSM user (AA, SELinux, Smack)
also initializing TOMOYO, though. It should be a no-op. Is the
On 3/27/19 3:23 PM, Casey Schaufler wrote:
> On 3/27/2019 3:05 PM, Tetsuo Handa wrote:
>> On 2019/03/28 6:43, Kees Cook wrote:
> I don't see problems for an exclusive LSM user (AA, SELinux, Smack)
> also initializing TOMOYO, though. It should be a no-op. Is there some
> situation where
On 3/27/2019 3:05 PM, Tetsuo Handa wrote:
On 2019/03/28 6:43, Kees Cook wrote:
I don't see problems for an exclusive LSM user (AA, SELinux, Smack)
also initializing TOMOYO, though. It should be a no-op. Is there some
situation where this is not true?
There should be no problem except some TOMOY
On 2019/03/28 6:43, Kees Cook wrote:
>>> I don't see problems for an exclusive LSM user (AA, SELinux, Smack)
>>> also initializing TOMOYO, though. It should be a no-op. Is there some
>>> situation where this is not true?
>>
>> There should be no problem except some TOMOYO messages are printed.
>
>
On Wed, Mar 27, 2019 at 2:05 PM Tetsuo Handa
wrote:
>
> On 2019/03/28 5:45, Kees Cook wrote:
> > On Wed, Mar 27, 2019 at 1:30 PM Tetsuo Handa
> > wrote:
> >>
> >> On 2019/03/28 4:16, Kees Cook wrote:
> >>> The part I don't understand is what you've said about TOMOYO being
> >>> primary and not wa
On 2019/03/28 5:45, Kees Cook wrote:
> On Wed, Mar 27, 2019 at 1:30 PM Tetsuo Handa
> wrote:
>>
>> On 2019/03/28 4:16, Kees Cook wrote:
>>> The part I don't understand is what you've said about TOMOYO being
>>> primary and not wanting the others stackable? That kind of goes
>>> against the point,
On Wed, Mar 27, 2019 at 1:30 PM Tetsuo Handa
wrote:
>
> On 2019/03/28 4:16, Kees Cook wrote:
> > The part I don't understand is what you've said about TOMOYO being
> > primary and not wanting the others stackable? That kind of goes
> > against the point, but I'm happy to do that if you want it tha
On 2019/03/28 4:16, Kees Cook wrote:
> The part I don't understand is what you've said about TOMOYO being
> primary and not wanting the others stackable? That kind of goes
> against the point, but I'm happy to do that if you want it that way.
Automatically enabling multiple legacy major LSMs might
On Mon, Mar 25, 2019 at 2:06 PM Tetsuo Handa
wrote:
>
> On 2019/03/26 4:08, James Morris wrote:
> > On Sun, 24 Mar 2019, Randy Dunlap wrote:
> >
> >> On 3/24/19 2:26 PM, Linus Torvalds wrote:
> >>> Well, we're a week away from the merge window close, and here's rc2.
> >>> Things look fairly normal
On 2019/03/26 4:08, James Morris wrote:
> On Sun, 24 Mar 2019, Randy Dunlap wrote:
>
>> On 3/24/19 2:26 PM, Linus Torvalds wrote:
>>> Well, we're a week away from the merge window close, and here's rc2.
>>> Things look fairly normal, but honestly, rc2 is usually too early to
>>> tell. People have
On Sun, 24 Mar 2019, Randy Dunlap wrote:
> On 3/24/19 2:26 PM, Linus Torvalds wrote:
> > Well, we're a week away from the merge window close, and here's rc2.
> > Things look fairly normal, but honestly, rc2 is usually too early to
> > tell. People haven't necessarily had time to notice problems y
On 3/24/19 2:26 PM, Linus Torvalds wrote:
> Well, we're a week away from the merge window close, and here's rc2.
> Things look fairly normal, but honestly, rc2 is usually too early to
> tell. People haven't necessarily had time to notice problems yet.
> Which is just another way of saying "please
ng (1):
x86/gart: Exclude GART aperture from kcore
Kangjie Lu (3):
ALSA: echoaudio: add a check for ioremap_nocache
ALSA: sb8: add a check for request_region
x86/hyperv: Prevent potential NULL pointer dereference
Kishon Vijay Abraham I (1):
mmc: sdhci-omap: Set caps2 to indica
It's Sunday, and two weeks have passed, and everything is normal. You
all know the drill by now - the merge window is closed, and things are
supposed to calm down.
The merge window felt fairly normal to me. And looking at the stats,
nothing really odd stands out either. It's a regular sized releas
The pull request you sent on Tue, 12 Mar 2019 11:46:27 +:
> git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-5.1-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1fbf3e48123d701584bc75ccac67ef2fe412ac4c
Thank you!
--
Deet-doot-dot, I am a bot.
ndmy/linux-nfs.git tags/nfs-for-5.1-1
for you to fetch changes up to 4d6c671ace569d4b0d3f8d92ab3aef18a5d166bc:
SUNRPC: Take the transport send lock before binding+connecting (2019-03-10
14:08:19 -0400)
NFS client updates for
The pull request you sent on Wed, 6 Mar 2019 14:04:20 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
> tags/linux-kselftest-5.1-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a448c643bc49f14bb3aae68ee7085b4c7f6207d8
Thank you!
--
D
Hi Linus,
Please pull the following Kselftest update for Linux 5.1-rc1
This Kselftest update for Linux 5.1-rc1 consists of
- ir test compile warnings fixes
- seccomp test fixes and improvements from Tycho Andersen and Kees Cook
- ftrace fixes to non-POSIX-compliant constructs in colored output
Hi Rafael,
On 3/6/19 2:44 AM, Rafael J. Wysocki wrote:
Hi Shuah,
On Fri, Mar 1, 2019 at 5:47 PM shuah wrote:
Hi Rafael,
Please pull the following cpupower update for Linux 5.1-rc1.
This cpupower update for Linux 5.1-rc1 consists of a patch to add
support to display boost frequency
Hi Shuah,
On Fri, Mar 1, 2019 at 5:47 PM shuah wrote:
>
> Hi Rafael,
>
> Please pull the following cpupower update for Linux 5.1-rc1.
>
> This cpupower update for Linux 5.1-rc1 consists of a patch to add
> support to display boost frequency separately from Abhishek Goel.
Hi Rafael,
Please pull the following cpupower update for Linux 5.1-rc1.
This cpupower update for Linux 5.1-rc1 consists of a patch to add
support to display boost frequency separately from Abhishek Goel.
diff is attached.
thanks,
-- Shuah
ort (2019-02-22
09:23:46 +)
irqchip updates for Linux 5.1
- Core pseudo-NMI handling code
- Allow the default irq domain to be retrieved
- A new interrupt controller for the Loongson LS1X platform
- Affinity support for the SiFiv
58 matches
Mail list logo
