I'm announcing the release of the 4.9.246 kernel.
All users of the 4.9 kernel series must upgrade.
The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:
diff --git a/Makefile b/Makefile
index 2d9e5c4688a4..c42ada4e8846 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 4
-SUBLEVEL = 245
+SUBLEVEL = 246
EXTRAVERSION =
NAME = Blurry Fish Butt
diff --git a/arch/arm/boot/dts/imx50-evk.dts
I'm announcing the release of the 4.4.246 kernel.
All users of the 4.4 kernel series must upgrade.
The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.4.y
and can be browsed at the normal kernel.org git web browser:
On Tue, Nov 24, 2020 at 10:59:48AM +, Catalin Marinas wrote:
> Hi Mike,
>
> On Tue, Nov 24, 2020 at 11:25:51AM +0200, Mike Rapoport wrote:
> > +static vm_fault_t secretmem_fault(struct vm_fault *vmf)
> > +{
> > + struct address_space *mapping = vmf->vma->vm_file->f_mapping;
...
> > +
> >
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
On Tue, Nov 24, 2020 at 03:08:09PM +0100, Florian Weimer wrote:
> Do you categorically reject the general advice, or specific instances as
> well?
All of the above. Really, if people decided to use seccompt to return
nonsensical error codes we should not work around that in new kernel
ABIs.
On Tue, Nov 24, 2020 at 03:08:05PM +0100, Mark Wielaard wrote:
> For valgrind the issue is statx which we try to use before falling back
> to stat64, fstatat or stat (depending on architecture, not all define
> all of these). The problem with these fallbacks is that under some
> containers
On Tue, Nov 24, 2020 at 5:42 AM Oleg Nesterov wrote:
>
> On 11/23, Suren Baghdasaryan wrote:
> >
> > + if (madvise_destructive(behavior)) {
> > + /* Allow destructive madvise only on a dying processes */
> > + if (!signal_group_exit(task->signal)) {
>
>
> >> >>
> >> >> That's the typical long latency avoidance method.
> >> >>
> >> >> > The question is, which value we should use as a batch_threshold: 100,
> >> >> > 1000, etc.
> >> >>
> >> >> I think we can do some measurement to determine it?
> >> >>
> >> > Hmm.. looking at it one more time i
On Tue, Nov 24, 2020 at 04:21:48PM +0100, Linus Walleij wrote:
> > What people think they were sold was the idea that they shouldn't have
> > to write driver code or upstream things, something with more AML like
> > capabilities (not realising that AML works partly because ACPI hugely
> >
On Tue 24 Nov 09:34 CST 2020, Vinod Koul wrote:
> On 22-11-20, 23:21, Bjorn Andersson wrote:
> > Every now and then it's convenient to be able to inspect the content of
> > SMEM items. Rather than carrying some hack locally let's upstream a
> > driver that when inserted exposes a debugfs
On Tue, 24 Nov 2020 11:41:40 +0100 Yves-Alexis Perez wrote:
> On Sat, 2020-11-21 at 14:03 -0800, Jakub Kicinski wrote:
> > Applied to net with the typo fixed, thanks!
>
> Thanks!
>
> Is there any chance it'll be in 5.10 or will it have to wait for the 5.11
> merge window?
It'll be in
Hi Tom,
Daniel asked about filtering bitmasks, something like:
cpumask != 0xff
Looking into the code, I realized that bitmasks are dynamic arrays, and
there's no logic in the filter code to handle dynamic arrays of anything
other than 'char' type (which are dynamic strings).
If you have any
Applied. Thanks!
Alex
On Mon, Nov 23, 2020 at 7:42 PM Quan, Evan wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
> Reviewed-by: Evan Quan
>
> -Original Message-
> From: Colin King
> Sent: Monday, November 23, 2020 6:54 PM
> To: Deucher, Alexander ; Koenig, Christian
On 11/23/20 9:42 AM, Alex Belits wrote:
> This is an update of task isolation work that was originally done by
> Chris Metcalf and maintained by him until
> November 2017. It is adapted to the current kernel and cleaned up to
> implement its functionality in a more complete and cleaner manner.
On Tue, Nov 24, 2020 at 05:02:18PM +0100, Bastien Nocera wrote:
> On Wed, 2020-11-11 at 17:32 +0100, Greg KH wrote:
> > On Wed, Nov 11, 2020 at 04:03:30PM +, Limonciello, Mario wrote:
> > > > > > Given we're effectively ending up with the combination of
> > > > > > runtime PM turned
> > > > >
On Mon, Nov 23, 2020 at 6:21 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:382:23: warning:
> ‘ecc_umc_mcumc_status_addrs’ defined but not used [-Wunused-const-variable=]
> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:720: warning:
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
On 2020-11-24 15:38, Ricardo Ribalda wrote:
On architectures where the is no coherent caching such as ARM use the
dma_alloc_noncontiguos API and handle manually the cache flushing using
dma_sync_single().
With this patch on the affected architectures we can measure up to 20x
performance
On Mon, Nov 23, 2020 at 6:20 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:382:23: warning:
> ‘ecc_umc_mcumc_status_addrs’ defined but not used [-Wunused-const-variable=]
>
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc:
16.11.2020 20:42, Gabriel Krisman Bertazi пишет:
> When one the generic syscall entry code, use the syscall_work field in
> struct thread_info and specific SYSCALL_WORK flags to setup this syscall
> work. This flag has the advantage of being architecture independent.
>
> Users of the flag
From: David Laight
> Sent: 20 November 2020 15:39
>
> From: Thomas Zimmermann
> > Sent: 20 November 2020 13:42
> ...
> > I did a diff from v5.10-rc4 to drm-tip to look for suspicious changes.
> > Some candidates are
> >
> >8e3784dfef8a ("drm/ast: Reload gamma LUT after changing primary
> >
On Mon, Nov 23, 2020 at 6:21 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c:618: warning: Function parameter or
> member 'flush_type' not described in 'gmc_v8_0_flush_gpu_tlb_pasid'
> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c:618:
On Mon, Nov 23, 2020 at 6:20 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c:433: warning: Function parameter or
> member 'flush_type' not described in 'gmc_v7_0_flush_gpu_tlb_pasid'
> drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c:433:
On Tue, Nov 24, 2020 at 02:14:45PM +, Marc Zyngier wrote:
> Some interrupts (such as the rescheduling IPI) rely on not going through
> the irq_enter()/irq_exit() calls. To distinguish such interrupts, add
> a new IRQ flag that allows the low-level handling code to sidestep the
> enter()/exit()
Hi,
On Tue, Nov 24, 2020 at 1:19 AM Rakesh Pillai wrote:
>
> > -Original Message-
> > From: Doug Anderson
> > Sent: Tuesday, November 24, 2020 6:27 AM
> > To: Abhishek Kumar
> > Cc: Kalle Valo ; Rakesh Pillai
> > ; LKML ; ath10k
> > ; Brian Norris ;
> > linux-wireless ; David S. Miller
On Wed, Nov 18, 2020 at 03:36:47PM +0100, Andrea Parri (Microsoft) wrote:
> When channel->device_obj is non-NULL, vmbus_onoffer_rescind() could
> invoke put_device(), that will eventually release the device and free
> the channel object (cf. vmbus_device_release()). However, a pointer
> to the
Dear Linux folks,
On the Intel Tiger Lake Dell XPS 13 9310 Linux 5.9.9 from Debian
sid/unstable logged the messages below. Please find the whole log in the
Linux bug tracker [1].
```
kernel: BERT: Error records from previous boot:
kernel: [Hardware Error]: event severity: fatal
kernel:
On Wed, Nov 18, 2020 at 05:37:15PM -0800, Jakub Kicinski wrote:
> On Wed, 18 Nov 2020 16:33:10 +0100 Andrea Parri (Microsoft) wrote:
> > Lack of validation could lead to out-of-bound reads and information
> > leaks (cf. usage of nvdev->chan_table[]). Check that the number of
> > allocated
On Wed 04 Nov 01:03 CST 2020, Sibi Sankar wrote:
> The application processor accessing the MBA region after assigning it to
> the remote Q6 would lead to an XPU violation. Fix this by un-mapping the
> MBA region post firmware copy and MBA text log dumps.
>
> Signed-off-by: Sibi Sankar
On Mon, Nov 23, 2020 at 6:20 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c:448: warning: Function parameter or
> member 'flags' not described in 'uvd_v4_2_ring_emit_fence'
> drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c:448: warning:
On Mon, Nov 23, 2020 at 6:20 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/cik_sdma.c:282: warning: Function parameter or
> member 'flags' not described in 'cik_sdma_ring_emit_fence'
> drivers/gpu/drm/amd/amdgpu/cik_sdma.c:282: warning:
On Fri, Nov 20, 2020 at 04:30:19PM -0800, Nuno Das Neves wrote:
> This patch series provides a userspace interface for creating and running
> guest
> virtual machines while running on the Microsoft Hypervisor [0].
>
> Since managing guest machines can only be done when Linux is the root
>
On Tue, Nov 24, 2020 at 03:40:21PM +0100, Ulf Hansson wrote:
> It looks like Christoph is planning for some rewrite of the pstore
> code, so let's see what that means in regards to this.
Here is what I posted last month:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/pstore
On Mon, Nov 23, 2020 at 6:20 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> In file included from
> drivers/gpu/drm/amd/amdgpu/dimgrey_cavefish_reg_init.c:28:
> drivers/gpu/drm/amd/amdgpu/../include/dimgrey_cavefish_ip_offset.h:151:29:
> warning: ‘UMC_BASE’ defined
MSI support for platform devices.
Signed-off-by: Vikas Gupta
---
drivers/vfio/platform/vfio_platform_common.c | 99 ++-
drivers/vfio/platform/vfio_platform_irq.c | 260 +-
drivers/vfio/platform/vfio_platform_private.h | 16 ++
include/uapi/linux/vfio.h
This RFC adds support for MSI for platform devices.
MSI block is added as an ext irq along with the existing
wired interrupt implementation.
Changes from:
-
v1 to v2:
1) IRQ allocation has been implemented as below:
On Fri, Nov 20, 2020 at 04:30:31PM -0800, Nuno Das Neves wrote:
[...]
> diff --git a/virt/mshv/mshv_main.c b/virt/mshv/mshv_main.c
> index c9445d2edb37..7ddb66d260ce 100644
> --- a/virt/mshv/mshv_main.c
> +++ b/virt/mshv/mshv_main.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
>
On Mon, Nov 23, 2020 at 6:20 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> In file included from drivers/gpu/drm/amd/amdgpu/vangogh_reg_init.c:28:
> drivers/gpu/drm/amd/amdgpu/../include/vangogh_ip_offset.h:210:29: warning:
> ‘USB_BASE’ defined but not used
On Mon, Nov 23, 2020 at 6:20 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> In file included from
> drivers/gpu/drm/amd/amdgpu/sienna_cichlid_reg_init.c:28:
> drivers/gpu/drm/amd/amdgpu/../include/sienna_cichlid_ip_offset.h:186:29:
> warning: ‘USB0_BASE’ defined
On Mon, Nov 23, 2020 at 6:20 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> In file included from drivers/gpu/drm/amd/amdgpu/navi12_reg_init.c:27:
> drivers/gpu/drm/amd/amdgpu/../include/navi12_ip_offset.h:179:29: warning:
> ‘USB0_BASE’ defined but not used
On Tue, Nov 17, 2020 at 06:19:49PM -0500, Joel Fernandes (Google) wrote:
> Add a generic_idle_{enter,exit} helper function to enter and exit kernel
> protection when entering and exiting idle, respectively.
>
> While at it, remove a stale RCU comment.
>
> Reviewed-by: Alexandre Chartre
>
On Mon, Nov 23, 2020 at 6:20 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> In file included from drivers/gpu/drm/amd/amdgpu/navi14_reg_init.c:27:
> drivers/gpu/drm/amd/amdgpu/../include/navi14_ip_offset.h:179:29: warning:
> ‘USB0_BASE’ defined but not used
On Mon, Nov 23, 2020 at 6:20 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> In file included from drivers/gpu/drm/amd/amdgpu/arct_reg_init.c:27:
> drivers/gpu/drm/amd/amdgpu/../include/arct_ip_offset.h:227:29: warning:
> ‘DBGU_IO_BASE’ defined but not used
On Mon, Nov 23, 2020 at 6:20 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> In file included from drivers/gpu/drm/amd/amdgpu/navi10_reg_init.c:27:
> drivers/gpu/drm/amd/amdgpu/../include/navi10_ip_offset.h:127:29: warning:
> ‘UMC_BASE’ defined but not used
On Mon, Nov 23, 2020 at 6:20 AM Lee Jones wrote:
>
> In file included from drivers/gpu/drm/amd/amdgpu/vega20_reg_init.c:27:
> drivers/gpu/drm/amd/amdgpu/../include/vega20_ip_offset.h:154:29: warning:
> ‘XDMA_BASE’ defined but not used [-Wunused-const-variable=
> 154 | static const struct
The PID coefficients should be estimated again when there was a change to
sustainable power value made by user. This change removes unused argument
'force' and makes the function ready for such updates.
Signed-off-by: Lukasz Luba
---
drivers/thermal/gov_power_allocator.c | 28
The sustainable power value might come from the Device Tree or can be
estimated in run time. The sustainable power might be updated by the user
via sysfs interface, which should trigger new estimation of PID
coefficients. There is no need to estimate it every time when the
governor is called and
On Mon, Nov 23, 2020 at 6:20 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c:192: warning: Function parameter or
> member 'async' not described in 'dce_v6_0_page_flip'
> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c:1050: warning:
Dear,
How is everything with you today? I got your contact from a directory and
picked interest to communicate you by faith, though we have not met before, I
believe we can achieve something together. My husband died few years ago after
battling with brain cancer, before his death, he
Intelligent Power Allocation (IPA) is built around the PID controller
concept. The initialization code tries to setup the environment based on
the information available in DT or estimate the value based on minimum
power reported by each of the cooling device. The estimation will have an
impact on
is in an abstract
scale. Do the estimation of sustainable power only once and avoid expensive
calculation every time the IPA is called. Do the estimation of PID constants
when there was user update via sysfs to sustainable power.
The patch set should apply on top next-20201124
Changes:
v4:
- added new
On Tue, Nov 17, 2020 at 06:19:48PM -0500, Joel Fernandes (Google) wrote:
> Core-scheduling prevents hyperthreads in usermode from attacking each
> other, but it does not do anything about one of the hyperthreads
> entering the kernel for any reason. This leaves the door open for MDS
> and L1TF
On Mon, Nov 23, 2020 at 6:20 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c:91: warning: Function parameter or
> member 'job' not described in 'uvd_v3_1_ring_emit_ib'
> drivers/gpu/drm/amd/amdgpu/uvd_v3_1.c:91: warning:
On Fri, Nov 20, 2020 at 04:39:42PM -0500, Jes Sorensen wrote:
> On 11/20/20 1:38 PM, Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix
> > multiple warnings by replacing /* fall through */ comments with
> > the new pseudo-keyword macro fallthrough;
On Mon, Nov 23, 2020 at 6:19 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/si_dma.c:92: warning: Function parameter or
> member 'addr' not described in 'si_dma_ring_emit_fence'
> drivers/gpu/drm/amd/amdgpu/si_dma.c:92: warning: Function
On Mon, Nov 23, 2020 at 6:19 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:1903: warning: Function parameter or
> member 'timeout' not described in 'gfx_v6_0_ring_test_ib'
>
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc:
On Mon, Nov 23, 2020 at 6:20 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:1590: warning: Function parameter or
> member 'instance' not described in 'gfx_v7_0_select_se_sh'
> drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:1788:
On Mon, Nov 23, 2020 at 6:19 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/cik_sdma.c:226: warning: Function parameter or
> member 'job' not described in 'cik_sdma_ring_emit_ib'
> drivers/gpu/drm/amd/amdgpu/cik_sdma.c:226: warning:
On 11/24/2020 12:42 AM, Madhavan Srinivasan wrote:
On 11/24/20 10:21 AM, Namhyung Kim wrote:
Hello,
On Mon, Nov 23, 2020 at 8:00 PM Michael Ellerman
wrote:
Namhyung Kim writes:
Hi Peter and Kan,
(Adding PPC folks)
On Tue, Nov 17, 2020 at 2:01 PM Namhyung Kim
wrote:
Hello,
On
On Wed, 2020-11-11 at 17:32 +0100, Greg KH wrote:
> On Wed, Nov 11, 2020 at 04:03:30PM +, Limonciello, Mario wrote:
> > > > > Given we're effectively ending up with the combination of
> > > > > runtime PM turned
> > > > > on by udev rules, do we need something like this for that ID:
> > > > >
On Mon, Nov 23, 2020 at 6:19 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c:185: warning: Function parameter or
> member 'async' not described in 'dce_v8_0_page_flip'
>
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: David
On 11/24/20 2:41 AM, Zhen Lei wrote:
An appropriate return value should be set on the failed path.
Reported-by: Hulk Robot
Signed-off-by: Zhen Lei
LGTM.
Acked-by: Yonghong Song
Also this is a bug fix. It should probably be targeted to bpf tree. So,
Fixes: 4d374ba0bf30 ("tools:
From: Min Li
Feed kstrtou8 with NULL terminated string.
Changes since v1:
-Use sscanf to get rid of adhoc string parse.
Signed-off-by: Min Li
---
drivers/ptp/ptp_clockmatrix.c | 53 +++
1 file changed, 18 insertions(+), 35 deletions(-)
diff --git
On Mon, Nov 23, 2020 at 6:19 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c:157: warning: Function parameter or
> member 'handle' not described in 'uvd_v4_2_hw_init'
> drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c:157: warning: Excess
Hi Kalyan,
On Tue, 24 Nov 2020 at 18:27, wrote:
>
> On 2020-11-08 23:25, Amit Pundir wrote:
> > On Tue, 4 Aug 2020 at 21:09, Rob Clark wrote:
> >>
> >> On Thu, Jul 16, 2020 at 4:36 AM Kalyan Thota
> >> wrote:
> >> >
> >> > This change adds support to scale src clk and bandwidth as
> >> > per
From: Matthew Gerlach
In preparation of looking for dfls based on a vendor
specific pcie capability, move code that assumes
Bar0/offset0 as start of DFL to its own function.
Signed-off-by: Matthew Gerlach
---
v3: no change
v2: remove spurious blank lines
rename find_dfl_in_bar0 to
From: Matthew Gerlach
The start of a Device Feature List (DFL) is currently assumed to be at
Bar0/Offset 0 on the PCIe bus by drivers/fpga/dfl-pci.c. This patchset
adds support for the start one or more DFLs to be specified in a
Vendor-Specific Capability (VSEC) structure in PCIe config space.
From: Matthew Gerlach
A DFL may not begin at offset 0 of BAR 0. A PCIe vendor
specific capability can be used to specify the start of a
number of DFLs.
Signed-off-by: Matthew Gerlach
---
v3: Add text and ascii art to documentation.
Ensure not to exceed PCIe config space in loop.
v2:
On Tue, Nov 24, 2020 at 03:28:14PM +0100, Daniel Vetter wrote:
> On Fri, Nov 20, 2020 at 02:30:29PM -0400, Jason Gunthorpe wrote:
> > On Thu, Nov 19, 2020 at 03:41:46PM +0100, Daniel Vetter wrote:
> > > @@ -4805,21 +4824,15 @@ EXPORT_SYMBOL(follow_pte_pmd);
> > > * Return: zero and the pfn at
On Tue, 2020-11-24 at 14:37 +0200, Mathias Nyman wrote:
>
> I don't think we are ready to enable runtime pm as default for all
> Intel xHCI controllers.
> The risk of xHCI not waking up when user plugs a mouse/keyboard,
> making the system unusable
> just seems too high compared to the
On Mon, Nov 23, 2020 at 6:20 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:115: warning: Function parameter or
> member 'adev' not described in 'amdgpu_virt_request_full_gpu'
> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:115:
On Mon, Nov 23, 2020 at 6:19 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/radeon_device.c:637:6: warning: no previous prototype
> for ‘radeon_device_is_virtual’ [-Wmissing-prototypes]
>
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc:
The scheduler now knows enough about these braindead systems to place
32-bit tasks accordingly, so throw out the safety checks and allow the
ret-to-user path to avoid do_notify_resume() if there is nothing to do.
Signed-off-by: Will Deacon
---
arch/arm64/kernel/process.c | 14 +-
Provide an implementation of arch_task_cpu_possible_mask() so that we
can prevent 64-bit-only cores being added to the 'cpus_mask' for compat
tasks on systems with mismatched 32-bit support at EL0,
Signed-off-by: Will Deacon
---
arch/arm64/include/asm/mmu_context.h | 13 +
1 file
Reject explicit requests to change the affinity mask of a task via
set_cpus_allowed_ptr() if the requested mask is not a subset of the
mask returned by arch_task_cpu_possible_mask(). This ensures that the
'cpus_mask' for a given task cannot contain CPUs which are incapable of
executing it, except
If we want to support 32-bit applications, then when we identify a CPU
with mismatched 32-bit EL0 support we must ensure that we will always
have an active 32-bit CPU available to us from then on. This is important
for the scheduler, because is_cpu_allowed() will be constrained to 32-bit
CPUs for
On Mon, Nov 23, 2020 at 6:19 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/cik_ih.c:189: warning: Function parameter or
> member 'ih' not described in 'cik_ih_get_wptr'
> drivers/gpu/drm/amd/amdgpu/cik_ih.c:274: warning: Function
Asymmetric systems may not offer the same level of userspace ISA support
across all CPUs, meaning that some applications cannot be executed by
some CPUs. As a concrete example, upcoming arm64 big.LITTLE designs do
not feature support for 32-bit applications on both clusters.
On such a system, we
If the scheduler cannot find an allowed CPU for a task,
cpuset_cpus_allowed_fallback() will widen the affinity to cpu_possible_mask
if cgroup v1 is in use.
In preparation for allowing architectures to provide their own fallback
mask, just return early if we're not using cgroup v2 and allow
When exec'ing a 32-bit task on a system with mismatched support for
32-bit EL0, try to ensure that it starts life on a CPU that can actually
run it.
Signed-off-by: Will Deacon
---
arch/arm64/kernel/process.c | 42 -
1 file changed, 41 insertions(+), 1
Asymmetric systems may not offer the same level of userspace ISA support
across all CPUs, meaning that some applications cannot be executed by
some CPUs. As a concrete example, upcoming arm64 big.LITTLE designs do
not feature support for 32-bit applications on both clusters.
Although userspace
Since 32-bit applications will be killed if they are caught trying to
execute on a 64-bit-only CPU in a mismatched system, advertise the set
of 32-bit capable CPUs to userspace in sysfs.
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Will Deacon
---
.../ABI/testing/sysfs-devices-system-cpu
Scheduling a 32-bit application on a 64-bit-only CPU is a bad idea.
Ensure that 32-bit applications always take the slow-path when returning
to userspace on a system with mismatched support at EL0, so that we can
avoid trying to run on a 64-bit-only CPU and force a SIGKILL instead.
Allow systems with mismatched 32-bit support at EL0 to run 32-bit
applications based on a new kernel parameter.
Signed-off-by: Will Deacon
---
Documentation/admin-guide/kernel-parameters.txt | 7 +++
arch/arm64/kernel/cpufeature.c | 7 +++
2 files changed, 14
In preparation for late initialisation of the "sanitised" AArch32 register
state, move the AArch32 registers out of 'struct cpuinfo' and into their
own struct definition.
Signed-off-by: Will Deacon
---
arch/arm64/include/asm/cpu.h | 44 +++--
arch/arm64/kernel/cpufeature.c |
If a vCPU is caught running 32-bit code on a system with mismatched
support at EL0, then we should kill it.
Acked-by: Marc Zyngier
Signed-off-by: Will Deacon
---
arch/arm64/kvm/arm.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/arm.c
Hello folks,
Here's version four of the wonderful patches I previously posted here:
v1: https://lore.kernel.org/r/20201027215118.27003-1-w...@kernel.org
v2: https://lore.kernel.org/r/20201109213023.15092-1-w...@kernel.org
v3: https://lore.kernel.org/r/20201113093720.21106-1-w...@kernel.org
When confronted with a mixture of CPUs, some of which support 32-bit
applications and others which don't, we quite sensibly treat the system
as 64-bit only for userspace and prevent execve() of 32-bit binaries.
Unfortunately, some crazy folks have decided to build systems like this
with the
On Mon, Nov 23, 2020 at 6:19 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c:127: warning: Function parameter or
> member 'job' not described in 'amdgpu_ib_schedule'
>
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: David
On Tue, 24 Nov 2020 08:57:30 -0500
Philippe Duplessis-Guindon wrote:
> I have an error saying that `regcache_sync` has 2 fields named `type`
> while using libtraceevent.
>
> Erase the `int field` type, which is not assigned. This field is
> introduced by mistake and this commit removes it.
>
>
On Mon, Nov 23, 2020 at 6:19 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:1214: warning: Function parameter or
> member 'page_flags' not described in 'amdgpu_ttm_tt_create'
>
> Cc: Alex Deucher
> Cc: "Christian König"
>
On Tue, 24 Nov 2020, Colin King wrote:
> From: Colin Ian King
>
> The variable next_addr is not initialized and is being used in a call
> to i3c_master_get_free_addr as a starting point to find the next address.
> Fix this by initializing next_addr to 0 to avoid an uninitialized garbage
>
Dear Chen,
Thank you for the patch.
Am 24.11.20 um 16:32 schrieb Chen Yu:
The NIC is put in runtime suspend status when there is no wire connected.
As a result, it is safe to keep this NIC in runtime suspended during s2ram
because the system does not rely on the NIC plug event nor WOL to wake
On 11/20/20 11:01 AM, Catalin Marinas wrote:
Hi Khalid,
On Fri, Oct 23, 2020 at 11:56:11AM -0600, Khalid Aziz wrote:
diff --git a/arch/sparc/include/asm/mman.h b/arch/sparc/include/asm/mman.h
index f94532f25db1..274217e7ed70 100644
--- a/arch/sparc/include/asm/mman.h
+++
From: Russell King
> Sent: 24 November 2020 15:17
...
> That said, _if_ the PHY has a way to read the resolved state rather
> than reading the advertisement registers, that is what should be
> used (as I said previously) rather than trying to decode the
> advertisement registers ourselves. That is
On Mon, Nov 23, 2020 at 12:36:10PM +0800, Li, Aubrey wrote:
> >> +#ifdef CONFIG_SCHED_CORE
> >> + /*
> >> + * Skip this cpu if source task's cookie does not match
> >> + * with CPU's core cookie.
> >> + */
> >> + if
From: Arnd Bergmann
The -Wnested-externs warning has become useless with gcc, since
this warns every time that BUILD_BUG_ON() or similar macros
are used.
With clang, the warning option does nothing to start with, so
just remove it entirely.
Suggested-by: Nathan Chancellor
Signed-off-by: Arnd
Hi Prabhakar,
On Tue, Nov 24, 2020 at 12:27 PM Lad Prabhakar
wrote:
> Define rpcif_enable_rpm() and rpcif_disable_rpm() as static
> inline in the header instead of exporting it.
>
> Suggested-by: Pavel Machek
> Signed-off-by: Lad Prabhakar
Thanks for your patch, which is an improvement.
>
On Mon, Nov 23, 2020 at 12:18 PM Masahiro Yamada wrote:
>
> Applied to linux-kbuild. Thanks.
>
> But, I think people already tend to ignore W=2 warnings.
Yes, this is what I was trying to change with this series and a couple of other
patches I sent. When all the warnings from commonly included
701 - 800 of 1495 matches
Mail list logo
