On 3/28/2019 1:24 PM, Yue Haibing wrote:
From: YueHaibing
KASAN report this:
BUG: KASAN: global-out-of-bounds in qedi_dbg_err+0xda/0x330 [qedi]
Read of size 31 at addr c12b0ae0 by task syz-executor.0/2429
CPU: 0 PID: 2429 Comm: syz-executor.0 Not tainted 5.0.0-rc7+ #45
Hardware name
On Thu, Mar 28, 2019 at 02:28:55PM +0100, Borislav Petkov wrote:
> On Thu, Mar 28, 2019 at 03:11:40PM +0200, Andy Shevchenko wrote:
> > Any idea how it can be done?
>
> Like this?
>
> static u8 serial_inb(unsigned long addr, int offset)
It's not a generic serial_in()...
> {
> if (early_se
On 3/25/19 1:47 PM, David Rientjes wrote:
> This ensures that the address and length provided to DBG_DECRYPT and
> DBG_ENCRYPT do not cause an overflow.
>
> At the same time, pass the actual number of pages pinned in memory to
> sev_unpin_memory() as a cleanup.
>
> Reported-by: Cfir Cohen
> Si
On Thu, Mar 28, 2019 at 02:42:13PM +0100, Borislav Petkov wrote:
> On Thu, Mar 28, 2019 at 03:21:53PM +0200, Andy Shevchenko wrote:
> > If the connection to the target is done via serial interface and
> > firmware and / or bootloader already did necessary configuration.
>
> Again: how is the user
On Thu, Mar 28, 2019 at 03:50:15PM +0200, Andy Shevchenko wrote:
> Can, but with code uglifying to workaround kstrtox() restrictions.
> simple_strtox() _just works_ as expected.
simple_strtox() also has its problems.
> Requires buffer copying, finding digits there, making a proper termination.
>
On Thu, Mar 28, 2019 at 03:52:26PM +0200, Andy Shevchenko wrote:
> It's not a generic serial_in()...
Why?
> What about mmio32 as next step?
Next step where? Is it part of your patches?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Wed, Mar 27, 2019 at 03:29:47PM -0700, Greg Thelen wrote:
> On Fri, Mar 22, 2019 at 11:15 AM Roman Gushchin wrote:
> > On Thu, Mar 07, 2019 at 08:56:32AM -0800, Greg Thelen wrote:
> > > + int cpu;
> > > +
> > > + for_each_online_cpu(cpu)
> > > + x += per_cpu_ptr(memcg->stat_
Hi Paolo and Radim,
On 2/1/19 10:47 AM, Singh, Brijesh wrote:
> svm.c is pretty huge, before we add more SEV specific commands (e.g SEV-ES,
> SEV-Migration etc) lets move the SEV command handling into a separate file.
> There is no logical changes in this series.
>
Any thoughts on this series ?
On Thu, Mar 28, 2019 at 7:07 PM Gary Guo wrote:
>
> Hi Anup,
>
> The code still does not use ASID in TLB flush routines. Without this
> added the code does not boot on systems with true ASID support.
Can you elaborate why flush by ASID is need and flush_tlb_all() will
not work?
>
> We also need
On Wed 2019-03-27 16:20:37, Sakari Ailus wrote:
> Hi Petr,
>
> On Wed, Mar 27, 2019 at 01:26:25PM +0100, Petr Mladek wrote:
> > On Tue 2019-03-26 14:41:01, Sakari Ailus wrote:
> > > Add two convenience functions for accessing node's parents:
> > >
> > > fwnode_count_parents() returns the number o
Em Wed, Mar 27, 2019 at 03:53:30PM -0400, Liang, Kan escreveu:
> On 3/18/2019 4:53 AM, Jiri Olsa wrote:
> > On Fri, Mar 15, 2019 at 11:00:14AM -0700, kan.li...@linux.intel.com wrote:
> > > From: Kan Liang
> > > Signed-off-by: Kan Liang
> > > Cc: Thomas Richter
> > > Cc: sta...@vger.kernel.org
>
On Thu, Mar 28, 2019 at 04:00:39PM +0200, Andy Shevchenko wrote:
> If it's _non-standard_ serial interface (by meaning of I/O accessors and port
> addresses), user may consider to use this options in case the interface to
> communicate with kernel is serial one and its configuration is done by othe
On Thu, Mar 28, 2019 at 7:07 PM Gary Guo wrote:
>
> Hi Anup,
>
> The code still does not use ASID in TLB flush routines. Without this
> added the code does not boot on systems with true ASID support.
>
> We also need to consider the case of CONTEXTID overflow on 32-bit
> systems. 32-bit CONTEXTID
On Wed, Mar 27, 2019 at 11:52 PM Greg KH wrote:
>
> On Wed, Mar 27, 2019 at 12:01:50PM -0700, Patrick Venture wrote:
> > On Wed, Mar 27, 2019 at 11:54 AM Greg KH wrote:
> > >
> > > On Wed, Mar 27, 2019 at 11:44:36AM -0700, Patrick Venture wrote:
> > > > On Wed, Mar 27, 2019 at 11:28 AM Greg KH
Hello,
arch/x86/include/asm/bitops.h defines clear_bit(nr, addr) for
non-constant |nr| values as follows:
void clear_bit(long nr, volatile unsigned long *addr) {
asm volatile("lock; btr %1,%0"
: "+m"(*(volatile long *)addr)
: "Ir" (nr));
}
(https://elixir.bootlin.com/linux/latest/sour
On 3/28/19 6:19 AM, raymond pang wrote:
> When CONFIG_VMAP_STACK=y, __pa() returns incorrect physical address for
> a stack virtual address. Stack DMA buffers must be avoided.
Thanks, applied.
--
Jens Axboe
The "result" variable isn't initialized on this error path.
Fixes: 55e331cf7ebe ("drivers: add support for the TI VLYNQ bus")
Signed-off-by: Dan Carpenter
---
drivers/vlynq/vlynq.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/vlynq/vlynq.c b/drivers/vlynq/vlynq.c
On Thu, Mar 28, 2019 at 03:05:08PM +0100, Borislav Petkov wrote:
> On Thu, Mar 28, 2019 at 03:52:26PM +0200, Andy Shevchenko wrote:
> > It's not a generic serial_in()...
>
> Why?
By name and by what it's handling (only byte accesses to I/O or MMIO).
> > What about mmio32 as next step?
>
> Next
On Thu, Mar 07, 2019 at 08:56:32AM -0800, Greg Thelen wrote:
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3880,6 +3880,7 @@ struct wb_domain *mem_cgroup_wb_domain(struct
> bdi_writeback *wb)
> * @pheadroom: out parameter for number of allocatable pages according to
> memcg
> * @pdirt
On Thursday, March 03/28/19, 2019 at 18:10:37 +0530, Jason Gunthorpe wrote:
> On Wed, Mar 27, 2019 at 07:08:54PM +0530, Potnuri Bharat Teja wrote:
> > On Saturday, March 03/23/19, 2019 at 08:07:46 +0530, Kangjie Lu wrote:
> > >
> > >
> > > > On Mar 8, 2019, at 11:19 PM, Kangjie Lu wrote:
> > > >
The KASAN shadow area is mapped into vmemmap space:
0x8000 0400 to 0x8000 0600 .
For this vmemmap has to be disabled.
Cc: Daniel Axtens
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/Kconfig.debug| 3 +-
arch/powe
On Thu, Mar 28, 2019 at 03:03:29PM +0100, Borislav Petkov wrote:
> On Thu, Mar 28, 2019 at 03:50:15PM +0200, Andy Shevchenko wrote:
> > Can, but with code uglifying to workaround kstrtox() restrictions.
> > simple_strtox() _just works_ as expected.
>
> simple_strtox() also has its problems.
Yes!
On Thu, Mar 28, 2019 at 07:50:23PM +0530, Potnuri Bharat Teja wrote:
> On Thursday, March 03/28/19, 2019 at 18:10:37 +0530, Jason Gunthorpe wrote:
> > On Wed, Mar 27, 2019 at 07:08:54PM +0530, Potnuri Bharat Teja wrote:
> > > On Saturday, March 03/23/19, 2019 at 08:07:46 +0530, Kangjie Lu wrote:
>
On 03/27, Joel Fernandes wrote:
>
> Also, based on Kees comment, I think it appears to me that get_pid and
> put_pid can race in this way in the original code right?
>
> get_pid put_pid
>
> atomic_dec_and_test returns 1
> atomic_inc
>
On Thu, Mar 28, 2019 at 03:13:07PM +0100, Borislav Petkov wrote:
> On Thu, Mar 28, 2019 at 04:00:39PM +0200, Andy Shevchenko wrote:
> > If it's _non-standard_ serial interface (by meaning of I/O accessors and
> > port
> > addresses), user may consider to use this options in case the interface to
>
On Tue 2019-03-26 15:24:50, Andy Shevchenko wrote:
> On Tue, Mar 26, 2019 at 02:11:35PM +0100, Rasmus Villemoes wrote:
> > On 26/03/2019 13.41, Sakari Ailus wrote:
> > > Add support for %pfw conversion specifier (with "f" and "P" modifiers) to
> > > support printing full path of the node, including
On 28/03/2019 14:09, Anup Patel wrote:
> On Thu, Mar 28, 2019 at 7:07 PM Gary Guo wrote:
>>
>> Hi Anup,
>>
>> The code still does not use ASID in TLB flush routines. Without this
>> added the code does not boot on systems with true ASID support.
>
> Can you elaborate why flush by ASID is need a
On 3/28/2019 7:47 PM, Dan Carpenter wrote:
The "result" variable isn't initialized on this error path.
Fixes: 55e331cf7ebe ("drivers: add support for the TI VLYNQ bus")
Signed-off-by: Dan Carpenter
Reviewed-by: Mukesh Ojha
-Mukesh
---
drivers/vlynq/vlynq.c | 3 ++-
1 file changed, 2 in
On 28/03/2019 14:13, Anup Patel wrote:
> On Thu, Mar 28, 2019 at 7:07 PM Gary Guo wrote:
>>
>> Hi Anup,
>>
>> The code still does not use ASID in TLB flush routines. Without this
>> added the code does not boot on systems with true ASID support.
>>
>> We also need to consider the case of CONTEXT
On Thu, Mar 28, 2019 at 04:20:01PM +0200, Andy Shevchenko wrote:
> By name and by what it's handling (only byte accesses to I/O or MMIO).
Your series does only byte accesses so you can use byte variant.
> My point is, that doing branch(es) on each I/O call is not good as simple
> calling the prop
On Thu, Mar 28, 2019 at 04:23:02PM +0200, Andy Shevchenko wrote:
> If it's strong opinion, I consider this rather as NAK.
> Thank you for review.
Your call.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Wed 2019-03-27 16:10:48, Sakari Ailus wrote:
> Hi Petr,
>
> On Tue, Mar 26, 2019 at 04:13:07PM +0100, Petr Mladek wrote:
> > On Fri 2019-03-22 17:29:30, Sakari Ailus wrote:
> > > Add support for %pfw conversion specifier (with "f" and "P" modifiers) to
> > > support printing full path of the no
On 3/28/2019 7:46 PM, Bo YU wrote:
When compiling with check flag: make -C tools/bpf/bpftool/
gcc will warning:
jit_disasm.c:119:29: warning: assignment discards ‘const’ qualifier
from pointer target type [-Wdiscarded-qualifiers]
info.disassembler_options = disassembler_options;
So conver
On Thu, Mar 28, 2019 at 03:57:44AM +0100, Jann Horn wrote:
> On Thu, Mar 28, 2019 at 3:34 AM Joel Fernandes wrote:
> > On Thu, Mar 28, 2019 at 01:59:45AM +0100, Jann Horn wrote:
> > > On Thu, Mar 28, 2019 at 1:06 AM Kees Cook wrote:
> > > > On Wed, Mar 27, 2019 at 7:53 AM Joel Fernandes (Google)
We forgot to set "err" on this error path.
Fixes: 9e543e22e204 ("irqchip: Add driver for Loongson-1 interrupt controller")
Signed-off-by: Dan Carpenter
---
drivers/irqchip/irq-ls1x.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/irqchip/irq-ls1x.c b/drivers/irqchip/irq-ls1x.c
index
On Thu, Mar 28, 2019 at 03:26:19PM +0100, Oleg Nesterov wrote:
> On 03/27, Joel Fernandes wrote:
> >
> > Also, based on Kees comment, I think it appears to me that get_pid and
> > put_pid can race in this way in the original code right?
> >
> > get_pid put_pid
> >
> >
On 3/28/2019 7:07 PM, Thomas Bogendoerfer wrote:
smatch complaint:
arch/mips/sgi-ip27/ip27-irq.c:123 shutdown_bridge_irq()
warn: variable dereferenced before check 'hd' (see line 121)
Fix it by removing local variable and use hd->pin directly.
Fixes: 69a07a41d908 ("MIPS: SGI-IP27:
On Wed, Mar 27, 2019 at 11:43:20PM +, David Howells wrote:
> +static void binderfs_free_fc(struct fs_context *fc)
> +{
> + struct binderfs_info *info = fc->s_fs_info;
> +
> + if (info) {
> + struct ipc_namespace *ipc_ns = fc->s_fs_info;
> + put_ipc_ns(ipc_ns);
I
On Thu, Mar 28, 2019 at 03:35:35PM +0100, Borislav Petkov wrote:
> On Thu, Mar 28, 2019 at 04:23:02PM +0200, Andy Shevchenko wrote:
> > If it's strong opinion, I consider this rather as NAK.
> > Thank you for review.
>
> Your call.
Yes, as I said I won't uglify code to pursue kstrtox() whim.
Than
On Thu, Mar 28, 2019 at 03:34:47PM +0100, Borislav Petkov wrote:
> On Thu, Mar 28, 2019 at 04:20:01PM +0200, Andy Shevchenko wrote:
> > By name and by what it's handling (only byte accesses to I/O or MMIO).
>
> Your series does only byte accesses so you can use byte variant.
>
> > My point is, th
On Thu, Mar 28, 2019 at 12:13 PM Sakari Ailus
wrote:
>
> Hi Rafael,
>
> On Thu, Mar 28, 2019 at 10:38:01AM +0100, Rafael J. Wysocki wrote:
> > On Wed, Mar 27, 2019 at 3:20 PM Sakari Ailus
> > wrote:
> > >
> > > Hi Petr,
> > >
> > > On Wed, Mar 27, 2019 at 01:26:25PM +0100, Petr Mladek wrote:
> >
On Thu, 2019-03-28 at 06:38 -0700, Angus Ainslie (Purism) wrote:
> Fix a typo in the compatible string
>
> Signed-off-by: Angus Ainslie (Purism)
Reviwed-by: Daniel Baluta
On Wed, Mar 27, 2019 at 11:21:58AM -0700, Matthew Wilcox wrote:
> On Wed, Mar 27, 2019 at 05:29:57PM +, Catalin Marinas wrote:
> > On Wed, Mar 27, 2019 at 09:44:32AM +0100, Michal Hocko wrote:
> > > As long as there is an implicit __GFP_NOFAIL then kmemleak is simply
> > > broken no matter what
On 3/28/2019 6:43 PM, Geert Uytterhoeven wrote:
gpiochip_free_hogs() was always called from gpiochip_remove(), not
of_gpiochip_remove(). It is now also called from the failure patch in
gpiochip_add_data_with_key().
Fixes: f625d4601759f1cf ("gpio: add GPIO hogging mechanism")
Signed-off-by: Ge
On Wed, Mar 27, 2019 at 02:02:27PM -0400, Qian Cai wrote:
> On 3/27/19 1:29 PM, Catalin Marinas wrote:
> > From dc4194539f8191bb754901cea74c86e7960886f8 Mon Sep 17 00:00:00 2001
> > From: Catalin Marinas
> > Date: Wed, 27 Mar 2019 17:20:57 +
> > Subject: [PATCH] mm: kmemleak: Add an emergency
On Wed, Mar 13, 2019 at 04:42:15PM +0800, ryder@kernel.org wrote:
> From: Ryder Lee
>
> This adds basic support for MT7629 reference board.
>
> Signed-off-by: Ryder Lee
> ---
> Changes since v1:
> -Fix unit-address warnings.
> -Put all the mmio peripherals under a simple-bus node.
> -Drop a
Greetings,
We are consultancy firm situated in Bahrain currently looking to finance new or
existing projects in any industry.
Currently we are sourcing for investment opportunities for our review and
consideration and we provide financial and strategic advisory services to
growing companies an
On Wed, Mar 27, 2019 at 05:38:46PM -0400, Joel Fernandes wrote:
> On Wed, Mar 27, 2019 at 11:44:37AM -0700, Paul E. McKenney wrote:
> > On Wed, Mar 27, 2019 at 01:45:45PM -0400, Joel Fernandes wrote:
> > > On Wed, Mar 27, 2019 at 08:53:51AM -0700, Paul E. McKenney wrote:
> > > > On Wed, Mar 27, 201
On 28.03.19 14:43, Oscar Salvador wrote:
> Hi,
>
> since last two RFCs were almost unnoticed (thanks David for the feedback),
> I decided to re-work some parts to make it more simple and give it a more
> testing, and drop the RFC, to see if it gets more attention.
> I also added David's feedback,
On Wed, Mar 13, 2019 at 11:00:07AM +0200, Georgi Djakov wrote:
> In addition to frequency and voltage, some devices may have bandwidth
> requirements for their interconnect throughput - for example a CPU
> or GPU may also need to increase or decrease their bandwidth to DDR
> memory based on the cur
On Sat, Mar 16, 2019 at 12:32:49AM +0530, Sibi Sankar wrote:
>
>
> On 3/13/19 2:30 PM, Georgi Djakov wrote:
> > Here is a proposal to extend the OPP bindings with bandwidth based on
> > a previous discussion [1].
> >
> > Every functional block on a SoC can contribute to the system power
> > effi
The next patch will introduce another approach to compute the next
interrupt based on the array suffixes derived algorithm. This one
will replace the variance computation code.
The patch review will be too complex if we change the code little by
little, it is much simpler to remove the variance co
The previous approach based on the variance was discarding values from
the timings when they were considered as anomalies as stated by the
normal law statistical model.
However in the interrupt life, there can be multiple anomalies due to
the nature of the device generating the interrupts, and mos
On Thu, Mar 28, 2019 at 3:41 PM Angus Ainslie (Purism) wrote:
>
> The imx8mq needs to be specified to check the clk ratio.
>
> Signed-off-by: Angus Ainslie (Purism)
> ---
> Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentati
Since we're just talking about RCU stuff now, adding Paul McKenney to
the thread.
On Thu, Mar 28, 2019 at 3:37 PM Joel Fernandes wrote:
> On Thu, Mar 28, 2019 at 03:57:44AM +0100, Jann Horn wrote:
> > On Thu, Mar 28, 2019 at 3:34 AM Joel Fernandes
> > wrote:
> > > On Thu, Mar 28, 2019 at 01:59:
On Wed, 13 Mar 2019 15:10:30 +0100, Neil Armstrong wrote:
> The Amlogic G12A has a slighly different Power Control, but uses the
> same address space and sysctrl registers.
>
> Signed-off-by: Neil Armstrong
> ---
> .../devicetree/bindings/power/amlogic,meson-gx-pwrc.txt | 4 +++-
> 1 file
On Wed, 13 Mar 2019 15:20:40 +0100, Christina Quast wrote:
> In the iMX7d datasheet, the PAD_CTL_DSE_X* values are different from
> the documentation.
>
> Changes since v2:
> * Changed patch title to 'dt-bindings: pinctrl: imx7d:'
>
> Signed-off-by: Christina Quast
> ---
> .../devicetree/bindin
Hi,
First, thanks for taking a look at this.
On 3/28/19 5:04 AM, Rafael J. Wysocki wrote:
On Tue, Mar 26, 2019 at 11:40 PM Jeremy Linton wrote:
ACPI 6.3 adds a flag to indicate that child nodes are all
identical cores. This is useful to authoritatively determine
if a set of (possibly offline
Most architectures current have a debugfs file for dumping the kernel
page tables. Currently each architecture has to implement custom
functions for walking the page tables because the generic
walk_page_range() function is unable to walk the page tables used by the
kernel.
This series extends 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 will be provided by the
p?d_large() 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_large() functions/macros.
For mips, we only support large pages on 64 bit.
For 64 b
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_large() functions/macros.
For riscv a page is large when it has a read, write or exe
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_large() functions/macros.
For s390, pud_large() and pmd_large() are already implemen
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_large() functions/macros.
For x86 we already have static inline functions, so simply
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 p?d_large() macros, provide generic
does nothing defaults.
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
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/mm/dump.c | 117 ++-
1 file changed, 59 insertions(+), 58 deletions(-)
diff --git a/a
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:
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
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
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
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
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
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
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_large() functions/macros.
For sparc 64 bit, pmd_large() and pud_large() are already
On 3/28/19 8:43 AM, Pierre Morel wrote:
On 26/03/2019 19:57, Tony Krowiak wrote:
On 3/22/19 10:43 AM, Pierre Morel wrote:
We prepare the interception of the PQAP/AQIC instruction for
the case the AQIC facility is enabled in the guest.
...snip...
+/*
+ * handle_pqap: Handling pqap intercept
On Thu, 2019-03-28 at 14:59 +, Catalin Marinas wrote: 2
> +/* minimum memory pool sizes */
> +#define MIN_OBJECT_POOL (NR_CPUS * 4)
> +#define MIN_SCAN_AREA_POOL (NR_CPUS * 1)
I am thinking about making those are tunable, so people could have a big pool
depends on
From: Saravana Kannan
Many CPU architectures have caches that can scale independent of the
CPUs. Frequency scaling of the caches is necessary to make sure the cache
is not a performance bottleneck that leads to poor performance and
power. The same idea applies for RAM/DDR.
To achieve this, this
Export 'dev_pm_opp_find_opp_of_np' and 'of_parse_required_nodes'
as it will be used by passive governor to parse and auto-populate
mapping specified using the required-opps property.
Signed-off-by: Sibi Sankar
---
drivers/opp/of.c | 13 +++--
include/linux/pm_opp.h | 13 +++
On Thu, Mar 28, 2019 at 01:50:29PM +0200, Pekka Enberg wrote:
> On 27/03/2019 2.59, Qian Cai wrote:
> > > > Unless there is a brave soul to reimplement the kmemleak to embed it's
> > > > metadata into the tracked memory itself in a foreseeable future, this
> > > > provides a good balance between en
This RFC series aims to add cpu based scaling support to the passive
governor and scale DDR with a generic interconnect bandwidth based
devfreq driver on SDM845 SoC. This series achieves similar functionality
to Georgi's Patch series (https://patchwork.kernel.org/cover/10850817/)
and can be used wi
Add and export helpers 'dev_pm_opp_get_avg_bw()' and
'dev_pm_opp_get_peak_bw()' that can be used to get the
average and peak bandwidth values read from device tree
when present.
Signed-off-by: Sibi Sankar
---
drivers/opp/core.c | 38 ++
include/linux/pm_op
Add dt-bindings support for a generic interconnect bandwidth voting
devfreq driver.
Signed-off-by: Sibi Sankar
---
.../devicetree/bindings/devfreq/icbw.txt | 146 ++
1 file changed, 146 insertions(+)
create mode 100644 Documentation/devicetree/bindings/devfreq/icbw.txt
dif
From: Saravana Kannan
This driver registers itself as a devfreq device that allows devfreq
governors to make bandwidth votes for an interconnect path. This allows
applying various policies for different interconnect paths using devfreq
governors.
Example uses:
* Use the devfreq performance gover
Add and export 'dev_pm_opp_update_voltage' to find and update voltage
of an opp for a given frequency. This will be useful to update the opps
with voltages read back from firmware.
Signed-off-by: Sibi Sankar
---
drivers/opp/core.c | 62 ++
include/linu
Add a OPP tables for the cpu nodes.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 182 +++
1 file changed, 182 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index cd8ac481381b..072563f6b6cb
Add nodes to enable DDR devfreq driver on SDM845 SoC.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 80
1 file changed, 80 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 072563f6b
Add support to parse and update OPP tables attached to the cpu nodes.
Signed-off-by: Sibi Sankar
---
drivers/cpufreq/qcom-cpufreq-hw.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
b/drivers/cpufreq/qcom-cpuf
On 3/28/2019 6:43 PM, Geert Uytterhoeven wrote:
The err_remove_chip block is too coarse, and may perform cleanup that
must not be done. E.g. if of_gpiochip_add() fails, of_gpiochip_remove()
is still called, causing:
OF: ERROR: Bad of_node_put() on /soc/gpio@e605
CPU: 1 PID: 20 C
On 28.03.19 16:09, David Hildenbrand wrote:
> On 28.03.19 14:43, Oscar Salvador wrote:
>> Hi,
>>
>> since last two RFCs were almost unnoticed (thanks David for the feedback),
>> I decided to re-work some parts to make it more simple and give it a more
>> testing, and drop the RFC, to see if it gets
On 3/28/19 9:06 AM, Pierre Morel wrote:
On 26/03/2019 21:45, Tony Krowiak wrote:
On 3/22/19 10:43 AM, Pierre Morel wrote:
The AP interruptions are assigned on a queue basis and
the GISA structure is handled on a VM basis, so that
we need to add a structure we can retrieve from both side
s/sid
SAMA5 devices use the newer DRM driver for LCD. They don't need
the older FB driver: remove the Kconfig option for them.
Signed-off-by: Nicolas Ferre
---
arch/arm/mach-at91/Kconfig | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index
On 3/28/2019 6:43 PM, Geert Uytterhoeven wrote:
If the call to of_gpiochip_scan_gpios() in of_gpiochip_add() fails, no
error handling is performed. This lead to the need of callers to call
of_gpiochip_remove() on failure, which causes "BAD of_node_put() on ..."
if the failure happened before t
On Wed, 2019-03-27 at 14:19 -0400, Sasha Levin wrote:
> From: Slavomir Kaslev
>
> [ Upstream commit ee5e001196d1345b8fee25925ff5f1d67936081e ]
>
> The current implementation of splice() and tee() ignores O_NONBLOCK
> set
> on pipe file descriptors and checks only the SPLICE_F_NONBLOCK flag
> for
On Thu, 2019-03-28 at 15:05 +, Catalin Marinas wrote:
> > It takes 2 runs of LTP oom01 tests to disable kmemleak.
>
> What configuration are you using (number of CPUs, RAM)? I tried this on
> an arm64 guest under kvm with 4 CPUs and 512MB of RAM, together with
> fault injection on kmemleak_obj
If your goal is to be able to boot from any 4k-aligned address, then
disallowing boots between PAGE_OFFSET and PAGE_OFSSET + vmlinux_size
seems counterproductive, since there are a lot of 4k-aligned addresses
in that range that are now disallowed. (And worse, the specific range
of disallowed addres
- On Mar 28, 2019, at 3:49 AM, schwidefsky schwidef...@de.ibm.com wrote:
> On Wed, 27 Mar 2019 16:38:32 -0400
> "Carlos O'Donell" wrote:
>
>> On 3/27/19 5:16 AM, Martin Schwidefsky wrote:
>> > On Mon, 25 Mar 2019 11:54:32 -0400 (EDT)
>> > Mathieu Desnoyers wrote:
>> >
>> +++ b/sysde
On Tue, Mar 26, 2019 at 9:31 PM Andy Lutomirski wrote:
>
> On Tue, Mar 26, 2019 at 3:35 AM Reshetova, Elena
> wrote:
> >
> > > On Mon, Mar 18, 2019 at 1:16 PM Andy Lutomirski wrote:
> > > > On Mon, Mar 18, 2019 at 2:41 AM Elena Reshetova
> > > > wrote:
> > > > > Performance:
> > > > >
> > > > >
On Thu, Mar 28, 2019 at 12:24 AM Borislav Petkov wrote:
>
> Well, but copy_user_generic() (which ends up calling the
> copy_user_handle_tail() eventually) casts those __user pointers to
> (__force void *). Converting them back to __user looks strange to me.
>
> Linus?
Well, it does that because t
201 - 300 of 687 matches
Mail list logo
