On 6/22/2024 2:47 AM, Dmitry Baryshkov wrote:
On Fri, Jun 21, 2024 at 05:16:53PM GMT, Gokul Sriram Palanisamy wrote:
IPQ8074 uses secure PIL. Hence, adding the support for the same.
See Documentation/process/submitting-patches.rst
Thanks. Will add detailed description.
Signed-off-by:
On 6/22/2024 2:38 AM, Dmitry Baryshkov wrote:
On Fri, Jun 21, 2024 at 05:16:52PM GMT, Gokul Sriram Palanisamy wrote:
PRNG clock is needed by the secure PIL, support for the same
is added in subsequent patches.
Which 'same'?
What is 'secure PIL'?
will elaborate in the updated version.
To
On 6/21/2024 8:39 PM, Krzysztof Kozlowski wrote:
On 21/06/2024 13:46, Gokul Sriram Palanisamy wrote:
-static int q6v5_wcss_init_clock(struct q6v5_wcss *wcss)
+static int ipq8074_init_clock(struct q6v5_wcss *wcss)
+{
+ int ret;
+
+ wcss->prng_clk = devm_clk_get(wcss->dev,
On Sat, 22 Jun 2024 01:03:39 +0300, Dmitry Baryshkov wrote:
> Protection domain mapper is a QMI service providing mapping between
> 'protection domains' and services supported / allowed in these domains.
> For example such mapping is required for loading of the WiFi firmware or
> for properly
On Mon, Jun 24, 2024 at 6:14 PM Masami Hiramatsu wrote:
>
> On Tue, 21 May 2024 18:38:45 -0700
> Andrii Nakryiko wrote:
>
> > Add a set of tests to validate that stack traces captured from or in the
> > presence of active uprobes and uretprobes are valid and complete.
> >
> > For this we use BPF
On Mon, Jun 24, 2024 at 5:39 PM Masami Hiramatsu wrote:
>
> On Mon, 24 Jun 2024 13:32:35 -0700
> Andrii Nakryiko wrote:
>
> > On Mon, Jun 17, 2024 at 3:37 PM Andrii Nakryiko
> > wrote:
> > >
> > > On Tue, Jun 4, 2024 at 10:16 AM Andrii Nakryiko
> > > wrote:
> > > >
> > > > On Tue, Jun 4, 2024
On Mon, Jun 24, 2024 at 7:49 PM Andy Chiu wrote:
>
> Hi Alex,
>
> On Mon, Jun 24, 2024 at 4:21 PM Alexandre Ghiti
> wrote:
> >
> > We cannot delay the icache flush after patching some functions as we may
> > have patched a function that will get called before the icache flush.
> >
> > The only
On Mon, 17 Jun 2024 10:46:28 +0900
"Masami Hiramatsu (Google)" wrote:
> Hi,
>
> Here is the 11th version of the series to re-implement the fprobe on
> function-graph tracer. The previous version is;
>
> https://lore.kernel.org/all/171509088006.162236.7227326999861366050.stgit@devnote2/
>
>
On Mon, 24 Jun 2024 17:21:34 -0700
Andrii Nakryiko wrote:
> Given unapply_uprobe() can call remove_breakpoint() which eventually
> calls uprobe_write_opcode(), which can modify a set of memory pages and
> expects mm->mmap_lock held for write, it needs to have writer lock.
>
> Fix this by
On Mon, Jun 24, 2024 at 6:07 PM Michael S. Tsirkin wrote:
>
> On Mon, Jun 24, 2024 at 10:45:23AM +0800, Jason Wang wrote:
> > This patch synchronize operstate with admin state per RFC2863.
> >
> > This is done by trying to toggle the carrier upon open/close and
> > synchronize with the config
On Mon, Jun 24, 2024 at 5:59 PM Michael S. Tsirkin wrote:
>
> On Mon, Jun 24, 2024 at 10:45:21AM +0800, Jason Wang wrote:
> > Somtime driver may want to enable or disable the config callback. This
> > requires a synchronization with the core. So this patch change the
> > config_enabled to be a
On Tue, 21 May 2024 18:38:45 -0700
Andrii Nakryiko wrote:
> Add a set of tests to validate that stack traces captured from or in the
> presence of active uprobes and uretprobes are valid and complete.
>
> For this we use BPF program that are installed either on entry or exit
> of user function,
On Tue, 21 May 2024 18:38:45 -0700
Andrii Nakryiko wrote:
> Add a set of tests to validate that stack traces captured from or in the
> presence of active uprobes and uretprobes are valid and complete.
>
> For this we use BPF program that are installed either on entry or exit
> of user function,
On Tue, 21 May 2024 18:38:42 -0700
Andrii Nakryiko wrote:
> This helper is needed in another file, so make it a bit more uniquely
> named and expose it internally.
>
> Signed-off-by: Andrii Nakryiko
Sorry, I think this conflicts with
On 6/21/2024 3:03 PM, Dmitry Baryshkov wrote:
If the service locator server is restarted fast enough, the PDR can
rewrite locator_addr fields concurrently. Protect them by placing
modification of those fields under the main pdr->lock.
Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection
On Mon, 24 Jun 2024 13:32:35 -0700
Andrii Nakryiko wrote:
> On Mon, Jun 17, 2024 at 3:37 PM Andrii Nakryiko
> wrote:
> >
> > On Tue, Jun 4, 2024 at 10:16 AM Andrii Nakryiko
> > wrote:
> > >
> > > On Tue, Jun 4, 2024 at 7:13 AM Masami Hiramatsu
> > > wrote:
> > > >
> > > > On Tue, 21 May 2024
On Tue, 21 May 2024 18:38:42 -0700
Andrii Nakryiko wrote:
> This helper is needed in another file, so make it a bit more uniquely
> named and expose it internally.
>
> Signed-off-by: Andrii Nakryiko
Looks good to me.
Acked-by: Masami Hiramatsu (Google)
Thank you
> ---
>
Switch internals of BPF multi-uprobes to batched version of uprobe
registration and unregistration APIs.
This also simplifies BPF clean up code a bit thanks to all-or-nothing
guarantee of uprobes_register_batch().
Signed-off-by: Andrii Nakryiko
---
kernel/trace/bpf_trace.c | 23
With all the batch uprobe APIs work we are now finally ready to reap the
benefits. Switch uprobes_treelock from reader-writer spinlock to a much
more efficient and scalable per-CPU RW semaphore.
Benchmarks and numbers time. I've used BPF selftests' bench tool,
trig-uprobe-nop benchmark
Now that we have a good separate of each registration step, take
uprobes_treelock just once for relevant registration step, and then
process all relevant uprobes in one go.
Even if writer lock introduces a relatively large delay (as might happen
with per-CPU RW semaphore), this will keep overall
Similarly to what we did for uprobes_register_batch(), split
uprobe_unregister_batch() into two separate phases with different
locking needs.
First, all the VMA unregistration is performed while holding
a per-uprobe register_rwsem.
Then, we take a batched uprobes_treelock once to __put_uprobe()
Now we are ready to split alloc-and-insert coupled step into two
separate phases.
First, we allocate and prepare all potentially-to-be-inserted uprobe
instances, assuming corresponding uprobes are not yet in uprobes_tree.
This is needed so that we don't do memory allocations under
Introduce batch versions of uprobe registration (attachment) and
unregistration (detachment) APIs.
Unregistration is presumed to never fail, so that's easy.
Batch registration can fail, and so the semantics of
uprobe_register_batch() is such that either all uprobe_consumers are
successfully
To allow unbundling alloc-uprobe-and-insert step which is currently
tightly coupled, inline alloc_uprobe() logic into
uprobe_register_batch() loop. It's called from one place, so we don't
really lose much in terms of maintainability.
No functional changes.
Signed-off-by: Andrii Nakryiko
---
Simplify uprobe registration/unregistration interfaces by making offset
and ref_ctr_offset part of uprobe_consumer "interface". In practice, all
existing users already store these fields somewhere in uprobe_consumer's
containing structure, so this doesn't pose any problem. We just move
some fields
Return -ENOMEM instead of NULL, which makes caller's error handling just
a touch simpler.
Signed-off-by: Andrii Nakryiko
---
kernel/events/uprobes.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index
Revamp how struct uprobe is refcounted, and thus how its lifetime is
managed.
Right now, there are a few possible "owners" of uprobe refcount:
- uprobes_tree RB tree assumes one refcount when uprobe is registered
and added to the lookup tree;
- while uprobe is triggered and kernel is
Given unapply_uprobe() can call remove_breakpoint() which eventually
calls uprobe_write_opcode(), which can modify a set of memory pages and
expects mm->mmap_lock held for write, it needs to have writer lock.
Fix this by switching to mmap_write_lock()/mmap_write_unlock().
Fixes: da1816b1caec
There is no task_struct passed into get_user_pages_remote() anymore,
drop the parts of comment mentioning NULL tsk, it's just confusing at
this point.
Signed-off-by: Andrii Nakryiko
---
kernel/events/uprobes.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
This patch set, ultimately, switches global uprobes_treelock from RW spinlock
to per-CPU RW semaphore, which has better performance and scales better under
contention and multiple parallel threads triggering lots of uprobes.
To make this work well with attaching multiple uprobes (through BPF
On Mon, Jun 17, 2024 at 3:37 PM Andrii Nakryiko
wrote:
>
> On Tue, Jun 4, 2024 at 10:16 AM Andrii Nakryiko
> wrote:
> >
> > On Tue, Jun 4, 2024 at 7:13 AM Masami Hiramatsu wrote:
> > >
> > > On Tue, 21 May 2024 18:38:43 -0700
> > > Andrii Nakryiko wrote:
> > >
> > > > When kernel has pending
From: Yunseong Kim
parallel_test() function in vringh_test needs to verify
the creation of the guest/host pipe.
Signed-off-by: Yunseong Kim
---
tools/virtio/vringh_test.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/tools/virtio/vringh_test.c
From: Yunseong Kim
In the TRACE_EVENT(qdisc_reset) NULL dereference occurred from
qdisc->dev_queue->dev ->name
This situation simulated from bunch of veths and Bluetooth disconnection
and reconnection.
During qdisc initialization, qdisc was being set to noop_queue.
In veth_init_queue, the
Hi Pedro,
On 6/25/24 12:55 오전, Pedro Tammela wrote:
> On 24/06/2024 12:43, Yunseong Kim wrote:
>> Hi Pedro,
>>
>> On 6/25/24 12:12 오전, Pedro Tammela wrote:
>>> On 22/06/2024 01:57, ysk...@gmail.com wrote:
From: Yunseong Kim
In the TRACE_EVENT(qdisc_reset) NULL dereference occurred
On 24/06/2024 12:43, Yunseong Kim wrote:
Hi Pedro,
On 6/25/24 12:12 오전, Pedro Tammela wrote:
On 22/06/2024 01:57, ysk...@gmail.com wrote:
From: Yunseong Kim
In the TRACE_EVENT(qdisc_reset) NULL dereference occurred from
qdisc->dev_queue->dev ->name
[ 5301.595872] KASAN: null-ptr-deref
Hi Pedro,
On 6/25/24 12:12 오전, Pedro Tammela wrote:
> On 22/06/2024 01:57, ysk...@gmail.com wrote:
>> From: Yunseong Kim
>>
>> In the TRACE_EVENT(qdisc_reset) NULL dereference occurred from
>>
>> qdisc->dev_queue->dev ->name
>>
>> [ 5301.595872] KASAN: null-ptr-deref in range
>>
Hello,
syzbot found the following issue on:
HEAD commit:3226607302ca selftests: net: change shebang to bash in amt..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12a2683e98
kernel config: https://syzkaller.appspot.com/x/.config?x=e78fc116033e0ab7
On 22/06/2024 01:57, ysk...@gmail.com wrote:
From: Yunseong Kim
In the TRACE_EVENT(qdisc_reset) NULL dereference occurred from
qdisc->dev_queue->dev ->name
This situation simulated from bunch of veths and Bluetooth dis/reconnection.
During qdisc initialization, qdisc was being set to
On 24/05/23 03:57PM, Miklos Szeredi wrote:
> [trimming CC list]
>
> On Thu, 23 May 2024 at 04:49, John Groves wrote:
>
> > - memmap=! will reserve a pretend pmem device at
> >
> > - memmap=$ will reserve a pretend dax device at
> >
>
> Doesn't get me a /dev/dax or /dev/pmem
>
> Complete
Hi Alex,
On Mon, Jun 24, 2024 at 4:21 PM Alexandre Ghiti wrote:
>
> We cannot delay the icache flush after patching some functions as we may
> have patched a function that will get called before the icache flush.
>
> The only way to completely avoid such scenario is by flushing the icache
> as
On 6/18/2024 7:08 PM, Konrad Dybcio wrote:
On 6/18/24 15:13, Naina Mehta wrote:
Rename qdss@8880 memory region as qlink_logging memory region
and add qdss_mem memory region at address of 0x8850.
Split mpss_dsmharq_mem region into 2 separate regions and
reduce the size of
On Mon, Jun 24, 2024 at 10:45:23AM +0800, Jason Wang wrote:
> This patch synchronize operstate with admin state per RFC2863.
>
> This is done by trying to toggle the carrier upon open/close and
> synchronize with the config change work. This allows propagate status
> correctly to stacked devices
On Mon, Jun 24, 2024 at 10:45:21AM +0800, Jason Wang wrote:
> Somtime driver may want to enable or disable the config callback. This
> requires a synchronization with the core. So this patch change the
> config_enabled to be a integer counter. This allows the toggling of
> the config_enable to be
On Wed, Jun 5, 2024 at 1:42 PM Björn Töpel wrote:
>
> From: Björn Töpel
>
> Now that DAX is usable, enable the DAX VMEMMAP optimization as well.
>
> Signed-off-by: Björn Töpel
> ---
> arch/riscv/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/riscv/Kconfig
On Wed, Jun 5, 2024 at 1:41 PM Björn Töpel wrote:
>
> From: Björn Töpel
>
> For an architecture to support memory hotplugging, a couple of
> callbacks needs to be implemented:
>
> arch_add_memory()
> This callback is responsible for adding the physical memory into the
> direct map, and call
(resending as gmail client turned to html)
On Wed, Jun 5, 2024 at 1:41 PM Björn Töpel wrote:
>
> From: Björn Töpel
>
> The pfn_to_kaddr() function is used by KASAN's memory hotplugging
> path. Add the missing function to the RISC-V port, so that it can be
> built with MHP and CONFIG_KASAN.
>
>
We cannot delay the icache flush after patching some functions as we may
have patched a function that will get called before the icache flush.
The only way to completely avoid such scenario is by flushing the icache
as soon as we patch a function. This will probably be costly as we don't
batch
On 20/06/2024 19:03, Alexandre Ghiti wrote:
On 19/06/2024 05:40, Andy Chiu wrote:
On Tue, Jun 18, 2024 at 9:40 PM Alexandre Ghiti
wrote:
Hi Andy,
On Tue, Jun 18, 2024 at 2:48 PM Andy Chiu wrote:
On Tue, Jun 18, 2024 at 8:02 PM Alexandre Ghiti wrote:
Hi Conor,
On 17/06/2024 15:23,
On 6/21/24 1:35 PM, Ilya Leoshkevich wrote:
> Even though the KMSAN warnings generated by memchr_inv() are suppressed
> by metadata_access_enable(), its return value may still be poisoned.
>
> The reason is that the last iteration of memchr_inv() returns
> `*start != value ? start : NULL`, where
49 matches
Mail list logo
