On Fri, Jul 19, 2019 at 01:40:13PM -0400, Andy Lutomirski wrote:
> > On Jul 19, 2019, at 1:03 PM, Sean Christopherson
> > wrote:
> >
> > The generic vDSO implementation, starting with commit
> >
> > 7ac870747988 ("x86/vdso: Switch to generic vDSO implementation")
> >
> > breaks seccomp-enabl
On Mon, Jul 22, 2019 at 5:23 PM Alexander Potapenko wrote:
> On Mon, Jul 22, 2019 at 4:26 PM Arnd Bergmann wrote:
> > On Mon, Jul 22, 2019 at 3:43 PM Alexander Potapenko
> > wrote:
> > > On Mon, Jul 22, 2019 at 1:41 PM Arnd Bergmann wrote:
> > Doesn't that just limit the usefulness of KASAN, a
On Wed, Jul 10, 2019 at 09:55:12AM -0600, Rob Herring wrote:
> On Wed, Jul 3, 2019 at 5:23 PM Matthias Kaehlcke wrote:
> >
> > Hi Florian,
> >
> > On Wed, Jul 03, 2019 at 02:37:47PM -0700, Florian Fainelli wrote:
> > > On 7/3/19 12:37 PM, Matthias Kaehlcke wrote:
> > > > The LED behavior of some R
In addition, it seems that svm_page_enc_status_hc() accepts 'gpa',
'npages', 'enc' directly from the guest, and so these can take
arbitrary values. A very large 'npages' could lead to an int overflow
in 'gfn_end = gfn_start + npages', making gfn_end < gfn_start. This
could an OOB access in the bitm
On Mon, 2019-07-22 at 10:36 -0600, stillcompil...@gmail.com wrote:
> From: Joshua Clayton
>
> Make available printk_once variants to hid_warn() etc
>
> Signed-off-by: Joshua Clayton
This seems OK, but I suggest a slightly different style:
> diff --git a/include/linux/hid.h b/include/linux/hid
On Sat, 13 Jul 2019 11:46:31 +0800, Icenowy Zheng wrote:
> Allwinner V3 has the same main die with V3s, but with more pins wired.
> There's a I2S bus on V3 that is not available on V3s.
>
> Add the V3-only peripheral's clocks and reset to the V3s CCU driver,
> bound to a new V3 compatible string.
Hi,
On 2019-07-05 18:09, Colin Ian King wrote:
> Static analysis on today's linux-next has found a potential error in the
> following commit:
>
> commit 280e54c9f614c88292685383cf2d65057586e9fb
> Author: Andrzej Pietrasiewicz
> Date: Thu Jun 7 13:06:08 2018 +0200
>
> drm/exynos: scaler: Re
wakeup_abort_count and wakeup_count sysfs entries print the
same (wakeup_count) attribute. This patch removes the duplicate
wakeup_abort_count sysfs entry.
Signed-off-by: Ravi Chandra Sadineni
---
Documentation/ABI/testing/sysfs-devices-power | 25 ++-
drivers/base/power/sysfs.c
On Wed, Jul 17, 2019 at 05:18:52PM +0800, YueHaibing wrote:
> Fix sparse warnings:
>
> lib/zstd/compress.c:2252:6: warning:
> symbol 'ZSTD_compressBlock_greedy_extDict' was not declared. Should it be
> static?
> lib/zstd/compress.c:2982:14: warning:
> symbol 'ZSTD_createCStream_advanced' was no
DT nodes should be ordered by address, then node name, and finally label.
The msm8998 dtsi does not follow this, so clean it up by reordering the
nodes. While we are at it, extend the addresses to be fully 32-bits wide
so that ordering is easy to determine when adding new nodes. Also, two
or so n
only got a partial panic, but when I threw 5.3-rc1 on a linode vm,
it hit this:
bus_add_driver+0x1a9/0x1c0
? scsi_init_sysctl+0x22/0x22
driver_register+0x6b/0xa6
? scsi_init_sysctl+0x22/0x22
init+0x86/0xcc
do_one_initcall+0x69/0x334
kernel_init_freeable+0x367/0x3ff
? rest_init+0x247/0x247
The pull request you sent on Sun, 21 Jul 2019 21:13:21 -0700 (PDT):
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git refs/heads/master
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/83768245a3b158b96d33012b22ab01d193afb2da
Thank you!
--
Deet-doot-dot, I
The pull request you sent on Mon, 22 Jul 2019 18:23:38 +0200 (CEST):
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> sched-urgent-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7b5cf701ea9c395c792e2a7e3b7caf4c68b87721
Thank you!
--
Deet-doot
The pull request you sent on Mon, 22 Jul 2019 16:22:41 +0200:
> g...@gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux
> tags/for-linus-20190722
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/44b912cd0b5596c5ae8ae857bd1d5ff83ed5
Thank you!
--
The pull request you sent on Mon, 22 Jul 2019 08:58:06 -0300:
> git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
> tags/media/v5.3-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c92f0380673bd295c9ac73030a17c16b9df3e702
Thank you!
--
Deet-doot-dot
On Mon, Jul 22, 2019 at 09:27:08AM -0700, Linus Torvalds wrote:
> On Mon, Jul 22, 2019 at 7:26 AM Christian Brauner
> wrote:
> >
> > This contains a fix for pidfd polling. It ensures that the task's exit
> > state is visible to all waiters:
>
> Hmm.
>
> I've pulled this, but the exit_state thin
On Mon, Jul 22, 2019 at 07:35:03AM -0700, Mark Balantzyan wrote:
> Hello all,
>
> I had previously submitted 2 patches attempting to fix the data race
> condition in alim1535_wdt.c as part of my work with individuals on the
> Linux Driver Verification project. I am including the original patch
> d
From: Joshua Clayton
Make available printk_once variants to hid_warn() etc
Signed-off-by: Joshua Clayton
---
include/linux/hid.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/include/linux/hid.h b/include/linux/hid.h
index d770ab1a0479..5b239712c902 100644
--- a/incl
From: Joshua Clayton
On HP spectre x360 convertible the message:
hid-sensor-hub 001F:8087:0AC2.0002: hid_field_extract() called with n (192) >
32! (kworker/1:2)
is continually printed many times per second, crowding out all other kernel logs
Protect dmesg by printing the warning only one time.
On Mon, Jul 22, 2019 at 09:25:51AM -0700, Paul E. McKenney wrote:
> On Mon, Jul 22, 2019 at 12:13:40PM -0400, Michael S. Tsirkin wrote:
> > On Mon, Jul 22, 2019 at 08:55:34AM -0700, Paul E. McKenney wrote:
> > > On Mon, Jul 22, 2019 at 11:47:24AM -0400, Michael S. Tsirkin wrote:
> > > > On Mon, Jul
On Mon, Jul 22, 2019 at 03:47:44PM +0300, Alexandru Ardelean wrote:
> Some devices like the ADIS16460 IMU require a longer period between
> transfers, i.e. between when the CS is de-asserted and re-asserted. The
> default value of 10us is not enough. This change makes the delay
> configurable for w
On Mon, Jul 22, 2019 at 7:26 AM Christian Brauner wrote:
>
> This contains a fix for pidfd polling. It ensures that the task's exit
> state is visible to all waiters:
Hmm.
I've pulled this, but the exit_state thing has been very fragile
before, and I'm not entirely happy with how this just chang
Static analysis identified that index comparison against ITS entries in
iort_dev_find_its_id() is off by one.
Update the comparison condition and clarify the resulting error
message.
Fixes: 4bf2efd26d76 ("ACPI: Add new IORT functions to support MSI domain
handling")
Link: https://lore.kernel.org
On Mon, Jul 22, 2019 at 12:13:40PM -0400, Michael S. Tsirkin wrote:
> On Mon, Jul 22, 2019 at 08:55:34AM -0700, Paul E. McKenney wrote:
> > On Mon, Jul 22, 2019 at 11:47:24AM -0400, Michael S. Tsirkin wrote:
> > > On Mon, Jul 22, 2019 at 11:14:39AM -0400, Joel Fernandes wrote:
> > > > [snip]
> > >
This is really helpful and thank you for taking the initiative! I've
no real feedback other than to offer support.
We've been looking in this direction to avoid memory overhead in:
https://github.com/google/perf_data_converter
Some use cases:
1) streaming protobuf rather than perf.data files,
2) us
Linus,
please pull the latest sched-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-urgent-for-linus
up to: b8d3349803ba: sched/rt, Kconfig: Unbreak def/oldconfig with
CONFIG_PREEMPT=y
The PREEMPT_RT stub config renamed PREEMPT to PREEMPT_LL
On 7/22/19 3:57 AM, Dmitry Osipenko wrote:
22.07.2019 13:13, Marc Zyngier пишет:
On 22/07/2019 10:54, Dmitry Osipenko wrote:
21.07.2019 22:40, Sowjanya Komatineni пишет:
Tegra210 platforms use sc7 entry firmware to program Tegra LP0/SC7 entry
sequence and sc7 entry firmware is run from COP/B
On Fri, Jul 19 2019 at 12:20 -0600, Stephen Boyd wrote:
Quoting Lina Iyer (2019-07-01 08:29:06)
From: "Raju P.L.S.S.S.N"
tcs->lock was introduced to serialize access with in TCS group. But
even without tcs->lock, drv->lock is serving the same purpose. So
use a single drv->lock.
Isn't the dow
On Mon, Jul 22, 2019 at 01:04:48PM -0300, Jason Gunthorpe wrote:
> On Mon, Jul 22, 2019 at 08:52:35AM -0700, Paul E. McKenney wrote:
> > So why then is there a problem?
>
> I'm not sure there is a real problem, I thought Michael was just
> asking how to design with RCU in the case where the user c
On Mon, Jul 22, 2019 at 01:04:48PM -0300, Jason Gunthorpe wrote:
> On Mon, Jul 22, 2019 at 08:52:35AM -0700, Paul E. McKenney wrote:
> > So why then is there a problem?
>
> I'm not sure there is a real problem, I thought Michael was just
> asking how to design with RCU in the case where the user c
While loading fw crashdump in function fw_crash_buffer_show(),
left bytes in one dma chunk was not checked, if copying size
over it, overflow access will cause kernel panic.
Signed-off-by: Junxiao Bi
---
drivers/scsi/megaraid/megaraid_sas_base.c | 3 +++
1 file changed, 3 insertions(+)
diff --g
Commit 36a2ba07757d ("ACPI/IORT: Reject platform device creation on NUMA
node mapping failure") introduced a local variable 'node' in
arm_smmu_v3_set_proximity() that shadows the struct acpi_iort_node
pointer function parameter.
Execution was unaffected but it is prone to errors and can lead
to su
On Mon, Jul 22, 2019 at 08:55:34AM -0700, Paul E. McKenney wrote:
> On Mon, Jul 22, 2019 at 11:47:24AM -0400, Michael S. Tsirkin wrote:
> > On Mon, Jul 22, 2019 at 11:14:39AM -0400, Joel Fernandes wrote:
> > > [snip]
> > > > > Would it make sense to have call_rcu() check to see if there are many
>
+++ Martin Kaiser [22/07/19 12:13 +0200]:
Dear all,
I run next-20190722 on an arm imx25 system and came across an issue that might
be worth reporting. I am no sure to whom, though. Please let me know if I got
that wrong.
Loading a module, no matter which one, causes a segfault and a dump such
+++ Bartosz Golaszewski [22/07/19 14:12 +0200]:
Hi,
with v5.3-rc1 I'm hitting the following BUG() when trying to load the
gpio-backlight module:
kernel BUG at kernel/module.c:1919!
Internal error: Oops - BUG: 0 [#1] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 1 Comm: systemd Tainted: GW
On 22/07/2019 16:34, Thomas Gleixner wrote:
John,
Hi Thomas,
On Mon, 22 Jul 2019, John Garry wrote:
On 22/07/2019 15:41, Marc Zyngier wrote:
On 22/07/2019 15:14, John Garry wrote:
I have a question on commit cbf866a6 ("genirq: Let irq thread follow
the effective hard irq affinity"), i
On Mon, Jul 22, 2019 at 08:52:35AM -0700, Paul E. McKenney wrote:
> So why then is there a problem?
I'm not sure there is a real problem, I thought Michael was just
asking how to design with RCU in the case where the user controls the
kfree_rcu??
Sounds like the answer is "don't worry about it" ?
Dear Eric,
Sorry for the late reply.
On 5/29/19 6:00 PM, Eric Dumazet wrote:
> On Wed, May 29, 2019 at 7:49 AM Paul Menzel wrote:
>> On 05/28/19 19:18, Eric Dumazet wrote:
>>> On 5/28/19 8:42 AM, Paul Menzel wrote:
>>
Occasionally, Linux outputs the message below on the workstation Dell
On Mon, Jul 22, 2019 at 11:00:10AM -0400, Steven Rostedt wrote:
> On Mon, 22 Jul 2019 13:42:02 +0100
> Catalin Marinas wrote:
>
> > > I agree with Masami, that the selftest actually caught a bug here. I
> > > think the arch code may need to change as the purpose of Masami's
> > > changes was to e
On Mon, Jul 22, 2019 at 11:47:24AM -0400, Michael S. Tsirkin wrote:
> On Mon, Jul 22, 2019 at 11:14:39AM -0400, Joel Fernandes wrote:
> > [snip]
> > > > Would it make sense to have call_rcu() check to see if there are many
> > > > outstanding requests on this CPU and if so process them before
> >
On Mon, Jul 22, 2019 at 09:39:24AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Sun, Jul 21, 2019 at 01:24:10PM +0200, Jiri Olsa escreveu:
> > Adding empty libperf.a under toos/perf/lib and
> > linking it with perf.
>
> So, I noticed you created a subdirectory under tools/perf/, while I
> first tho
On Mon, Jul 22, 2019 at 10:41:52AM -0300, Jason Gunthorpe wrote:
> On Mon, Jul 22, 2019 at 04:51:49AM -0700, Paul E. McKenney wrote:
>
> > > > > Would it make sense to have call_rcu() check to see if there are many
> > > > > outstanding requests on this CPU and if so process them before
> > > > >
Need to ensure that kref_put does not run concurrently with the loop
inside rxe_pool_get_key.
Signed-off-by: Maksym Planeta
---
drivers/infiniband/sw/rxe/rxe_pool.c | 18 ++
drivers/infiniband/sw/rxe/rxe_pool.h | 4 +---
2 files changed, 19 insertions(+), 3 deletions(-)
diff --
Used in a later patch.
Signed-off-by: Maksym Planeta
---
drivers/infiniband/sw/rxe/rxe_pool.c | 3 ++-
drivers/infiniband/sw/rxe/rxe_pool.h | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/sw/rxe/rxe_pool.c
b/drivers/infiniband/sw/rxe/rxe_pool.c
index 30
Make rxe_run_task only schedule tasks and never run them directly.
This simplification will be used in further patches.
Signed-off-by: Maksym Planeta
---
drivers/infiniband/sw/rxe/rxe_comp.c | 16
drivers/infiniband/sw/rxe/rxe_loc.h | 2 +-
drivers/infiniband/sw/rxe/rxe_net
Pointer to PD is not used in rxe_ah anymore.
Signed-off-by: Maksym Planeta
---
drivers/infiniband/sw/rxe/rxe_verbs.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.h
b/drivers/infiniband/sw/rxe/rxe_verbs.h
index 5c4b2239129c..8dd65c2a7c72 100644
--- a/dri
Used in a later patch.
Signed-off-by: Maksym Planeta
---
drivers/infiniband/sw/rxe/rxe_loc.h | 1 +
drivers/infiniband/sw/rxe/rxe_qp.c | 17 +
drivers/infiniband/sw/rxe/rxe_req.c | 1 +
drivers/infiniband/sw/rxe/rxe_resp.c | 25 ++---
4 files changed, 17
This patchset helps to get rid of following race condition situations:
1. Tasklet functions were incrementing reference counting after entering
running the tasklet.
2. Getting a pointer to reference counted object (kref) was
After putting all tasks to schedule, this counter does not have a
meaning anymore.
Signed-off-by: Maksym Planeta
---
drivers/infiniband/sw/rxe/rxe_comp.c| 6 --
drivers/infiniband/sw/rxe/rxe_hw_counters.c | 1 -
drivers/infiniband/sw/rxe/rxe_hw_counters.h | 1 -
3 files changed, 8 de
Replace tasklets with workqueues in rxe driver.
Ensure that task is called only through a workqueue. This allows to
simplify task logic.
Add additional dependencies to make sure that cleanup tasks do not
happen after object's memory is already reclaimed.
Improve overal stability of the driver by
Reference should be aquired *before* the tasklet is run. The best time
to increment the reference counter is at initialisation. Otherwise, the
object may not exists anymore by the time tasklet is run.
Signed-off-by: Maksym Planeta
---
drivers/infiniband/sw/rxe/rxe_comp.c | 4
drivers/infini
Replace void* with rxe_pool_entry* for some functions.
Change macro to inline function.
Signed-off-by: Maksym Planeta
---
drivers/infiniband/sw/rxe/rxe_comp.c | 18
drivers/infiniband/sw/rxe/rxe_mcast.c | 20
drivers/infiniband/sw/rxe/rxe_mr.c| 8 ++--
drivers/infiniband
Specific implementations must finish off the cleanup of pool elements
when it is the right moment. Reason for that is that a concreate cleanup
function may want postpone and schedule part of object destruction to
later time.
Signed-off-by: Maksym Planeta
---
drivers/infiniband/sw/rxe/rxe_cq.c
On Fri, Jul 19 2019 at 12:22 -0600, Stephen Boyd wrote:
Quoting Lina Iyer (2019-07-01 08:29:07)
When triggering a TCS to send its contents, reading back the trigger
value may return an incorrect value. That is because, writing the
trigger may raise an interrupt which could be handled immediately
On Mon, Jul 22, 2019 at 11:14:39AM -0400, Joel Fernandes wrote:
> [snip]
> > > Would it make sense to have call_rcu() check to see if there are many
> > > outstanding requests on this CPU and if so process them before returning?
> > > That would ensure that frequent callers usually ended up doing t
This enables the Enhanced Quadrature Encoder Pulse (eQEP) module for
connectors E1, E2 and E3 on BeagleBone Blue.
Signed-off-by: David Lechner
---
arch/arm/boot/dts/am335x-boneblue.dts | 54 +++
1 file changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneb
This documents device tree binding for the Texas Instruments Enhanced
Quadrature Encoder Pulse (eQEP) Module found in various TI SoCs.
Signed-off-by: David Lechner
---
.../devicetree/bindings/counter/ti-eqep.txt| 18 ++
1 file changed, 18 insertions(+)
create mode 100644 Doc
This adds a new counter driver for the Texas Instruments Enhanced
Quadrature Encoder Pulse (eQEP) module.
Only very basic functionality is currently implemented - only enough to
be able to read the position. The actual device has many more features
which can be added to the driver on an as-needed
This adds new nodes for the Texas Instruments Enhanced Quadrature
Encoder Pulse (eQEP) module in the PWM subsystem on AM33XX.
Signed-off-by: David Lechner
---
arch/arm/boot/dts/am33xx-l4.dtsi | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/boot/dts/am33x
This series adds device tree bindings and a new counter driver for the Texas
Instruments Enhanced Quadrature Encoder Pulse (eQEP).
As mentioned in one of the commit messages, to start with, the driver only
supports reading the current counter value and setting the min/max values.
Other features ca
Now walk_page_range() can walk kernel page tables, we can switch the
arm64 ptdump code over to using it, simplifying the code.
Signed-off-by: Steven Price
---
arch/arm64/Kconfig | 1 +
arch/arm64/Kconfig.debug | 19 +
arch/arm64/include/asm/ptdump.h| 8 +-
To enable x86 to use the generic walk_page_range() function, the
callers of ptdump_walk_pgd_level_debugfs() need to pass in the mm_struct.
This means that ptdump_walk_pgd_level_core() is now always passed a
valid pgd, so drop the support for pgd==NULL.
Signed-off-by: Steven Price
---
arch/x86/i
Add a generic version of page table dumping that architectures can
opt-in to
Signed-off-by: Steven Price
---
include/linux/ptdump.h | 19 +
mm/Kconfig.debug | 21 ++
mm/Makefile| 1 +
mm/ptdump.c| 161 +
4 files ch
To enable x86 to use the generic walk_page_range() function, the
callers of ptdump_walk_pgd_level() need to pass an mm_struct rather
than the raw pgd_t pointer. Luckily since commit 7e904a91bf60
("efi: Use efi_mm in x86 as well as ARM") we now have an mm_struct
for EFI on x86.
Signed-off-by: Steve
An mm_struct is needed to enable x86 to use of the generic
walk_page_range() function.
In the case of walking the user page tables (when
CONFIG_PAGE_TABLE_ISOLATION is enabled), it is necessary to create a
fake_mm structure because there isn't an mm_struct with a pointer
to the pgd of the user pag
Make use of the new functionality in walk_page_range to remove the
arch page walking code and use the generic code to walk the page tables.
The effective permissions are passed down the chain using new fields
in struct pg_state.
The KASAN optimisation is implemented by including test_p?d callback
Since 48684a65b4e3: "mm: pagewalk: fix misbehavior of walk_page_range
for vma(VM_PFNMAP)", page_table_walk() will report any kernel area as
a hole, because it lacks a vma.
This means each arch has re-implemented page table walking when needed,
for example in the per-arch ptdump walker.
Remove the
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_leaf() functions/macros.
For sparc 64 bit, pmd_large() and pud_large() are already p
pgd_entry() and pud_entry() were removed by commit 0b1fbfe50006c410
("mm/pagewalk: remove pgd_entry() and pud_entry()") because there were
no users. We're about to add users so reintroduce them, along with
p4d_entry() as we now have 5 levels of tables.
Note that commit a00cc7d9dd93d66a ("mm, x86:
For the /sys/kernel/debug/page_tables/ files, rather than outputing a
mostly empty line when a block of memory isn't present just skip the
line. This keeps the output shorter and will help with a future change
switching to using the generic page walk code as we no longer care about
the 'level' that
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_leaf() functions/macros.
For s390, pud_large() and pmd_large() are already implement
mm/dump_pagetables.c passes both struct seq_file and struct pg_state
down the chain of walk_*_level() functions to be passed to note_page().
Instead place the struct seq_file in struct pg_state and access it from
struct pg_state (which is private to this file) in note_page().
Signed-off-by: Steven
It is useful to be able to skip parts of the page table tree even when
walking without VMAs. Add test_p?d callbacks similar to test_walk but
which are called just before a table at that level is walked. If the
callback returns non-zero then the entire table is skipped.
Signed-off-by: Steven Price
Exposing the pud/pgd levels of the page tables to walk_page_range() means
we may come across the exotic large mappings that come with large areas
of contiguous memory (such as the kernel's linear map).
For architectures that don't provide all p?d_leaf() macros, provide
generic do nothing default t
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_leaf() functions/macros.
For x86 we already have p?d_large() functions, so simply ad
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_leaf() functions/macros.
For mips, we only support large pages on 64 bit.
For 64 bi
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information will be provided by the
p?d_leaf() functions/macros.
For arc, we only have two levels, so only pmd_leaf() i
This is a slight reworking and extension of my previous patch set
(Convert x86 & arm64 to use generic page walk), but I've continued the
version numbering as most of the changes are the same. In particular
this series ends with a generic PTDUMP implemention for arm64 and x86.
Many architectures cu
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_leaf() functions/macros.
For powerpc pmd_large() already exists and does what we wan
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_leaf() functions/macros.
For riscv a page is a leaf page when it has a read, write o
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information will be provided by the
p?d_leaf() functions/macros.
For arm64, we already have p?d_sect() macros which we
walk_page_range() is going to be allowed to walk page tables other than
those of user space. For this it needs to know when it has reached a
'leaf' entry in the page tables. This information is provided by the
p?d_leaf() functions/macros.
For arm pmd_large() already exists and does what we want. S
e it is.
>
> - sed@ -
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/log/?h=objtool-many-fixes-v2
next-20190722 has them.
Parallely, I opened an CBL issue #617
"drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool:
.altinstr_replacement+0x86: redundan
On Mon, 2019-07-22 at 08:54 +, Gustavo Pimentel wrote:
>
> >
> > > > +static inline void al_pcie_target_bus_set(struct al_pcie
> > > > *pcie,
> > > > + u8 target_bus,
> > > > + u8 mask_target_bus)
> > > > +{
> > >
The generic ARM CPUidle driver includes by mistake.
Remove the topology header include.
Signed-off-by: Lorenzo Pieralisi
Cc: Ulf Hansson
Cc: Sudeep Holla
Cc: Daniel Lezcano
Cc: "Rafael J. Wysocki"
---
drivers/cpuidle/cpuidle-arm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/
The PSCI checker currently relies on the generic ARM CPUidle
infrastructure to enter an idle state, which in turn creates
a dependency that is not really needed.
The PSCI checker code to test PSCI CPU suspend is built on
top of the CPUidle framework and can easily reuse the
struct cpuidle_state.en
CPUidle back-end operations are not implemented in some platforms
but this should not be considered an error serious enough to be
logged. Check the arm_cpuidle_init() return value to detect whether
the failure must be reported or not in the kernel log and do
not log it if the platform does not supp
Current PSCI code handles idle state entry through the
psci_cpu_suspend_enter() API, that takes an idle state index as a
parameter and convert the index into a previously initialized
power_state parameter before calling the PSCI.CPU_SUSPEND() with it.
This is unwieldly, since it forces the PSCI fi
Current PSCI CPUidle driver is built on top of the generic ARM
CPUidle infrastructure that relies on the architectural back-end
idle operations to initialize and enter idle states.
On ARM64 systems, PSCI is the only interface the kernel ever uses
to enter idle states, so, having to rely on a gener
Allow selection of the PSCI CPUidle in the kernel by adding
the required Kconfig options.
Remove PSCI callbacks from ARM/ARM64 generic CPU ops
to prevent the PSCI idle driver from clashing with the generic
ARM CPUidle driver initialization, that relies on CPU ops
to initialize and enter idle state
PSCI firmware is the standard power management control for
all ARM64 based platforms and it is also deployed on some
ARM 32 bit platforms to date.
Idle state entry in PSCI is currently achieved by calling
arm_cpuidle_init() and arm_cpuidle_suspend() in a generic
idle driver, which in turn relies o
John,
On Mon, 22 Jul 2019, John Garry wrote:
> On 22/07/2019 15:41, Marc Zyngier wrote:
> > On 22/07/2019 15:14, John Garry wrote:
> > > I have a question on commit cbf866a6 ("genirq: Let irq thread follow
> > > the effective hard irq affinity"), if you could kindly check:
> > >
> > > Here we
On Mon, Jul 22, 2019 at 05:14:26PM +0200, Maksym Planeta wrote:
> Replace tasklets with workqueues in rxe driver.
>
> Ensure that task is called only through a workqueue. This allows to
> simplify task logic.
>
> Add additional dependencies to make sure that cleanup tasks do not
> happen after ob
In a later patch I need to know if the dependency to QP object still
exists or not.
On 22/07/2019 17:29, Jason Gunthorpe wrote:
On Mon, Jul 22, 2019 at 05:14:23PM +0200, Maksym Planeta wrote:
Used in a later patch.
Signed-off-by: Maksym Planeta
drivers/infiniband/sw/rxe/rxe_pool.c | 3 ++-
On Mon, Jul 22, 2019 at 05:14:23PM +0200, Maksym Planeta wrote:
> Used in a later patch.
>
> Signed-off-by: Maksym Planeta
> drivers/infiniband/sw/rxe/rxe_pool.c | 3 ++-
> drivers/infiniband/sw/rxe/rxe_pool.h | 2 +-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i
On 7/22/19 8:39 AM, Arnd Bergmann wrote:
On Sun, Jul 21, 2019 at 4:25 PM Masahiro Yamada
wrote:
struct snd_sof_blk_hdr {
enum snd_sof_fw_blk_type type;
- uint32_t size; /* bytes minus this header */
- uint32_t offset;/* offset from base */
+ __u
On 22/07/2019 17:25, Jason Gunthorpe wrote:
On Mon, Jul 22, 2019 at 05:14:20PM +0200, Maksym Planeta wrote:
Need to ensure that kref_put does not run concurrently with the loop
inside rxe_pool_get_key.
Signed-off-by: Maksym Planeta
drivers/infiniband/sw/rxe/rxe_pool.c | 18 +++
On Mon, Jul 22, 2019 at 05:14:21PM +0200, Maksym Planeta wrote:
>
> int rxe_init_task(void *obj, struct rxe_task *task,
> - void *arg, int (*func)(void *), char *name)
> + struct rxe_qp *qp, int (*func)(void *), char *name)
> {
> task->obj = obj;
> -
On Mon, Jul 22, 2019 at 05:14:20PM +0200, Maksym Planeta wrote:
> Need to ensure that kref_put does not run concurrently with the loop
> inside rxe_pool_get_key.
>
> Signed-off-by: Maksym Planeta
> drivers/infiniband/sw/rxe/rxe_pool.c | 18 ++
> drivers/infiniband/sw/rxe/rxe_pool.
On 22-07-19, 16:44, Arnd Bergmann wrote:
> On Mon, Jul 22, 2019 at 4:36 PM Vinod Koul wrote:
> > On 22-07-19, 16:22, Arnd Bergmann wrote:
> > > On Mon, Jul 22, 2019 at 4:13 PM Vinod Koul wrote:
> > > >
> > > > On 22-07-19, 10:16, Arnd Bergmann wrote:
> > > > > With the audio driver no longer refe
601 - 700 of 1180 matches
Mail list logo