It can either be called inline (locally or CPU hotplug locked) when
rdp->nocb_defer_wakeup is pending or from the nocb timer. In both cases
the rdp is offlined and we want to take the nocb lock.
Clarify the locking rules and expectations.
Signed-off-by: Frederic Weisbecker
Cc: Paul E. McKenney
Pure NOCB code entrypoints (nocb_cb kthread, nocb_gp kthread, nocb
timers) can unconditionally lock rdp->nocb_lock as they always execute
in the context of an offloaded rdp.
This also prepare for toggling CPUs to/from callback's offloaded mode
where the offloaded state will possibly change when
This is a necessary step toward making nohz_full controllable through
cpuset. Next step should be to allow a CPU to be nocb even if it wasn't
part of the nocb set on boot.
The core design of this set is mostly based on suggestions from Paul
of course.
On Mon, May 11, 2020 at 11:04:03PM +0100, Cristian Marussi wrote:
> Hi Dave
>
> thanks for the review first of all.
>
> On Wed, May 06, 2020 at 04:25:50PM +0100, Dave Martin wrote:
> > On Mon, May 04, 2020 at 05:38:47PM +0100, Cristian Marussi wrote:
> > > Add core SCMI Notifications
On 13. 05. 20 18:04, Jeffrey Hugo wrote:
> On Wed, May 13, 2020 at 9:53 AM wrote:
>> From: Michael Srba
>>
>> Attempting to enable these devices causes a "synchronous
>> external abort". Suspected cause is that the debug power
>> domain is not enabled by default on this device.
>> Disable these
' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Anmol/staging-android-ashmem-Fixed-a-issue-related-to-file_operations/20200513-194410
base: https://git.kernel.org/pub/scm/linux/kernel/git
Wojciech Kudla writes:
> On 13/05/2020 13:24, Thomas Gleixner wrote:
>
>> Why would the SMP call function single interrupt go through the
>> PLATFORM_IPI_VECTOR? It goes as the name says through the
>> CALL_FUNCTION_SINGLE_VECTOR.
>>
>
> Wrong vector, my bad.
>
> However 2) still stands in my
[add fsdevel to cc]
On Tue, May 12, 2020 at 08:22:08PM -0600, Jens Axboe wrote:
> On 5/12/20 8:14 PM, Xu, Yanfei wrote:
> > Hi,
> >
> > After operating the /dev/loop which losetup with an image placed in**tmpfs,
> >
> > I got the following ERROR messages:
> >
> > [cut
Hi Chun-Kuang,
Missatge de Enric Balletbo i Serra del
dia dv., 1 de maig 2020 a les 17:25:
>
> Use the drm_bridge_connector helper to create a connector for pipelines
> that use drm_bridge. This allows splitting connector operations across
> multiple bridges when necessary, instead of having the
On 12.05.20 11:41, Hui Zhu wrote:
This description needs an overhaul, it's hard to parse.
> If the guest kernel has many fragmentation pages, use virtio_balloon
> will split THP of QEMU when it calls MADV_DONTNEED madvise to release
> the balloon pages.
This is very unclear and confusing. You
Most modern broadcom PHYs support ECD (enhanced cable diagnostics). Add
support for it in the bcm-phy-lib so they can easily be used in the PHY
driver.
There are two access methods for ECD: legacy by expansion registers and
via the new RDB registers which are exclusive. Provide functions in two
Add the convenience function to do a read-modify-write. This has the
additional benefit of saving one write to the selection register.
Signed-off-by: Michael Walle
Reviewed-by: Florian Fainelli
Reviewed-by: Andrew Lunn
---
drivers/net/phy/bcm-phy-lib.c | 32
Use the generic cable tester functions from bcm-phy-lib to add cable
tester support.
100m cable, A/B/C/D open:
Cable test started for device eth0.
Cable test completed for device eth0.
Pair: Pair A, result: Open Circuit
Pair: Pair B, result: Open Circuit
Pair: Pair C, result: Open
Add cable tester support for the Broadcom PHYs. Support for it was
developed on a BCM54140 Quad PHY which RDB register access.
If there is a link partner the results are not as good as with an open
cable. I guess we could retry if the measurement until all pairs had at
least one valid result.
Add helper to read and write expansion registers without taking the mdio
lock.
Please note, that this changes the semantics of the read and write.
Before there was no lock between selecting the expansion register and
the actual read/write. This may lead to access failures if there are
parallel
On Wed, Mar 11, 2020 at 08:20:04PM +0900, David Stevens wrote:
> Add support for UUID-based resource sharing mechanism to virtgpu. This
> implements the new virtgpu commands and hooks them up to dma-buf's
> get_uuid callback.
>
> Signed-off-by: David Stevens
> ---
>
On Wed, May 13, 2020 at 4:52 AM Masahiro Yamada wrote:
>
> Nick,
>
> On Wed, May 13, 2020 at 4:23 AM Nick Desaulniers
> wrote:
> >
> > On Mon, May 11, 2020 at 10:54 PM Masahiro Yamada
> > wrote:
> > >
> > > > >On Mon, May 4, 2020 at 5:13 AM Nick Desaulniers
> > > > > wrote:
> > > > >>
> > > >
. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Rodrigo-Rolim-Mendes-de-Alencar/video-fbdev-ssd1307fb-Added-support-to-Column-offset/20200513-195401
base
David Laight writes:
> From: Will Deacon
>> Sent: 13 May 2020 13:40
>> On Wed, May 13, 2020 at 02:32:43PM +0200, Peter Zijlstra wrote:
>> > On Wed, May 13, 2020 at 01:48:41PM +0200, Marco Elver wrote:
>> >
>> > > Disabling most instrumentation for arch/x86 is reasonable. Also fine
>> > > with the
On 5/13/2020 9:27 AM, Greg Kroah-Hartman wrote:
> On Wed, May 13, 2020 at 08:08:07AM -0700, Florian Fainelli wrote:
>>
>>
>> On 5/13/2020 5:26 AM, Greg Kroah-Hartman wrote:
>>> On Tue, May 12, 2020 at 11:00:15AM -0400, Al Cooper wrote:
Some BRCMSTB USB chips have an XHCI, EHCI and OHCI
The workqueue code has it's internal spinlocks (pool::lock), which
are acquired on most workqueue operations. These spinlocks are
converted to 'sleeping' spinlocks on a RT-kernel.
Workqueue functions can be invoked from contexts which are truly atomic
even on a PREEMPT_RT enabled kernel. Taking
The workqueue code has it's internal spinlock (pool::lock) and also
implicit spinlock usage in the wq_manager waitqueue. These spinlocks
are converted to 'sleeping' spinlocks on a RT-kernel.
Workqueue functions can be invoked from contexts which are truly atomic
even on a PREEMPT_RT enabled
The workqueue code is currently not RT compatible due to nesting of
regular spinlocks inside of raw spinlocks and locking of spinlocks
inside of regions which are truly atomic even on a RT kernel.
One part of this problem are the wait queues as they use regular
spinlocks internally.
The
On Wed, May 13, 2020 at 08:08:07AM -0700, Florian Fainelli wrote:
>
>
> On 5/13/2020 5:26 AM, Greg Kroah-Hartman wrote:
> > On Tue, May 12, 2020 at 11:00:15AM -0400, Al Cooper wrote:
> >> Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
> >> on the same port where XHCI handles 3.0
On Wed, May 13, 2020 at 6:36 AM Arnaldo Carvalho de Melo
wrote:
>
> Em Tue, May 12, 2020 at 04:59:18PM -0700, Ian Rogers escreveu:
> > If allocated, perf_pkg_mask and metric_events need freeing.
>
> Applied, were those found with some tool? Or just by visual inspection?
>
> Also I noticed that
The series changes `wq_manager_wait' from waitqueues to simple
waitqueues and its internal locking (pool::lock and wq_mayday_lock) to
raw spinlocks so that workqueues can be used on PREEMPT_RT from truly
atomic context.
Sebastian
On Tue, May 12, 2020 at 06:04:50PM +0100, Julien Thierry wrote:
> Hi Matt,
>
> On 5/11/20 6:35 PM, Matt Helsley wrote:
> > Currently objtool only collects information about relocations with
> > addends. In recordmcount, which we are about to merge into objtool,
> > some supported architectures do
Am 2020-05-13 18:00, schrieb Oleksij Rempel:
On Wed, May 13, 2020 at 05:49:53PM +0200, Andrew Lunn wrote:
> Uff.. i missed this. Then I'll need only to add some changes on top of
> his patch.
I've been chatting with mwalle on IRC today. There should be a repost
of the patches soon.
Cool!
On Wed, May 13, 2020 at 03:13:28PM +0100, Richard Hughes wrote:
> On Wed, 13 May 2020 at 10:11, Mika Westerberg
> wrote:
> > > I can fix up all those, but out of interest how did you "know" the
> > > right three digit identifier to use?
> > I work for Intel ;-)
>
> Hah, okay, thanks :)
>
> > >
On Wed, May 13, 2020 at 04:16:22PM +, Luis Chamberlain wrote:
> On Wed, May 13, 2020 at 10:40:31AM -0500, Eric W. Biederman wrote:
> > Luis Chamberlain writes:
> >
> > > Certain symbols are not meant to be used by everybody, the security
> > > helpers for reading files directly is one such
On Wed, 13 May 2020 18:15:57 +0200
Sven Schnelle wrote:
> Thanks for looking into this. I've attached my /proc/config.gz to this Mail.
> The x86 system is my Laptop which is a Thinkpad X280 with 4 HT CPUs (so 8 cpus
> in total). I've tried disabling preemption, but this didn't help.
>
> It's
Hi Scott,
On Thu, 2020-05-07 at 17:27 -0700, Scott Branden wrote:
> Please consider this version series ready for upstream acceptance.
>
> This patch series adds partial read support in request_firmware_into_buf.
> In order to accept the enhanced API it has been requested that kernel
> selftests
On Wed, May 13, 2020 at 06:00:26PM +0200, Oleksij Rempel wrote:
> On Wed, May 13, 2020 at 05:49:53PM +0200, Andrew Lunn wrote:
> > > Uff.. i missed this. Then I'll need only to add some changes on top of
> > > his patch.
> >
> > I've been chatting with mwalle on IRC today. There should be a
* Faiz Abbas [200512 13:39]:
> Move mmc nodes to be compatible with the sdhci-omap driver. The following
> modifications are required for omap_hsmmc specific properties:
>
> ti,non-removable: convert to the generic mmc non-removable
> ti,needs-special-reset: co-opted into the sdhci-omap driver
Greg KH writes:
> On Sat, May 09, 2020 at 12:00:57PM +0200, Thomas Gleixner wrote:
>> Greg KH writes:
>> > On Sat, May 09, 2020 at 12:20:14AM -0700, syzbot wrote:
>> >> memtype_reserve failed: [mem 0xff000-0x8fff], req write-back
>> >> WARNING: CPU: 1 PID: 7025 at
Alan Stern writes:
> On Sat, 9 May 2020, Thomas Gleixner wrote:
>
>> Greg KH writes:
>> > On Sat, May 09, 2020 at 12:20:14AM -0700, syzbot wrote:
>> >> memtype_reserve failed: [mem 0xff000-0x8fff], req write-back
>> >> WARNING: CPU: 1 PID: 7025 at arch/x86/mm/pat/memtype.c:589
>> >>
Thank you, Mel!
I think I have to make sure we cover the scenario you have targeted
when developing adjust_numa_imbalance:
===
On 5/13/20 9:09 AM, Christoph Hellwig wrote:
> On Wed, May 13, 2020 at 08:41:57AM -0700, Eric Dumazet wrote:
>>> +* recv* side when msg_control_is_user is set, msg_control is the kernel
>>> +* buffer used for all other cases.
>>> +*/
>>> + union {
>>> + void
Balbir Singh writes:
This part:
> --- a/include/uapi/linux/prctl.h
> +++ b/include/uapi/linux/prctl.h
> @@ -238,4 +238,8 @@ struct prctl_mm_map {
> #define PR_SET_IO_FLUSHER57
> #define PR_GET_IO_FLUSHER58
>
> +/* Flush L1D on context switch (mm) */
> +#define
On Wed, May 13, 2020 at 10:40:31AM -0500, Eric W. Biederman wrote:
> Luis Chamberlain writes:
>
> > Certain symbols are not meant to be used by everybody, the security
> > helpers for reading files directly is one such case. Use a symbol
> > namespace for them.
> >
> > This will prevent abuse of
Hi Steve,
On Wed, May 13, 2020 at 09:29:22AM -0400, Steven Rostedt wrote:
> On Wed, 13 May 2020 11:19:06 +0200
> Sven Schnelle wrote:
>
> > Did you had a chance to look into this? I can easily reproduce this both on
> > x86
> > and s390 by doing:
> >
> > cd /sys/kernel/tracing
> > cat
the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Vinod-Koul/Add-LT9611-DSI-to-HDMI-bridge/20200513-181150
base: https://git.kernel.org/pub/scm
On Wed, 13 May 2020 09:28:07 -0500, Dan Murphy wrote:
> The device tree binding declares the ti,mic-bias-source and the
> ti,vref-source properties as u32. The code reads them as u8 which is
> incorrect. Since the device tree binding indicates them as u32 the
> conde needs to be updated to read
The AR8031/AR8033 and the AR8035 support cable diagnostics. Adding
driver support is straightforward, so lets add it.
The PHY just do one pair at a time, so we have to start the test four
times. The cable_test_get_status() can block and therefore we can just
busy poll the test completion and
On Wed, May 13, 2020 at 08:00:28AM -0700, Patrick Donnelly wrote:
> In newer kernels (at least 5.6), it appears root is not able to write
> to files owned by other users in a sticky directory:
Yes. Controlled by /proc/sys/fs/protected_regular, which systemd crowd
has decided to enable in commit
On Wed, May 13, 2020 at 8:26 AM John Garry wrote:
>
> On 13/05/2020 07:22, Ian Rogers wrote:
> > Break pmu-events test into 2 and add a test to verify that all pmu metric
> > expressions simply parse. Try to parse all metric ids/events, failing if
> > metrics for the current architecture fail to
On Wed, May 13, 2020 at 08:41:57AM -0700, Eric Dumazet wrote:
> > +* recv* side when msg_control_is_user is set, msg_control is the kernel
> > +* buffer used for all other cases.
> > +*/
> > + union {
> > + void*msg_control;
> > + void __user
On Wed, May 13, 2020 at 10:16:46AM +0200, Greg KH wrote:
> On Tue, May 12, 2020 at 10:07:24AM +0100, Sean Young wrote:
> > So this device is the infrared kind which rc-core (in drivers/media/rc/)
> > supports, remotes and such things (not for serial IR). So by using a
> > rc-core driver, it can
On Wed, May 13, 2020 at 10:40:31AM -0500, Eric W. Biederman wrote:
> Luis Chamberlain writes:
>
> > Certain symbols are not meant to be used by everybody, the security
> > helpers for reading files directly is one such case. Use a symbol
> > namespace for them.
> >
> > This will prevent abuse of
On Wed, May 13, 2020 at 03:21:08PM +, Luis Chamberlain wrote:
> Signed-off-by: Luis Chamberlain
I can't take patches without any changelog text at all, sorry.
greg k-h
From: Arnd Bergmann
> Sent: 13 May 2020 17:00
> On Wed, May 13, 2020 at 5:31 PM Kalle Valo wrote:
...
> I investigated a little more: This does happen with 'defconfig'
> after all, in my first try I must have missed the '-smp 2' argument
> to qemu, and it ended up working correctly with just one
On Wed, May 13, 2020 at 05:48:07PM +0200, Johan Hovold wrote:
> On Wed, May 13, 2020 at 05:39:18PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, May 13, 2020 at 05:03:43PM +0200, Johan Hovold wrote:
> > > On Thu, May 07, 2020 at 01:53:18PM -0500, Gustavo A. R. Silva wrote:
> > > > The current
On Wed, May 13, 2020 at 03:47:22PM +, Luis Chamberlain wrote:
> On Wed, May 13, 2020 at 11:00:26AM -0400, Rafael Aquini wrote:
> > Analogously to the introduction of panic_on_warn, this patch
> > introduces a kernel option named panic_on_taint in order to
> > provide a simple and generic way
On Wed, 2020-05-13 at 15:53 +, David Laight wrote:
> > If we don't have pselect() we use the close() in the signal
> > handler. In that case we're just waiting in the read(), we're not
> > using select() or poll() or whatever. It's definitely the case
> > that if we're waiting in read() and
Hi Lubomir,
On Wed, May 13, 2020 at 12:08 PM Lubomir Rintel wrote:
> /* Get Clocks: */
> - gpu->clk_reg = devm_clk_get(>dev, "reg");
> + gpu->clk_reg = devm_clk_get_optional(>dev, "reg");
> DBG("clk_reg: %p", gpu->clk_reg);
> if (IS_ERR(gpu->clk_reg))
> -
Hi Sandeep,
I would suggest to send v6 with the changes Rob and Stephen requested,
except for the 'assigned-clock-rate' constraints. A description instead
of the constraints is not ideal, but the constraints could be also be
added at a later time. Hopefully Rob can either ack with the description
On Wed, May 13, 2020 at 9:53 AM wrote:
>
> From: Michael Srba
>
> Attempting to enable these devices causes a "synchronous
> external abort". Suspected cause is that the debug power
> domain is not enabled by default on this device.
> Disable these devices for now to avoid the crash.
>
> See:
On Wed, 13 May 2020 at 21:16, Daniel Vetter wrote:
>
> On Wed, May 13, 2020 at 02:51:12PM +0200, Greg KH wrote:
> > On Wed, May 13, 2020 at 05:40:26PM +0530, Charan Teja Kalla wrote:
> > >
> > > Thank you Greg for the comments.
> > > On 5/12/2020 2:22 PM, Greg KH wrote:
> > > > On Fri, May 08,
Hi folks,
The vfs-for-next branch of the xfs-linux repository at:
git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git
has just been updated.
Patches often get missed, so please check if your outstanding patches
were in this update. If they have not been in this update, please
resubmit
"Gustavo A. R. Silva" wrote:
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced in C99:
>
> struct foo {
>
This file now also contains several helpers for accessing user memory.
Signed-off-by: Christoph Hellwig
---
mm/maccess.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/maccess.c b/mm/maccess.c
index 747581ac50dc9..65880ba2ca376 100644
--- a/mm/maccess.c
+++
This matches the naming of strnlen_user, and also makes it more clear
what the function is supposed to do.
Signed-off-by: Christoph Hellwig
---
include/linux/uaccess.h | 2 +-
kernel/trace/trace_kprobe.c | 2 +-
mm/maccess.c| 4 ++--
3 files changed, 4 insertions(+), 4
On Wed, 13 May 2020 at 17:51, Tao Zhou wrote:
>
> Hi Vincent,
>
> Sorry for the duplicate.
>
> On Wed, May 13, 2020 at 03:55:02PM +0200, Vincent Guittot wrote:
> > enqueue_task_fair jumps to enqueue_throttle label when cfs_rq_of(se) is
> > throttled which means that se can't be NULL in such case
maccess tends to define lots of underscore prefixed symbols that then
have other weak aliases. But except for two cases they are never
actually used, so remove them.
Signed-off-by: Christoph Hellwig
---
include/linux/uaccess.h | 3 ---
mm/maccess.c| 19 +++
2 files
Except for historical confusion in the kprobes/uprobes and bpf tracers
there is no good reason to ever allow user memory accesses from
probe_kernel_read. Make the tracers fall back to a probe_user_read
if the probe_kernel_read falls to keep the core API clean.
Signed-off-by: Christoph Hellwig
On Wed, May 13, 2020 at 04:52:16PM +0200, Jonas Falkevik wrote:
> Do not generate SCTP_ADDR_{MADE_PRIM,ADDED} events for SCTP_FUTURE_ASSOC
> assocs.
How did you get them?
I'm thinking you're fixing a side-effect of another issue here. For
example, in sctp_assoc_update(), it first calls
Move kernel access vs user access routines together to ease upcoming
ifdefs.
Signed-off-by: Christoph Hellwig
---
mm/maccess.c | 110 +--
1 file changed, 55 insertions(+), 55 deletions(-)
diff --git a/mm/maccess.c b/mm/maccess.c
index
Provide alternative versions of probe_kernel_read, probe_kernel_write
and strncpy_from_kernel_unsafe that don't need set_fs magic, but instead
use arch hooks that are modelled after unsafe_{get,put}_user to access
kernel memory in an exception safe way.
Signed-off-by: Christoph Hellwig
---
On Wed, May 13, 2020 at 8:21 AM Joerg Roedel wrote:
>
> Hi,
>
> here is the next post of this series with these changes to the first
> version:
>
> - Rebased to v5.7-rc5
>
> - As a result of the rebase, also removed the
> vmalloc_sync_mappings() call from tracing code
>
Better describe what this helper does, and match the naming of
copy_from_kernel_nofault.
Signed-off-by: Christoph Hellwig
---
arch/arm/kernel/traps.c | 2 +-
arch/arm/mm/alignment.c | 4 ++--
arch/arm64/kernel/traps.c | 2 +-
arch/ia64/include/asm/sections.h
Better describe what these functions do.
Suggested-by: Linus Torvalds
Signed-off-by: Christoph Hellwig
---
arch/powerpc/kernel/process.c | 3 ++-
arch/powerpc/kvm/book3s_64_mmu_radix.c | 4 ++--
arch/powerpc/mm/fault.c| 2 +-
arch/powerpc/oprofile/backtrace.c |
Better describe what these functions do.
Suggested-by: Linus Torvalds
Signed-off-by: Christoph Hellwig
---
arch/arm/kernel/ftrace.c | 3 +-
arch/arm/kernel/kgdb.c | 2 +-
arch/arm64/kernel/insn.c | 4 +--
arch/csky/kernel/ftrace.c | 5 ++--
Provide arch_kernel_read and arch_kernel_write routines to implement the
maccess routines without messing with set_fs and without stac/clac that
opens up access to user space.
Signed-off-by: Christoph Hellwig
---
arch/x86/include/asm/uaccess.h | 16
1 file changed, 16
All three callers really should try the explicit kernel and user
copies instead. One has already deprecated the somewhat dangerous
either kernel or user address concept, the other two still need to
follow up eventually.
Signed-off-by: Christoph Hellwig
Reviewed-by: Masami Hiramatsu
---
Currently architectures have to override every routine that probes
kernel memory, which includes a pure read and strcpy, both in strict
and not strict variants. Just provide a single arch hooks instead to
make sure all architectures cover all the cases.
Signed-off-by: Christoph Hellwig
---
Each of the helpers has just two callers, which also different in
dealing with kernel or userspace pointers. Just open code the logic
in the callers.
Signed-off-by: Christoph Hellwig
---
mm/maccess.c | 63
1 file changed, 29 insertions(+),
This matches the naming of strncpy_from_user_nofault, and also makes it
more clear what the function is supposed to do.
Signed-off-by: Christoph Hellwig
---
arch/x86/mm/maccess.c| 2 +-
include/linux/uaccess.h | 4 ++--
kernel/trace/bpf_trace.c | 2 +-
mm/maccess.c | 6 +++---
These two functions are not used by any modular code.
Signed-off-by: Christoph Hellwig
---
mm/maccess.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/mm/maccess.c b/mm/maccess.c
index 3ca8d97e50106..cf21e604f78cb 100644
--- a/mm/maccess.c
+++ b/mm/maccess.c
@@ -121,7 +121,6 @@ long
Add proper kerneldoc comments for probe_kernel_read_strict and
probe_kernel_read strncpy_from_unsafe_strict and explain the different
versus the non-strict version.
Signed-off-by: Christoph Hellwig
---
mm/maccess.c | 61
1 file changed, 43
This matches the naming of strncpy_from_user, and also makes it more
clear what the function is supposed to do.
Signed-off-by: Christoph Hellwig
---
include/linux/uaccess.h | 4 ++--
kernel/trace/bpf_trace.c| 2 +-
kernel/trace/trace_kprobe.c | 2 +-
mm/maccess.c| 4 ++--
Many of the maccess routines have a copy of the kerneldoc comment
in the header. Remove it as it is not useful and will get out of
sync sooner or later.
Signed-off-by: Christoph Hellwig
---
include/linux/uaccess.h | 38 --
1 file changed, 38 deletions(-)
On Wed, May 13, 2020 at 5:31 PM Kalle Valo wrote:
> Arnd Bergmann writes:
> > On Wed, May 13, 2020 at 2:57 PM Kalle Valo wrote:
> >>
> >> Arnd Bergmann writes:
> >>
> >> > If you share your .config, I can try reproducing with that as well.
> >> > Once there is a reproducer in qemu, it should
Hi all,
this series start cleaning up the safe kernel and user memory probing
helpers in mm/maccess.c, and then allows architectures to implement
the kernel probing without overriding the address space limit and
temporarily allowing access to user memory. It then switches x86
over to this new
On Wed, May 13, 2020 at 05:49:53PM +0200, Andrew Lunn wrote:
> > Uff.. i missed this. Then I'll need only to add some changes on top of
> > his patch.
>
> I've been chatting with mwalle on IRC today. There should be a repost
> of the patches soon.
Cool!
@Michael, please CC me.
you can include
On 5/13/20 10:35 AM, Paolo Bonzini wrote:
> On 13/05/20 01:58, Babu Moger wrote:
>> AMD's next generation of EPYC processors support the MPK (Memory
>> Protection Keys) feature.
>>
>> This series enables the feature on AMD and updates config parameters
>> and documentation to reflect the MPK
On Tue, May 12, 2020 at 06:04:56PM +0100, Julien Thierry wrote:
> Hi Matt,
>
> On 5/11/20 6:35 PM, Matt Helsley wrote:
> > objtool currently only compiles for x86 architectures. This is
> > fine as it presently does not support tooling for other
> > architectures. However, we would like to be
Hi Eric,
> -Original Message-
> From: Auger Eric [mailto:eric.au...@redhat.com]
> Sent: 13 May 2020 14:29
> To: Shameerali Kolothum Thodi ;
> Zhangfei Gao ; eric.auger@gmail.com;
> io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org;
> k...@vger.kernel.org;
On 5/13/20 10:09 AM, Dave Hansen wrote:
> On 5/12/20 4:58 PM, Babu Moger wrote:
>> +config X86_MEMORY_PROTECTION_KEYS
>> +# Both Intel and AMD platforms support "Memory Protection Keys"
>> +# feature. So add a generic option X86_MEMORY_PROTECTION_KEYS
>> +# and set the option
ChenTao wrote:
> Fix the following warning:
>
> drivers/net/wireless/realtek/rtl818x/rtl8187/rtl8225.c:609:17: warning:
> ‘rtl8225z2_tx_power_ofdm’ defined but not used
> static const u8 rtl8225z2_tx_power_ofdm[] = {
>
> Acked-by: Hin-Tak Leung
> Acked-by: Larry Finger
> Reported-by: Hulk
From: Paul Smith
> Sent: 13 May 2020 16:33
> On Wed, 2020-05-13 at 08:21 +, David Laight wrote:
...
> If we don't have pselect() we use the close() in the signal handler.
> In that case we're just waiting in the read(), we're not using select()
> or poll() or whatever. It's definitely the
The GENET controller on the Raspberry Pi 4 (2711) is typically
interfaced with an external Broadcom PHY via a RGMII electrical
interface. To make sure that delays are properly configured at the PHY
side, ensure that we the dedicated Broadcom PHY driver
(CONFIG_BROADCOM_PHY) is enabled for this to
From: Michael Srba
Attempting to enable these devices causes a "synchronous
external abort". Suspected cause is that the debug power
domain is not enabled by default on this device.
Disable these devices for now to avoid the crash.
See:
On Wed, May 13, 2020 at 5:42 PM Greg Kroah-Hartman
wrote:
>
> On Wed, May 13, 2020 at 06:18:40PM +0300, Heikki Krogerus wrote:
> > In the function kobject_cleanup(), kobject_del(kobj) is
> > called before the kobj->release(). That makes it possible to
> > release the parent of the kobject before
> Uff.. i missed this. Then I'll need only to add some changes on top of
> his patch.
I've been chatting with mwalle on IRC today. There should be a repost
of the patches soon.
Andrew
On Wed, May 13, 2020 at 09:50:03AM +0300, Kalle Valo wrote:
> (trimming CC, changing title)
>
> Kalle Valo writes:
>
> > Kalle Valo writes:
> >
> >> Arnd Bergmann writes:
> >>
> >>> gcc-10 correctly points out a bug with a zero-length array in
> >>> struct ath10k_pci:
> >>>
> >>>
On 2020/05/13 Sascha Hauer wrote:
> On Wed, May 13, 2020 at 08:52:39AM +, Robin Gong wrote:
> > On 2020/05/13 16:48 Sascha Hauer wrote:
> > > On Wed, May 13, 2020 at 08:38:26AM +, Robin Gong wrote:
> > > > On 2020/05/13 Sascha Hauer wrote:
> > > > > This patch is the one bisecting will
On Wed, May 13, 2020 at 05:39:18PM +0200, Greg Kroah-Hartman wrote:
> On Wed, May 13, 2020 at 05:03:43PM +0200, Johan Hovold wrote:
> > On Thu, May 07, 2020 at 01:53:18PM -0500, Gustavo A. R. Silva wrote:
> > > The current codebase makes use of the zero-length array language
> > > extension to the
On Wed, May 13, 2020 at 11:00:26AM -0400, Rafael Aquini wrote:
> Analogously to the introduction of panic_on_warn, this patch
> introduces a kernel option named panic_on_taint in order to
> provide a simple and generic way to stop execution and catch
> a coredump when the kernel gets tainted by
On Tue, May 05, 2020 at 06:13:13PM +0200, Nicolas Saenz Julienne wrote:
> On the Raspberry Pi 4, after a PCI reset, VL805's firmware may either be
> loaded directly from an EEPROM or, if not present, by the SoC's
> co-processor, VideoCore. This series adds support for the later.
>
> Note that
On Wed, May 13, 2020 at 02:51:12PM +0200, Greg KH wrote:
> On Wed, May 13, 2020 at 05:40:26PM +0530, Charan Teja Kalla wrote:
> >
> > Thank you Greg for the comments.
> > On 5/12/2020 2:22 PM, Greg KH wrote:
> > > On Fri, May 08, 2020 at 12:11:03PM +0530, Charan Teja Reddy wrote:
> > >> The
601 - 700 of 1758 matches
Mail list logo
