On 03.01.24 08:16, Bibo Mao wrote:
The patch add paravirt interface for guest kernel, it checks whether
system runs on VM mode. If it is, it will detect hypervisor type. And
returns true it is KVM hypervisor, else return false. Currently only
KVM hypervisor is supported, so there is only
This patch refines ipi handling on LoongArch platform, there are
three changes with this patch.
1. Add generic get_percpu_irq api, replace some percpu irq function
such as get_ipi_irq/get_pmc_irq/get_timer_irq with get_percpu_irq.
2. Change parameter action definition with function
On LoongArch system, ipi hw uses iocsr registers, there is one iocsr
register access on ipi sender and two iocsr access on ipi interrupt
handler. On VM mode all iocsr registers accessing will trap into
hypervisor.
This patch adds pv ipi support for VM, hypercall instruction is used
to ipi sender,
System will trap into hypervisor when executing cpucfg instruction.
And now hardware only uses the area 0 - 20 for actual usage, here
one specified area 0x1000 -- 0x10ff is used for KVM hypervisor,
and the area can be extended for other hypervisors in future.
Signed-off-by: Bibo Mao
---
The patch add paravirt interface for guest kernel, it checks whether
system runs on VM mode. If it is, it will detect hypervisor type. And
returns true it is KVM hypervisor, else return false. Currently only
KVM hypervisor is supported, so there is only hypervisor detection
for KVM type.
This patchset adds pv ipi support for VM. On physical machine, ipi HW
uses IOCSR registers, however there will be trap into hypervisor with
IOCSR registers access. This patch uses SWI interrupt for IPI
notification. During ipi sending with hypercall method, there is still
one trap; however with
On LoongArch system, hypercall instruction is supported when system
runs on VM mode. This patch adds dummy function with hypercall
instruction emulation, rather than inject EXCCODE_INE invalid
instruction exception.
Signed-off-by: Bibo Mao
---
arch/loongarch/include/asm/Kbuild | 1 -
On Mon, Jan 1, 2024 at 8:11 PM Alessandro Carminati
wrote:
>
> Hello,
>
>
>
> Il giorno dom 31 dic 2023 alle ore 06:35 Masahiro Yamada
> ha scritto:
> >
> > On Tue, Dec 5, 2023 at 6:48 AM Alessandro Carminati (Red Hat)
> > wrote:
> > >
> > > In the kernel environment, situations frequently
On Tue, 2 Jan 2024 18:19:37 +0800
Zhenhua Huang wrote:
> commit 717c7c894d4b ("fs/proc: Add boot loader arguments as comment to
> /proc/bootconfig") adds bootloader argument comments into /proc/bootconfig.
>
> /proc/bootconfig shows boot_command_line[] multiple times following
> every xbc key
kprobe_emulate_call_indirect currently uses int3_emulate_call to emulate
indirect calls. However, int3_emulate_call always assumes the size of
the call to be 5 bytes when calculating the return address. This is
incorrect for register-based indirect calls in x86, which can be either
2 or 3 bytes
From: Boqun Feng
> Sent: 02 January 2024 18:54
>
> On Sat, Dec 30, 2023 at 03:49:52PM +, David Laight wrote:
> [...]
> > But it looks odd that osq_unlock()'s fast path uses _release but the very
> > similar code in osq_wait_next() uses _acquire.
> >
>
> The _release in osq_unlock() is needed
On 2023-09-12 15:31:44, Konrad Dybcio wrote:
> These clocks are now handled from within the icc framework and are
> no longer registered from within the CCF. Remove them.
>
> Signed-off-by: Konrad Dybcio
This makes the USB and IOMMUs probe again on SDM630 devices like the Sony Xperia
XA2 Ultra.
Minor fix for virtio: code wanting to access the fields inside an skb
frag should use the skb_frag_*() helpers, instead of accessing the
fields directly. This allows for extensions where the underlying
memory is not a page.
Acked-by: Stefano Garzarella
Signed-off-by: Mina Almasry
---
v3:
-
On Fri, Dec 29, 2023 at 09:36:36AM +0100, Markus Elfring wrote:
> From: Markus Elfring
> Date: Fri, 29 Dec 2023 08:42:04 +0100
>
> Replace the specification of data structures by pointer dereferences
> as the parameter for the operator “sizeof” to make the corresponding size
> determination a
On Fri, Dec 29, 2023 at 09:38:47AM +0100, Markus Elfring wrote:
> From: Markus Elfring
> Date: Fri, 29 Dec 2023 09:15:07 +0100
>
> The kfree() function was called in two cases by
> the virtio_fs_get_tree() function during error handling
> even if the passed variable contained a null pointer.
>
From: "Steven Rostedt (Google)"
A flag was needed to denote which eventfs_inode was the "events"
directory, so a bit was taken from the "nr_entries" field, as there's not
that many entries, and 2^30 is plenty. But the bit number for nr_entries
was not updated to reflect the bit taken from it,
From: "Steven Rostedt (Google)"
If a getdents() is called on the tracefs directory but does not get all
the files, it can leave a "cursor" dentry in the d_subdirs list of tracefs
dentry. This cursor dentry does not have a d_inode for it. Before
referencing tracefs_inode from the dentry, the
From: "Steven Rostedt (Google)"
If a getdents() is called on the tracefs directory but does not get all
the files, it can leave a "cursor" dentry in the d_subdirs list of tracefs
dentry. This cursor dentry does not have a d_inode for it. Before
referencing tracefs_inode from the dentry, the
On Tue, 02 Jan 2024 18:54:26 +0800
"Ubisectech Sirius" wrote:
> Dear concerned.
> Greetings!
> We are Ubisectech Sirius Team, the vulnerability lab of China
> ValiantSec.Recently, our team has discovered a issue in Linux kernel 6.7.
> technical details:
> 1. Vulnerability Description: BUG:
On Sat, Dec 30, 2023 at 03:49:52PM +, David Laight wrote:
[...]
> I don't completely understand the 'acquire'/'release' semantics (they didn't
> exist when I started doing SMP kernel code in the late 1980s).
> But it looks odd that osq_unlock()'s fast path uses _release but the very
> similar
On Wed, Dec 20, 2023 at 08:47:19AM -0600, Tanmay Shah wrote:
>
> On 11/14/23 10:23 AM, Mathieu Poirier wrote:
> > On Tue, 14 Nov 2023 at 08:22, Bjorn Andersson wrote:
> > >
> > > On Sat, Oct 14, 2023 at 04:15:47PM -0700, Tanmay Shah wrote:
> > > > From: Mathieu Poirier
> > > >
> > > >
Hi Ulf,
I'm in agreement with the modifications done to imx_rproc.c and imx_dsp_rproc.c.
There is one thing I am ambivalent on, please see below.
On Thu, Dec 28, 2023 at 12:41:55PM +0100, Ulf Hansson wrote:
> Let's avoid the boilerplate code to manage the multiple PM domain case, by
> converting
>> It is probably clear that the function call “kfree(NULL)” does not perform
>> data processing which is really useful for the caller.
>> Such a call is kept in some cases because programmers did not like to invest
>> development resources for its avoidance.
>
> on the contrary, it is extremely
On Tue, Jan 02, 2024 at 11:47:38AM +0100, Markus Elfring wrote:
> > Do you consider more clarity in your argumentation?
>
> It is probably clear that the function call “kfree(NULL)” does not perform
> data processing which is really useful for the caller.
> Such a call is kept in some cases
On 12/14/23 00:24, 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
On Thu, 14 Dec 2023 00:24:21 +0100
Ilya Leoshkevich wrote:
> Architectures use assembly code to initialize ftrace_regs and call
> ftrace_ops_list_func(). Therefore, from the KMSAN's point of view,
> ftrace_regs is poisoned on ftrace_ops_list_func entry(). This causes
> KMSAN warnings when
On Thu, Dec 14, 2023 at 12:24:54AM +0100, Ilya Leoshkevich wrote:
> Now that everything else is in place, enable KMSAN in Kconfig.
>
> Signed-off-by: Ilya Leoshkevich
> ---
> arch/s390/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Heiko Carstens
On Thu, Dec 14, 2023 at 12:24:53AM +0100, Ilya Leoshkevich wrote:
> arch_kmsan_get_meta_or_null() finds the lowcore shadow by querying the
> prefix and calling kmsan_get_metadata() again.
>
> kmsan_virt_addr_valid() delegates to virt_addr_valid().
>
> Signed-off-by: Ilya Leoshkevich
> ---
>
On Thu, Dec 14, 2023 at 12:24:49AM +0100, Ilya Leoshkevich wrote:
> Add KMSAN support for the s390 implementations of the string functions.
> Do this similar to how it's already done for KASAN, except that the
> optimized memset{16,32,64}() functions need to be disabled: it's
> important for KMSAN
On Thu, Dec 14, 2023 at 12:24:52AM +0100, Ilya Leoshkevich wrote:
> The unwind code can read uninitialized frames. Furthermore, even in
> the good case, KMSAN does not emit shadow for backchains. Therefore
> disable it for the unwinding functions.
>
> Reviewed-by: Alexander Potapenko
>
On Thu, Dec 14, 2023 at 12:24:50AM +0100, Ilya Leoshkevich wrote:
> This is normally done by the generic entry code, but the
> kernel_stack_overflow() flow bypasses it.
>
> Reviewed-by: Alexander Potapenko
> Signed-off-by: Ilya Leoshkevich
> ---
> arch/s390/kernel/traps.c | 6 ++
> 1 file
On Thu, Dec 14, 2023 at 12:24:48AM +0100, Ilya Leoshkevich wrote:
> The pages for the KMSAN metadata associated with most kernel mappings
> are taken from memblock by the common code. However, vmalloc and module
> metadata needs to be defined by the architectures.
>
> Be a little bit more careful
On Thu, Dec 14, 2023 at 12:24:47AM +0100, Ilya Leoshkevich wrote:
> KMSAN generates the following false positives on s390x:
>
> [6.063666] DEBUG_LOCKS_WARN_ON(lockdep_hardirqs_enabled())
> [ ...]
> [6.577050] Call Trace:
> [6.619637] [<0690d2de>]
sure. function was available in /proc/kallsyms.
Any suggestion how to track source IP and natted IP in bpf after NAT
masquerade?
Basically I wanted to know the Source IP and source Port after NAT IP
using 5 tuple lookup?
-- PK
On Tue, Jan 2, 2024 at 8:00 PM Steven Rostedt wrote:
>
> On Tue, 2
On Thu, Dec 14, 2023 at 12:24:45AM +0100, Ilya Leoshkevich wrote:
> Diagnose 224 stores 4k bytes, which cannot be deduced from the inline
> assembly constraints. This leads to KMSAN false positives.
>
> Unpoison the output buffer manually with kmsan_unpoison_memory().
>
> Signed-off-by: Ilya
On Thu, Dec 14, 2023 at 12:24:46AM +0100, Ilya Leoshkevich wrote:
> s390 uses assembly code to initialize ftrace_regs and call
> kprobe_ftrace_handler(). Therefore, from the KMSAN's point of view,
> ftrace_regs is poisoned on kprobe_ftrace_handler() entry. This causes
> KMSAN warnings when running
On Thu, Dec 14, 2023 at 12:24:44AM +0100, Ilya Leoshkevich wrote:
> stcctm() uses the "Q" constraint for dest, therefore KMSAN does not
> understand that it fills multiple doublewords pointed to by dest, not
> just one. This results in false positives.
>
> Unpoison the whole dest manually with
On Thu, Dec 14, 2023 at 12:24:43AM +0100, Ilya Leoshkevich wrote:
> Prevent KMSAN from complaining about buffers filled by cpacf_trng()
> being uninitialized.
>
> Tested-by: Alexander Gordeev
> Reviewed-by: Alexander Potapenko
> Signed-off-by: Ilya Leoshkevich
> ---
>
On Tue, 2 Jan 2024 11:23:54 +0530
P K wrote:
> Hi,
>
> I am unable to trace nf_nat functions using kprobe with the latest kernel.
> Previously in kernel 6.1.55-1 it was working fine.
> Can someone please check if it's broken with the latest commit or i
> have to use it differently?
>
Note,
On Tue, Jan 02, 2024 at 02:43:24PM +0100, Luca Weiss wrote:
> On Tue Jan 2, 2024 at 2:36 PM CET, Greg Kroah-Hartman wrote:
> > On Thu, Dec 21, 2023 at 02:45:26PM +0100, Luca Weiss wrote:
> > > On Thu Dec 21, 2023 at 1:53 PM CET, Konrad Dybcio wrote:
> > > > On 21.12.2023 11:34, Dmitry Baryshkov
On Tue Jan 2, 2024 at 2:36 PM CET, Greg Kroah-Hartman wrote:
> On Thu, Dec 21, 2023 at 02:45:26PM +0100, Luca Weiss wrote:
> > On Thu Dec 21, 2023 at 1:53 PM CET, Konrad Dybcio wrote:
> > > On 21.12.2023 11:34, Dmitry Baryshkov wrote:
> > > > On Thu, 21 Dec 2023 at 09:33, Luca Weiss
> > > >
On Thu, Dec 21, 2023 at 02:45:26PM +0100, Luca Weiss wrote:
> On Thu Dec 21, 2023 at 1:53 PM CET, Konrad Dybcio wrote:
> > On 21.12.2023 11:34, Dmitry Baryshkov wrote:
> > > On Thu, 21 Dec 2023 at 09:33, Luca Weiss wrote:
> > >>
> > >> On Wed Dec 20, 2023 at 1:32 PM CET, Konrad Dybcio wrote:
> >
On Mon, Jan 01, 2024 at 05:38:24AM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:fbafc3e621c3 Merge tag 'for_linus' of git://git.kernel.org..
> git tree: upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=173df3e9e8
>
On Sun, 31 Dec 2023 at 16:49, Luca Weiss wrote:
>
> Convert the .txt documentation to .yaml.
>
> Take the liberty to change the compatibles for ipq8064, apq8064, msm8974
> and msm8960 to follow the updated naming schema. These compatibles are
> not used upstream yet.
>
> Also add a compatible for
> Do you consider more clarity in your argumentation?
It is probably clear that the function call “kfree(NULL)” does not perform
data processing which is really useful for the caller.
Such a call is kept in some cases because programmers did not like to invest
development resources for its
On 31/12/2023 15:48, Luca Weiss wrote:
> It doesn't appear that the configuration is for the HFPLL is generic, so
That's ok...
> add a qcs404-specific compatible and rename the existing struct to
but why this is the solution? If the qcom,hfpll compatible was
deprecated, but it is not. This
On 31/12/2023 15:48, Luca Weiss wrote:
> Convert the .txt documentation to .yaml.
>
> Take the liberty to change the compatibles for ipq8064, apq8064, msm8974
> and msm8960 to follow the updated naming schema. These compatibles are
> not used upstream yet.
>
> +
> +properties:
> + compatible:
From: Ingo Molnar
> Sent: 02 January 2024 09:54
>
>
> * David Laight wrote:
>
> > per_cpu_ptr() indexes __per_cpu_offset[] with the cpu number.
> > This requires the cpu number be 64bit.
> > However the value is osq_lock() comes from a 32bit xchg() and there
> > isn't a way of telling gcc the
commit 717c7c894d4b ("fs/proc: Add boot loader arguments as comment to
/proc/bootconfig") adds bootloader argument comments into /proc/bootconfig.
/proc/bootconfig shows boot_command_line[] multiple times following
every xbc key value pair, that's duplicated and not necessary.
Remove redundant
On Tue, Jan 02, 2024 at 10:35:17AM +0100, Markus Elfring wrote:
> >>> So what? kfree(NULL) is perfectly acceptable.
> >>
> >> I suggest to reconsider the usefulness of such a special function call.
> >
> > Can you be more explicit in your suggestion?
>
> I hope that the change acceptance can
On 9/13/2023 7:14 PM, Konrad Dybcio wrote:
On 13.09.2023 13:14, Krzysztof Kozlowski wrote:
On 13/09/2023 12:48, Konrad Dybcio wrote:
On 13.09.2023 10:53, Krzysztof Kozlowski wrote:
On 13/09/2023 10:47, Konrad Dybcio wrote:
On 13.09.2023 09:07, Krzysztof Kozlowski wrote:
On 12/09/2023
On Wed, Dec 20, 2023 at 01:45:00PM -0800, Mina Almasry wrote:
Minor fix for virtio: code wanting to access the fields inside an skb
frag should use the skb_frag_*() helpers, instead of accessing the
fields directly. This allows for extensions where the underlying
memory is not a page.
* David Laight wrote:
> per_cpu_ptr() indexes __per_cpu_offset[] with the cpu number.
> This requires the cpu number be 64bit.
> However the value is osq_lock() comes from a 32bit xchg() and there
> isn't a way of telling gcc the high bits are zero (they are) so
> there will always be an
* David Laight wrote:
> When osq_lock() returns false or osq_unlock() returns static
> analysis shows that node->next should always be NULL.
> This means that it isn't necessary to explicitly set it to NULL
> prior to atomic_xchg(>tail, curr) on extry to osq_lock().
>
> Just in case there a
>>> So what? kfree(NULL) is perfectly acceptable.
>>
>> I suggest to reconsider the usefulness of such a special function call.
>
> Can you be more explicit in your suggestion?
I hope that the change acceptance can grow for the presented transformation.
Are you looking for an improved patch
55 matches
Mail list logo
