On Tue, Jul 14, 2020 at 07:57:51PM +, Winkler, Tomas wrote:
> >
> > On Tue, Jul 14, 2020 at 05:54:32PM +, Winkler, Tomas wrote:
> > > >
> > > > There is a regular need in the kernel to provide a way to declare
> > > > having a dynamically sized set of trailing elements in a structure.
> >
On Tue, Jul 14, 2020 at 09:53:19PM +0200, Sedat Dilek wrote:
>
> Hmm, you might be right with moving to LDFLAGS_vmlinux.
>
> Attached are my linux-config and dmesg-output.
>
> - Sedat -
Which tree are you building against? I notice you have KERNEL_ZSTD
enabled, which hasn't been merged yet.
Get from the DT the syncon to probe the state of the remote processor
and the location of the resource table.
Mainly based on the work published by Arnaud Pouliquen [1].
[1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=239877
Signed-off-by: Mathieu Poirier
Reviewed-by:
On Tue, Jul 14, 2020 at 09:02:53PM +0200, Sebastian Andrzej Siewior wrote:
> On 2020-07-14 11:27:32 [-0700], Paul E. McKenney wrote:
> > I believe that Ulad and Joel are working on an update.
>
> I expressed multiple times that I am unhappy with the raw_spinlock_t
> which both want to keep. It is
Request IRQ with platform device rather than remote proc in order to
call stm32_rproc_parse_dt() before rproc_alloc(). That way we can
know whether we need to synchronise with the MCU or not.
Signed-off-by: Mathieu Poirier
Reviewed-by: Loic Pallardy
Reviewed-by: Bjorn Andersson
---
Split function stm32_rproc_parse_fw() in two parts, the first one
to parse the memory regions and the second one to load the
resource table. That way parsing of the memory regions can be
done without having do deal with the resource table when attaching
to a remote processor.
Mainly based on the
Introduce new attach function to be used when attaching to a
remote processor.
Mainly based on the work published by Arnaud Pouliquen [1].
[1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=239877
Signed-off-by: Mathieu Poirier
---
drivers/remoteproc/stm32_rproc.c | 8
This set applies on top of [1] and refactors the STM32 platform code in
order to attach to the M4 remote processor when it has been started by the
boot loader.
New to V6:
1) Removed extra newline in patch 06.
2) Re-worked title and changelog of patch 08 to better reflect
what is done by the
Make function rproc_resource_cleanup() public so that it can be
used by platform drivers when allocating resources to be used by
a detached remote processor.
Signed-off-by: Mathieu Poirier
---
drivers/remoteproc/remoteproc_core.c | 3 ++-
include/linux/remoteproc.h | 1 +
2 files
Update the co-processor state in function stm32_rproc_stop() so that
it can be used in scenarios where the remoteproc core is attaching
to the M4.
Mainly based on the work published by Arnaud Pouliquen [1].
[1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=239877
Introduce the required mechanic to set the state of the M4 in order
to properly deal with scenarios where the co-processor has been
started by another entity.
Mainly based on the work published by Arnaud Pouliquen [1].
[1].
Properly set the remote processor's resource table based on where it was
loaded by the external entity when attaching to a remote processor.
Mainly based on the work published by Arnaud Pouliquen [1].
[1]. https://patchwork.kernel.org/project/linux-remoteproc/list/?series=239877
Signed-off-by:
Remove the remote processor from the process of parsing the memory
ranges since there is no correlation between them.
Signed-off-by: Mathieu Poirier
Reviewed-by: Loic Pallardy
Reviewed-by: Bjorn Andersson
---
drivers/remoteproc/stm32_rproc.c | 8
1 file changed, 4 insertions(+), 4
Remove the remote processor from the process of parsing the device tree
since (1) there is no correlation between them and (2) to use the
information that was gathered to make a decision on whether to
synchronise with the M4 or not.
Signed-off-by: Mathieu Poirier
Reviewed-by: Bjorn Andersson
Other than one has to be done after the other, there is no correlation
between memory translation and DT parsing. As such move function
stm32_rproc_of_memory_translations() to stm32_rproc_probe() so that
stm32_rproc_parse_dt() can be extended to look for attach bindings
in a clean way.
On Tue, Jul 14, 2020 at 12:42:11PM -0700, Dave Hansen wrote:
> On 7/14/20 12:29 PM, Peter Zijlstra wrote:
> > On Tue, Jul 14, 2020 at 12:06:16PM -0700, Ira Weiny wrote:
> >> On Tue, Jul 14, 2020 at 10:44:51AM +0200, Peter Zijlstra wrote:
> >>> So, if I followed along correctly, you're proposing to
>
> On Tue, Jul 14, 2020 at 05:54:32PM +, Winkler, Tomas wrote:
> > >
> > > There is a regular need in the kernel to provide a way to declare
> > > having a dynamically sized set of trailing elements in a structure.
> > > Kernel code should always use “flexible array members”[1] for these
> >
On 7/14/20 12:17 PM, Pawan Gupta wrote:
> On Tue, Jul 14, 2020 at 07:57:53AM -0700, Dave Hansen wrote:
>> Let's stick to things which are at least static per reboot. Checking
>> for X86_FEATURE_VMX or even CONFIG_KVM_INTEL seems like a good stopping
>> point. "Could this kernel run a naughty
On Tue, Jul 14, 2020 at 12:22:05PM -0700, Joe Perches wrote:
> On Wed, 2020-07-15 at 00:36 +0530, Suraj Upadhyay wrote:
> > On Tue, Jul 14, 2020 at 11:57:23AM -0700, Joe Perches wrote:
> > > On Mon, 2020-07-13 at 17:17 +0300, Dan Carpenter wrote:
> > > > On Mon, Jul 13, 2020 at 05:52:22PM +0530,
Add a new function to assert the general health of the remote
processor before handing it to the remoteproc core.
Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud Pouliquen
Tested-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 41
1 file
Introduce function rproc_actuate() that provides the same
functionatlity as rproc_fw_boot(), but without the steps that
involve interaction with the firmware image. That way we can
deal with scenarios where the remoteproc core is attaching
to a remote processor that has already been started by
When function rproc_free_vring() clears the virtio device section
it does so on the cached resource table rather than the one
installed in the remote processor memory. When a remote processor
has been booted by another entity there is no need to use a cached
table and as such, no need to clear
Add a new RPROC_DETACHED state to take into account scenarios
where the remoteproc core needs to attach to a remote processor
that is booted by another entity.
Signed-off-by: Mathieu Poirier
Reviewed-by: Bjorn Andersson
Tested-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_sysfs.c | 1
Add an new attach() operation in order to properly deal with
scenarios where the remoteproc core needs to attach to a
remote processor that has been booted by another entity.
Signed-off-by: Mathieu Poirier
Reviewed-by: Bjorn Andersson
Tested-by: Arnaud Pouliquen
---
This set provides functionality allowing the remoteproc core to attach to
a remote processor that was started by another entity.
New in V6:
1) Added Arnaud's reviewed-by and tested-by tags.
Applies cleanly on rproc-next (0cf17702d872)
Thanks,
Mathieu
Mathieu Poirier (9):
remoteproc: Add new
Introducing function rproc_attach() to enact the same actions as
rproc_start(), but without the steps related to the handling of
a firmware image. That way we can properly deal with scenarios
where the remoteproc core needs to attach with a remote processsor
that has been booted by another
Refactor function rproc_trigger_auto_boot() to properly deal
with scenarios where the remoteproc core needs to attach with a
remote processor that has already been booted by an external
entity.
Signed-off-by: Mathieu Poirier
Reviewed-by: Bjorn Andersson
Tested-by: Arnaud Pouliquen
---
This patch prevents the firmware image name from being displayed when
the remoteproc core is attaching to a remote processor. This is needed
needed since there is no guarantee about the nature of the firmware
image that is loaded by the external entity.
Signed-off-by: Mathieu Poirier
Refactor function rproc_boot() to properly deal with scenarios
where the remoteproc core needs to attach with a remote
processor that has already been booted by an external entity.
Signed-off-by: Mathieu Poirier
Reviewed-by: Bjorn Andersson
Tested-by: Arnaud Pouliquen
---
On Tue, Jul 14, 2020 at 7:46 PM Nick Desaulniers
wrote:
>
> On Tue, Jul 14, 2020 at 4:11 AM Sedat Dilek wrote:
> >
> > When using Clang's Integrated Assembler (LLVM_IAS=1) we fell over
> > ClangBuiltLinux (CBL) issue #1043 where Jian Cai provided a patch.
> >
> > With Jian's patch applied
On Tue, Jul 14, 2020 at 12:42:11PM -0700, Dave Hansen wrote:
> On 7/14/20 12:29 PM, Peter Zijlstra wrote:
> > On Tue, Jul 14, 2020 at 12:06:16PM -0700, Ira Weiny wrote:
> >> On Tue, Jul 14, 2020 at 10:44:51AM +0200, Peter Zijlstra wrote:
> >>> So, if I followed along correctly, you're proposing to
Hi Steve,
On Tue, 2020-07-14 at 15:43 -0400, Steven Rostedt wrote:
> On Tue, 14 Jul 2020 20:35:12 +0200
> Pavel Machek wrote:
>
> > Hi!
> >
> > >
> > > I'm pleased to announce the 4.19.132-rt59 stable release.
> > >
> > > This release is just an update to the new stable 4.19.132
> > >
When assembling with Clang via `make LLVM_IAS=1` and CONFIG_HYPERV enabled,
we observe the following error:
:9:6: error: expected absolute expression
.if HYPERVISOR_REENLIGHTENMENT_VECTOR == 3
^
:1:1: note: while in macro instantiation
idtentry HYPERVISOR_REENLIGHTENMENT_VECTOR
On Tue, Jul 14, 2020 at 09:27:18AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:25051b55 udc: lpc32xx: make symbol 'lpc32xx_usbddata' static
> git tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
> console
On Tue, 14 Jul 2020 20:35:12 +0200
Pavel Machek wrote:
> Hi!
>
> >
> > I'm pleased to announce the 4.19.132-rt59 stable release.
> >
> > This release is just an update to the new stable 4.19.132
> > version and no RT specific changes have been made.
> >
> > You can get this release via the
Replace memsets of 1 byte with simple assignment.
Issue found with checkpatch.pl
Signed-off-by: Suraj Upadhyay
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
On Thu, Jul 09, 2020 at 05:05:09PM -0500, Eric W. Biederman wrote:
>
> I have merged all of this into my exec-next tree.
>
> The code is also available on the frozen branch:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
> usermode-driver-cleanup
>
>
Replace memsets of 1 byte with simple assignments.
Issue found with checkpatch.pl
Signed-off-by: Suraj Upadhyay
---
drivers/net/ethernet/intel/e1000e/ethtool.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/ethtool.c
On 7/14/20 12:29 PM, Peter Zijlstra wrote:
> On Tue, Jul 14, 2020 at 12:06:16PM -0700, Ira Weiny wrote:
>> On Tue, Jul 14, 2020 at 10:44:51AM +0200, Peter Zijlstra wrote:
>>> So, if I followed along correctly, you're proposing to do a WRMSR per
>>> k{,un}map{_atomic}(), sounds like excellent
Replace memsets of 1 byte with simple assignment.
Issue found with checkpatch.pl
Signed-off-by: Suraj Upadhyay
---
drivers/net/ethernet/intel/igb/igb_ethtool.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c
On Tue, Jul 14, 2020 at 07:30:38PM +0200, Geert Uytterhoeven wrote:
> On Tue, Jul 14, 2020 at 3:40 PM Jonathan Corbet wrote:
> > On Tue, 14 Jul 2020 09:22:39 +0200
> > Geert Uytterhoeven wrote:
> > > > > - website http://openrisc.io
> > > > > + website https://openrisc.io
Hi,
With the Linux Kernel version 5.8-rc5/master I am unable to mount some
squashfs filesystems compressed with "-comp lz4".
If I try to mount them I get the following error:
[1.084246] SQUASHFS error: lz4 decompression failed, data probably corrupt
[1.084545] SQUASHFS error: Failed to
On Wed, Jul 1, 2020 at 10:50 AM Masahiro Yamada wrote:
>
> On Thu, Jul 2, 2020 at 2:46 AM Alexei Starovoitov
> wrote:
> >
> > On Wed, Jul 01, 2020 at 06:26:44PM +0900, Masahiro Yamada wrote:
> > > Originally, bpfilter_umh was linked with -static only when
> > > CONFIG_BPFILTER_UMH=y.
> > >
> > >
Replace memsets of 1 byte with simple assignments.
Issue reported by checkpatch.pl.
Signed-off-by: Suraj Upadhyay
---
drivers/net/ethernet/intel/e1000/e1000_ethtool.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_ethtool.c
On Tue, Jul 14, 2020 at 12:10:47PM -0700, Ira Weiny wrote:
> On Tue, Jul 14, 2020 at 10:40:57AM +0200, Peter Zijlstra wrote:
> > That's an anti-pattern vs static_keys, I'm thinking you actually want
> > static_key_slow_{inc,dec}() instead of {enable,disable}().
>
> Thanks. I'll go read the doc
Rationale:
A completely white page with an empty .
Signed-off-by: Alexander A. Klimov
---
Yes, I noted that some of the links removed by these "CREDITS: remove link:"
patches have email addresses with the same domain nearby.
Don't worry, I'll take care of them together with all other
dead
The pull request you sent on Mon, 13 Jul 2020 17:53:32 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e9919e11e219eaa5e8041b7b1a196839143e9125
Thank you!
--
Deet-doot-dot, I am a bot.
On 7/14/20 10:47 AM, Maciej S. Szmigiero wrote:
> On 14.07.2020 19:14, Guenter Roeck wrote:
>> On 7/14/20 7:11 AM, Maciej S. Szmigiero wrote:
>>> On 14.07.2020 16:02, Guenter Roeck wrote:
On 7/11/20 1:41 PM, Maciej S. Szmigiero wrote:
> It has been observed that Toshiba DT01ACA family
Rationale:
A completely white page with just an in the .
Signed-off-by: Alexander A. Klimov
---
Yes, I noted that some of the links removed by these "CREDITS: remove link:"
patches have email addresses with the same domain nearby.
Don't worry, I'll take care of them together with all other
Rationale:
The way it redirects looks like a fallback from a dead URL to a generic one.
Signed-off-by: Alexander A. Klimov
---
Yes, I noted that some of the links removed by these "CREDITS: remove link:"
patches have email addresses with the same domain nearby.
Don't worry, I'll take care of
Rationale:
The way it redirects looks like a fallback from a dead URL to a generic one.
Signed-off-by: Alexander A. Klimov
---
Yes, I noted that some of the links removed by these "CREDITS: remove link:"
patches have email addresses with the same domain nearby.
Don't worry, I'll take care of
On Tue, 14 Jul 2020 20:31:43 +0200
Peter Zijlstra wrote:
> On Tue, Jul 14, 2020 at 12:07:01PM -0400, Steven Rostedt wrote:
> > Can we add a statement that says something like: "Because x86 now calls
> > static_call_init() before the setup of the memory allocator, we must
> > avoid using
On Tue, Jul 14, 2020 at 12:06 PM Christoph Hellwig wrote:
>
> this series starts to move the early init code away from requiring
> KERNEL_DS to be implicitly set during early startup. It does so by
> first removing legacy unused cruft, and the switches away the code
> from struct file based APIs
On 07/14, Daniel Vetter wrote:
> On Tue, Jul 14, 2020 at 07:39:42AM -0300, Melissa Wen wrote:
> > On Tue, Jul 14, 2020 at 7:20 AM Melissa Wen wrote:
> > >
> > > On 07/13, Daniel Vetter wrote:
> > > > On Fri, Jul 10, 2020 at 02:05:33PM -0300, Melissa Wen wrote:
> > > > > On 07/02, Daniel Vetter
Hi Pavel,
On Tue, 2020-07-14 at 20:35 +0200, Pavel Machek wrote:
> Hi!
>
> >
> > I'm pleased to announce the 4.19.132-rt59 stable release.
> >
> > This release is just an update to the new stable 4.19.132
> > version and no RT specific changes have been made.
> >
> > You can get this release
On Tue, Jul 14, 2020 at 12:09 PM Christoph Hellwig wrote:
>
> There is no good reason to mess with file descriptors from in-kernel
> code, switch the initramfs unpacking to struct file based write
> instead.
Looking at this diff, I realized this really should be cleaned up more.
+
On Tue, Jul 14, 2020 at 08:30:14PM +0200, Sedat Dilek wrote:
> > I did a full new build...
> >
> > ...and it fails with ld.lld-11 as linker:
> >
> > ld.lld-11 -m elf_x86_64 -pie --no-dynamic-linker -r -o
> > arch/x86/boot/compressed/.tmp_misc.o arch/x86/boot/compressed/misc.o
> > -T
On Tue, Jul 14, 2020 at 12:06:16PM -0700, Ira Weiny wrote:
> On Tue, Jul 14, 2020 at 10:44:51AM +0200, Peter Zijlstra wrote:
> > So, if I followed along correctly, you're proposing to do a WRMSR per
> > k{,un}map{_atomic}(), sounds like excellent performance all-round :-(
>
> Only to pages which
Hi,
On 7/14/20 5:32 PM, Pierre-Louis Bossart wrote:
On 7/14/20 8:33 AM, Hans de Goede wrote:
Hi,
On 7/14/20 10:09 AM, Jing Xiangfeng wrote:
snd_byt_cht_es8316_mc_probe() misses to call put_device() in an error
path. Add the missed function call to fix it.
Fixes: ba49cf6f8e4a ("ASoC:
On Tue, Jul 14, 2020 at 10:54:15AM +0200, Frieder Schrempf wrote:
> It would still be quite nice to benefit from the flexibility of DT overlays
> not only for the SPI use case. But before I come up with any custom
> solution, for now I will rather have the device in the DT statically.
> I just
On Tue, Jul 14, 2020 at 10:03 AM Brian Gerst wrote:>
> On Tue, Jul 14, 2020 at 2:40 AM Christoph Hellwig wrote:
> >
> > On Tue, Jun 16, 2020 at 10:23:13AM -0400, Brian Gerst wrote:
> > > Christoph Hellwig uncovered an issue with how we currently handle X32
> > > syscalls. Currently, we can only
On Tue, Jul 14, 2020 at 07:57:53AM -0700, Dave Hansen wrote:
> Let's stick to things which are at least static per reboot. Checking
> for X86_FEATURE_VMX or even CONFIG_KVM_INTEL seems like a good stopping
> point. "Could this kernel run a naughty guest?" If so, report
> "Vulnerable". It's the
On Wed, 2020-07-15 at 00:36 +0530, Suraj Upadhyay wrote:
> On Tue, Jul 14, 2020 at 11:57:23AM -0700, Joe Perches wrote:
> > On Mon, 2020-07-13 at 17:17 +0300, Dan Carpenter wrote:
> > > On Mon, Jul 13, 2020 at 05:52:22PM +0530, Suraj Upadhyay wrote:
> > > > Use direct assignment instead of using
From: Colin Ian King
It is possible for the call to omap_iommu_dump_ctx to return
a negative error number, so check for the failure and return
the error number rather than pass the negative value to
simple_read_from_buffer.
Addresses-Coverity: ("Improper use of negative value")
Fixes:
On Tue, Jul 14, 2020 at 8:33 PM Sedat Dilek wrote:
>
> On Tue, Jul 14, 2020 at 8:30 PM Sedat Dilek wrote:
> >
> > > I did a full new build...
> > >
> > > ...and it fails with ld.lld-11 as linker:
> > >
> > > ld.lld-11 -m elf_x86_64 -pie --no-dynamic-linker -r -o
> > >
On Mon, Jul 13, 2020 at 06:34:12AM +, tudor.amba...@microchip.com wrote:
> These four patches are looking good, I had just few minor comments.
> If you too think that they are ok, would you take them through the
> SPI tree? If so, I would need an immutable tag on top of v5.8-rc1
> preferably,
On Tue, Jul 14, 2020 at 9:04 AM Chris Down wrote:
> Either way, again, this isn't really the point. :-) The point is that there
> _are_ currently widespread cases involving poking MSRs from userspace, however
> sacrilegious or ugly (which I agree with!), and while people should be told
> about
On Tue, 14 Jul 2020 18:51:15 + Westergreen, Dalon wrote:
> > I've seen vendors abuse fields of ethtool --coalesce to configure
> > similar settings. tx-usecs-irq and rx-usecs-irq, I think. Since this
> > part of ethtool API has been ported to netlink, could we perhaps add
> > a new field to
The initial code that was adding delays was doing a cast over undefined
memory. This meant that the delays would be all gibberish.
This change, allocates all delays on the stack, and assigns them from the
ZynqMP & Versal macros/phase-list. And then finally copies them over the
common iclk_phase &
From: Tony Lindgren
[ Upstream commit 0df12a01f4857495816b05f048c4c31439446e35 ]
We can currently sometimes get "RXS timed out" errors and "EOT timed out"
errors with spi transfers.
These errors can be made easy to reproduce by reading the cpcap iio
values in a loop while keeping the CPUs busy
From: Chengguang Xu
[ Upstream commit 0b8eb629a700c0ef15a437758db8255f8444e76c ]
Release bip using kfree() in error path when that was allocated
by kmalloc().
Signed-off-by: Chengguang Xu
Reviewed-by: Christoph Hellwig
Acked-by: Martin K. Petersen
Signed-off-by: Jens Axboe
Signed-off-by:
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
This is the start of the stable review cycle for the 4.19.133 release.
There are 58 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Thu, 16 Jul 2020 18:40:38 +.
Anything
From: Will Deacon
commit 68cf617309b5f6f3a651165f49f20af1494753ae upstream.
PAGE_HYP_DEVICE is intended to encode attribute bits for an EL2 stage-1
pte mapping a device. Unfortunately, it includes PROT_DEVICE_nGnRE which
encodes attributes for EL1 stage-1 mappings such as UXN and nG, which are
From: Ido Schimmel
[ Upstream commit d9d5420273997664a1c09151ca86ac993f2f89c1 ]
We should not trigger a warning when a memory allocation fails. Remove
the WARN_ON().
The warning is constantly triggered by syzkaller when it is injecting
faults:
[ 2230.758664] FAULT_INJECTION: forcing a
From: Hector Martin
commit e337bf19f6af38d5c3fa6d06cd594e0f890ca1ac upstream.
These devices claim to be 96kHz mono, but actually are 48kHz stereo with
swapped channels and unaligned transfers.
Cc: sta...@vger.kernel.org
Signed-off-by: Hector Martin
Link:
From: Christian Borntraeger
[ Upstream commit 774911290c589e98e3638e73b24b0a4d4530e97c ]
The current number of KVM_IRQCHIP_NUM_PINS results in an order 3
allocation (32kb) for each guest start/restart. This can result in OOM
killer activity even with free swap when the memory is fragmented
From: Dan Carpenter
commit 8ff41cc21714704ef0158a546c3c4d07fae2c952 upstream.
This code assumes that the user passed in enough data for a
qrtr_hdr_v1 or qrtr_hdr_v2 struct, but it's not necessarily true. If
the buffer is too small then it will read beyond the end.
Reported-by: Manivannan
From: Stephane Eranian
[ Upstream commit 16accae3d97f97d7f61c4ee5d0002bccdef59088 ]
This patch fixes a bug introduced by:
fd3ae1e1587d6 ("perf/x86/rapl: Move RAPL support to common x86 code")
The Kconfig variable name was wrong. It was missing the CONFIG_ prefix.
Signed-off-by: Stephane
From: Janosch Frank
commit 528a9539348a0234375dfaa1ca5dbbb2f8f8e8d2 upstream.
If the pmd is soft dirty we must mark the pte as soft dirty (and not dirty).
This fixes some cases for guest migration with huge page backings.
Cc: # 4.8
Fixes: bc29b7ac1d9f ("s390/mm: clean up pte/pmd encoding")
From: Kees Cook
commit b25a7c5af9051850d4f3d93ca500056ab6ec724b upstream.
The printing of section addresses in /sys/module/*/sections/* was not
using the correct credentials to evaluate visibility.
Before:
# cat /sys/module/*/sections/.*text
0xc0458000
...
# capsh
From: Li Heng
[ Upstream commit 8a259e6b73ad8181b0b2ef338b35043433db1075 ]
t4_prep_fw goto bye tag with positive return value when something
bad happened and which can not free resource in adap_init0.
so fix it to return negative value.
Fixes: 16e47624e76b ("cxgb4: Add new scheme to update
From: Xiyu Yang
[ Upstream commit 11425c4519e2c974a100fc984867046d905b9380 ]
ttm_bo_add_move_fence() invokes dma_fence_get(), which returns a
reference of the specified dma_fence object to "fence" with increased
refcnt.
When ttm_bo_add_move_fence() returns, local variable "fence" becomes
From: Kees Cook
commit ed66f991bb19d94cae5d38f77de81f96aac7813f upstream.
In order to gain access to the open file's f_cred for kallsym visibility
permission checks, refactor the module section attributes to use the
bin_attribute instead of attribute interface. Additionally removes the
From: Wei Li
[ Upstream commit 8523c006264df65aac7d77284cc69aac46a6f842 ]
After entering kdb due to breakpoint, when we execute 'ss' or 'go' (will
delay installing breakpoints, do single-step first), it won't work
correctly, and it will enter kdb due to oops.
It's because the reason gotten in
From: Mikulas Patocka
commit 6958c1c640af8c3f40fa8a2eee3b5b905d95b677 upstream.
kobject_uevent may allocate memory and it may be called while there are dm
devices suspended. The allocation may recurse into a suspended device,
causing a deadlock. We must set the noio flag when sending a uevent.
From: Vasily Gorbik
[ Upstream commit 998f5bbe3dbdab81c1cfb1aef7c3892f5d24f6c7 ]
Currently if early_pgm_check_handler is called it ends up in pgm check
loop. The problem is that early_pgm_check_handler is instrumented by
KASAN but executed without DAT flag enabled which leads to addressing
Move the loop over the possible arrays into the caller to remove a level
of indentation for the whole function.
Signed-off-by: Christoph Hellwig
Acked-by: Song Liu
---
drivers/md/md-autodetect.c | 203 ++---
1 file changed, 101 insertions(+), 102 deletions(-)
devfs is long gone, and autoscan works just fine without this these days.
Signed-off-by: Christoph Hellwig
Acked-by: Song Liu
---
drivers/md/md-autodetect.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/md/md-autodetect.c b/drivers/md/md-autodetect.c
index
On Tue, Jul 14, 2020 at 10:40:57AM +0200, Peter Zijlstra wrote:
> On Tue, Jul 14, 2020 at 12:02:16AM -0700, ira.we...@intel.com wrote:
>
> > +static pgprot_t dev_protection_enable_get(struct dev_pagemap *pgmap,
> > pgprot_t prot)
> > +{
> > + if (pgmap->flags & PGMAP_PROT_ENABLED &&
Just like the NFS and CIFS root code this better lives with the
driver it is tightly integrated with.
Signed-off-by: Christoph Hellwig
Acked-by: Song Liu
---
drivers/md/Makefile | 3 +++
init/do_mounts_md.c => drivers/md/md-autodetect.c | 15 +--
From: Maxime Ripard
[ Upstream commit 842ec61f4006a6477a9deaedd69131e9f46e4cb5 ]
The main DRM device is actually a virtual device so it doesn't have the
iommus property, which is instead on the DMA masters, in this case the
mixers.
Add a call to of_dma_configure with the mixers DT node but on
There is no good reason to mess with file descriptors from in-kernel
code, switch the initrd loading to struct file based read and writes
instead.
Signed-off-by: Christoph Hellwig
---
fs/read_write.c | 2 +-
include/linux/syscalls.h | 1 -
init/do_mounts_rd.c | 82
There is no good reason to mess with file descriptors from in-kernel
code, switch the initramfs unpacking to struct file based write
instead.
Signed-off-by: Christoph Hellwig
---
init/initramfs.c | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
If initrd support is not enable just print the warning directly instead
of hiding the fact that we just failed behind two stub functions.
Signed-off-by: Christoph Hellwig
---
init/initramfs.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/init/initramfs.c
md_setup_drive knows it works with md devices, so it is rather pointless
to open a file descriptor and issue ioctls. Just call directly into the
relevant low-level md routines after getting a handle to the device using
blkdev_get_by_dev instead.
Signed-off-by: Christoph Hellwig
Acked-by: Song
Remove the special handling for multiple floppies in the initrd code.
No one should be using floppies for booting these days. (famous last
words..)
Signed-off-by: Christoph Hellwig
---
arch/arm/kernel/atags_parse.c | 2 -
arch/sh/kernel/setup.c| 2 -
arch/sparc/kernel/setup_32.c | 2
Add a helper for struct file based chown operations. To be used by
the initramfs code soon.
Signed-off-by: Christoph Hellwig
---
fs/open.c | 29 +
include/linux/fs.h | 2 ++
2 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/fs/open.c
BLKFLSBUF used to be overloaded for the ramdisk driver to free the whole
ramdisk, which was completely different behavior compared to all other
drivers. But this magic overload got removed in commit ff26956875c2
("brd: remove support for BLKFLSBUF"), so this call is entirely
pointless now.
Don't rely on the implicit set_fs(KERNEL_DS) for ksys_open to work, but
instead open a struct file for /dev/console and then install it as FD
0/1/2 manually.
Signed-off-by: Christoph Hellwig
---
init/main.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git
401 - 500 of 1986 matches
Mail list logo
