On 9/17/25 6:41 AM, Neeraj Kumar wrote:
> CXL region information preserved from the LSA needs to be exported for
> use by the CXL driver for CXL region re-creation.
>
> Signed-off-by: Neeraj Kumar
> ---
> drivers/nvdimm/dimm_devs.c | 18 ++
> include/li
Add config LIVEPATCH_DEBUG and define DEBUG if CONFIG_LIVEPATCH_DEBUG
is set, then pr_debug() can print a debug level message, it is a easy
way to get debug information without dynamic debugging.
Signed-off-by: Tiezhu Yang
---
kernel/livepatch/Kconfig | 8
kernel/livepatch
Save region information stored in cxlr to nd_set during
cxl_pmem_region_probe in nd_set. This saved region information is being
stored into LSA, which will be used for cxl region persistence
Signed-off-by: Neeraj Kumar
---
drivers/cxl/pmem.c | 13 +++--
1 file changed, 7 insertions
CXL region information preserved from the LSA needs to be exported for
use by the CXL driver for CXL region re-creation.
Signed-off-by: Neeraj Kumar
---
drivers/nvdimm/dimm_devs.c | 18 ++
include/linux/libnvdimm.h | 2 ++
2 files changed, 20 insertions(+)
diff --git a
Preserve region information from region label during nvdimm_probe. This
preserved region information is used for creating cxl region to achieve
region persistency across reboot.
Signed-off-by: Neeraj Kumar
---
drivers/nvdimm/dimm.c | 4
drivers/nvdimm/label.c| 41
Save region information stored in cxlr to nd_set during
cxl_pmem_region_probe in nd_set. This saved region information is being
stored into LSA, which will be used for cxl region persistence
Signed-off-by: Neeraj Kumar
---
drivers/cxl/pmem.c | 13 +++--
1 file changed, 7 insertions
Preserve region information from region label during nvdimm_probe. This
preserved region information is used for creating cxl region to achieve
region persistency across reboot.
Signed-off-by: Neeraj Kumar
---
drivers/nvdimm/dimm.c | 4
drivers/nvdimm/label.c| 41
CXL region information preserved from the LSA needs to be exported for
use by the CXL driver for CXL region re-creation.
Signed-off-by: Neeraj Kumar
---
drivers/nvdimm/dimm_devs.c | 18 ++
include/linux/libnvdimm.h | 2 ++
2 files changed, 20 insertions(+)
diff --git a
can print a debug level message, it is a easy
> >> way to get debug information without dynamic debugging.
> >
> > I do not have a strong opinion but is it really worth it? Configuring
>
> This is an alternative way, there are some similar usages:
>
> drivers/iom
On 2025/9/11 下午9:50, Miroslav Benes wrote:
Hi,
On Tue, 9 Sep 2025, Tiezhu Yang wrote:
Add config LIVEPATCH_DEBUG and define DEBUG if CONFIG_LIVEPATCH_DEBUG
is set, then pr_debug() can print a debug level message, it is a easy
way to get debug information without dynamic debugging.
I do not
Hi,
On Tue, 9 Sep 2025, Tiezhu Yang wrote:
> Add config LIVEPATCH_DEBUG and define DEBUG if CONFIG_LIVEPATCH_DEBUG
> is set, then pr_debug() can print a debug level message, it is a easy
> way to get debug information without dynamic debugging.
I do not have a strong opinion but is
On 13/08/25 04:11PM, Jonathan Cameron wrote:
On Wed, 30 Jul 2025 17:41:59 +0530
Neeraj Kumar wrote:
Preserve region information from region label during nvdimm_probe. This
preserved region information is used for creating cxl region to achieve
region persistency across reboot.
Signed-off-by
On Wed, 30 Jul 2025 17:42:00 +0530
Neeraj Kumar wrote:
> cxl region information preserved from LSA need to be exported so as to
> use by cxl driver for cxl region re-creation
CXL region information preserved from the LAS needs to be exported for
use by the CXL driver for CXL region re-cr
On Wed, 30 Jul 2025 17:41:59 +0530
Neeraj Kumar wrote:
> Preserve region information from region label during nvdimm_probe. This
> preserved region information is used for creating cxl region to achieve
> region persistency across reboot.
>
> Signed-off-by: Neeraj Kumar
See
Thanks for the quick review. You're right—this patch is a false
positive. Modern compilers zero out the remaining fields, so the fix
isn't needed.
I'll be withdrawing all the patches and will ensure we more carefully
evaluate our robot's findings before submitting in the future.
Thanks for your h
ould a summary phrase like “Prevent information leak in
virtio_transport_shutdown()”
be nicer?
Regards,
Markus
On Tue, Aug 05, 2025 at 01:10:09PM +0800, bsdhenrymar...@gmail.com wrote:
From: Henry Martin
The `struct virtio_vsock_pkt_info` is declared on the stack but only
partially initialized (only `op`, `flags`, and `vsk` are set)
The uninitialized fields (including `pkt_len`, `remote_cid`,
`remote_p
在 2025/8/5 13:10, bsdhenrymar...@gmail.com 写道:
From: Henry Martin
The `struct virtio_vsock_pkt_info` is declared on the stack but only
partially initialized (only `op`, `flags`, and `vsk` are set)
The uninitialized fields (including `pkt_len`, `remote_cid`,
`remote_port`, etc.) contain resid
From: Henry Martin
The `struct virtio_vsock_pkt_info` is declared on the stack but only
partially initialized (only `op`, `flags`, and `vsk` are set)
The uninitialized fields (including `pkt_len`, `remote_cid`,
`remote_port`, etc.) contain residual kernel stack data. This structure
is passed to
Save region information stored in cxlr to nd_set during
cxl_pmem_region_probe in nd_set. This saved region information is being
stored into LSA, which will be used for cxl region persistence
Signed-off-by: Neeraj Kumar
---
drivers/cxl/pmem.c | 13 +++--
1 file changed, 7 insertions
Preserve region information from region label during nvdimm_probe. This
preserved region information is used for creating cxl region to achieve
region persistency across reboot.
Signed-off-by: Neeraj Kumar
---
drivers/nvdimm/dimm.c | 4
drivers/nvdimm/label.c| 41
cxl region information preserved from LSA need to be exported so as to
use by cxl driver for cxl region re-creation
Signed-off-by: Neeraj Kumar
---
drivers/nvdimm/dimm_devs.c | 18 ++
include/linux/libnvdimm.h | 2 ++
2 files changed, 20 insertions(+)
diff --git a/drivers
cxl region information preserved from LSA need to be exported so as to
use by cxl driver for cxl region re-creation
Signed-off-by: Neeraj Kumar
---
drivers/nvdimm/dimm_devs.c | 18 ++
include/linux/libnvdimm.h | 2 ++
2 files changed, 20 insertions(+)
diff --git a/drivers
Save region information stored in cxlr to nd_set during
cxl_pmem_region_probe in nd_set. This saved region information is being
stored into LSA, which will be used for cxl region persistence
Signed-off-by: Neeraj Kumar
---
drivers/cxl/pmem.c | 13 +++--
1 file changed, 7 insertions
Preserve region information from region label during nvdimm_probe. This
preserved region information is used for creating cxl region to achieve
region persistency across reboot.
Signed-off-by: Neeraj Kumar
---
drivers/nvdimm/dimm.c | 4
drivers/nvdimm/label.c| 41
The current exeception register structure in selftests are missing
few registers (e.g stval). Instead of adding it manually, change
the ex_regs to align with pt_regs to make it future proof.
Suggested-by: Andrew Jones
Reviewed-by: Andrew Jones
Signed-off-by: Atish Patra
---
.../selftests/kvm/i
On 4/30/25 12:05 AM, Andrew Jones wrote:
On Tue, Apr 29, 2025 at 05:18:45PM -0700, Atish Patra wrote:
The current exeception register structure in selftests are missing
few registers (e.g stval). Instead of adding it manually, change
the ex_regs to align with pt_regs to make it future proof.
On Tue, Apr 29, 2025 at 05:18:45PM -0700, Atish Patra wrote:
> The current exeception register structure in selftests are missing
> few registers (e.g stval). Instead of adding it manually, change
> the ex_regs to align with pt_regs to make it future proof.
>
> Suggested-by: Andrew Jones
> Signed
The current exeception register structure in selftests are missing
few registers (e.g stval). Instead of adding it manually, change
the ex_regs to align with pt_regs to make it future proof.
Suggested-by: Andrew Jones
Signed-off-by: Atish Patra
---
.../selftests/kvm/include/riscv/processor.h
Extent information can be helpful to the user to coordinate memory usage
with the external orchestrator and FM.
Expose the details of region extents by creating the following
sysfs entries.
/sys/bus/cxl/devices/dax_regionX/extentX.Y
/sys/bus/cxl/devices/dax_regionX/extentX.Y
cxl_dpa_to_region() finds the region from a tuple.
The search involves finding the device endpoint decoder as well.
Dynamic capacity extent processing uses the endpoint decoder HPA
information to calculate the HPA offset. In addition, well behaved
extents should be contained within an endpoint
On Sat, 29 Mar 2025 03:30:37 +0530 Siddarth G wrote:
> Cppcheck reported a style warning:
> int result is assigned to long long variable. If the variable is long long
> to avoid loss of information, then you have loss of information.
>
> Changing the type of page_size from &#
Cppcheck reported a style warning:
int result is assigned to long long variable. If the variable is long long
to avoid loss of information, then you have loss of information.
Changing the type of page_size from 'unsigned int' to 'unsigned long long'
was considered. But
from the kernel or userspace.
>
> Additionally, some of the bpf_attr struct fields contain pointers to
> arbitrary memory. Currently the functionality to determine whether or
> not a pointer refers to kernel memory or userspace memory is exposed
> to the bpf verifier, but that infor
exposes that
information to applicable LSM hooks.
Change list:
- v6 -> v7
- use gettid/pid in lieu of getpid/tgid in test condition
- v5 -> v6
- fix regression caused by is_kernel renaming
- simplify test logic
- v4 -> v5
- merge v4 selftest breakout patch back into a single patch
e of this is the bpf_prog_load subcommand and its
> fd_array. This data is made available and used by the verifier but not
> made available to the LSM subsystem. This patchset simply exposes that
> information to applicable LSM hooks.
>
> [...]
Here is the summary with links:
-
struct fields contain pointers to
arbitrary memory. Currently the functionality to determine whether or
not a pointer refers to kernel memory or userspace memory is exposed
to the bpf verifier, but that information is missing from various LSM
hooks.
Here we augment the LSM hooks to provide this data
struct fields contain pointers to
arbitrary memory. Currently the functionality to determine whether or
not a pointer refers to kernel memory or userspace memory is exposed
to the bpf verifier, but that information is missing from various LSM
hooks.
Here we augment the LSM hooks to provide this data
exposes that
information to applicable LSM hooks.
Change list:
- v5 -> v6
- fix regression caused by is_kernel renaming
- simplify test logic
- v4 -> v5
- merge v4 selftest breakout patch back into a single patch
- change "is_kernel" to "kernel"
- add selftest
struct fields contain pointers to
arbitrary memory. Currently the functionality to determine whether or
not a pointer refers to kernel memory or userspace memory is exposed
to the bpf verifier, but that information is missing from various LSM
hooks.
Here we augment the LSM hooks to provide this data
exposes that
information to applicable LSM hooks.
Change list:
- v4 -> v5
- merge v4 selftest breakout patch back into a single patch
- change "is_kernel" to "kernel"
- add selftest using new kernel flag
- v3 -> v4
- split out selftest changes into a separate pa
Extract the meat of __do_cpuid_func_emulated() into a separate helper,
cpuid_func_emulated(), so that cpuid_func_emulated() can be used with a
single CPUID entry. This will allow marking emulated features as fully
supported in the guest cpu_caps without needing to hardcode the set of
emulated feat
On Thu, Nov 7, 2024 at 2:38 PM Luis Chamberlain wrote:
>
> On Wed, Nov 06, 2024 at 02:19:38PM -0800, Matthew Maurer wrote:
> > >
> > > > If booted against an old kernel, it will
> > > > behave as though there is no modversions information.
> > >
On Mon, Nov 18, 2024 at 04:09:34PM -0800, Matthew Maurer wrote:
> > Thinking about this some more, if we're going down enabling a new
> > option, it seems to beg the question if the old *two* ksymtab sections
> > could just be folded into the a new one where the "gpl only" thing
> > becomes just on
On Thu, Nov 07, 2024 at 02:38:13PM -0800, Luis Chamberlain wrote:
> The only thing left I think to test is the impact at runtime, and the
> only thing I can think of is first we use find_symbol() on resolve_symbol()
> which it took me a while to review and realize that this just uses a
> completel
> Thinking about this some more, if we're going down enabling a new
> option, it seems to beg the question if the old *two* ksymtab sections
> could just be folded into the a new one where the "gpl only" thing
> becomes just one "column" as you call it. Reasons I ask, it seems like
> we're duplicat
On Wed, Nov 06, 2024 at 02:19:38PM -0800, Matthew Maurer wrote:
> >
> > > If booted against an old kernel, it will
> > > behave as though there is no modversions information.
> >
> > Huh? This I don't get. If you have the new libkmod and boot
> > an
On Wed, Nov 6, 2024 at 10:27 PM Lucas De Marchi
wrote:
>
> On Wed, Nov 06, 2024 at 02:19:38PM -0800, Matthew Maurer wrote:
> >>
> >> > If booted against an old kernel, it will
> >> > behave as though there is no modversions information.
> >>
> &g
On Wed, Nov 06, 2024 at 02:19:38PM -0800, Matthew Maurer wrote:
> If booted against an old kernel, it will
> behave as though there is no modversions information.
Huh? This I don't get. If you have the new libkmod and boot
an old kernel, that should just not break becauase well, l
>
> > If booted against an old kernel, it will
> > behave as though there is no modversions information.
>
> Huh? This I don't get. If you have the new libkmod and boot
> an old kernel, that should just not break becauase well, long
> symbols were not ever
t; symbols, so it will fail to resolve the symbol and fail the load
> regardless.
Thanks for checking all this. It is exactly what I was looking for.
All this should be part of the cover letter and Kconfig documentation.
> If we add and enable NO_BASIC_MODVERSIONS like you suggested above,
&
hese
symbols, so it will fail to resolve the symbol and fail the load
regardless.
If we add and enable NO_BASIC_MODVERSIONS like you suggested above,
today's --show-modversions will claim there is no modversions data.
Applying a libkmod patch will result in modversions info being
displayed b
On Thu, Oct 31, 2024 at 01:00:28PM -0700, Matthew Maurer wrote:
> > The question is, if only extended moversions are used, what new tooling
> > requirements are there? Can you test using only extended modversions?
> >
> > Luis
>
> I'm not sure precisely what you're asking for. Do you want:
> 1.
> The question is, if only extended moversions are used, what new tooling
> requirements are there? Can you test using only extended modversions?
>
> Luis
I'm not sure precisely what you're asking for. Do you want:
1. A kconfig that suppresses the emission of today's MODVERSIONS
format? This wou
On Wed, Oct 30, 2024 at 11:05:03PM +, Matthew Maurer wrote:
> diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig
> index
> e6b2427e5c190aacf7b9c5c1bb57fca39d311564..a31c617cd67d3d66b24d2fba34cbd5cc9c53ab78
> 100644
> --- a/kernel/module/Kconfig
> +++ b/kernel/module/Kconfig
> @@ -208,
Generate both the existing modversions format and the new extended one
when running modpost. Presence of this metadata in the final .ko is
guarded by CONFIG_EXTENDED_MODVERSIONS.
We no longer generate an error on long symbols in modpost if
CONFIG_EXTENDED_MODVERSIONS is set, as they can now be app
On Wed, Oct 23, 2024 at 02:31:29AM +, Matthew Maurer wrote:
> Generate both the existing modversions format and the new extended one
> when running modpost. Presence of this metadata in the final .ko is
> guarded by CONFIG_EXTENDED_MODVERSIONS.
>
> We no longer generate an error on long symbol
Generate both the existing modversions format and the new extended one
when running modpost. Presence of this metadata in the final .ko is
guarded by CONFIG_EXTENDED_MODVERSIONS.
We no longer generate an error on long symbols in modpost if
CONFIG_EXTENDED_MODVERSIONS is set, as they can now be app
On Tue, Oct 15, 2024 at 11:18:59PM +, Matthew Maurer wrote:
> Generate both the existing modversions format and the new extended one
> when running modpost. Presence of this metadata in the final .ko is
> guarded by CONFIG_EXTENDED_MODVERSIONS.
>
> We no longer generate an error on long symbol
On Tue, Oct 15, 2024 at 11:18:59PM +, Matthew Maurer wrote:
> Generate both the existing modversions format and the new extended one
> when running modpost. Presence of this metadata in the final .ko is
> guarded by CONFIG_EXTENDED_MODVERSIONS.
>
> We no longer generate an error on long symbol
Hi Matt,
On Tue, Oct 15, 2024 at 4:19 PM Matthew Maurer wrote:
>
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index 107393a8c48a..d18ff8a1109a 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -1840,15 +1840,56 @@ static void add_versions(struct buffer *b,
Generate both the existing modversions format and the new extended one
when running modpost. Presence of this metadata in the final .ko is
guarded by CONFIG_EXTENDED_MODVERSIONS.
We no longer generate an error on long symbols in modpost if
CONFIG_EXTENDED_MODVERSIONS is set, as they can now be app
Generate both the existing modversions format and the new extended one
when running modpost.
We no longer generate an error on long symbols in modpost, as they can
now be appropriately encoded in the extended section. These symbols will
be skipped in the previous encoding.
Signed-off-by: Matthew
On 5/09/2024 8:08 pm, Aaron Lu wrote:
For optimized performance, firmware typically distributes EPC sections
evenly across different NUMA nodes. However, there are scenarios where
a node may have both CPUs and memory but no EPC section configured. For
example, in an 8-socket system with a Sub-
On 9/5/24 07:24, Jarkko Sakkinen wrote:
>> +for_each_online_node(nid) {
>> +if (!node_isset(nid, sgx_numa_mask) &&
>> +node_state(nid, N_MEMORY) && node_state(nid, N_CPU))
>> +pr_info("node%d has both CPUs and memory but doesn't
>> have an EPC se
On Thu Sep 5, 2024 at 11:08 AM EEST, Aaron Lu wrote:
> For optimized performance, firmware typically distributes EPC sections
> evenly across different NUMA nodes. However, there are scenarios where
> a node may have both CPUs and memory but no EPC section configured. For
> example, in an 8-socket
For optimized performance, firmware typically distributes EPC sections
evenly across different NUMA nodes. However, there are scenarios where
a node may have both CPUs and memory but no EPC section configured. For
example, in an 8-socket system with a Sub-Numa-Cluster=2 setup, there
are a total of
On Mon, Sep 2, 2024 at 2:56 AM Thomas Weißschuh wrote:
>
> Various information about modules is compiled into the info sections.
> For that a dedicated .mod.c file is generated by modpost for each module
> and then linked into the module.
> However most of the information in th
Various information about modules is compiled into the info sections.
For that a dedicated .mod.c file is generated by modpost for each module
and then linked into the module.
However most of the information in the .mod.c is the same for all
modules, internal and external.
Split the shared
On Wed, Jun 19, 2024 at 08:30:37AM +, Yusong Gao wrote:
> Add log information in kernel-space when loading module failures.
> Try to load the unsigned module and the module with bad signature
> when set 1 to /sys/module/module/parameters/sig_enforce.
>
> Unsigned module case:
&
Add log information in kernel-space when loading module failures.
Try to load the unsigned module and the module with bad signature
when set 1 to /sys/module/module/parameters/sig_enforce.
Unsigned module case:
(linux) insmod unsigned.ko
[ 18.714661] Loading of unsigned module is rejected
On 6/19/24 02:54, Luis Chamberlain wrote:
On Fri, Jun 14, 2024 at 09:25:19AM +, Yusong Gao wrote:
Add log information in kernel-space when loading module failures.
Try to load the unsigned module and the module with bad signature
when set 1 to /sys/module/module/parameters/sig_enforce
On Fri, Jun 14, 2024 at 09:25:19AM +, Yusong Gao wrote:
> Add log information in kernel-space when loading module failures.
> Try to load the unsigned module and the module with bad signature
> when set 1 to /sys/module/module/parameters/sig_enforce.
>
> Unsigned module case:
&
Add log information in kernel-space when loading module failures.
Try to load the unsigned module and the module with bad signature
when set 1 to /sys/module/module/parameters/sig_enforce.
Unsigned module case:
(linux) insmod unsigned.ko
[ 18.714661] Loading of unsigned module is rejected
On 4/3/24 12:46, Pavel Machek wrote:
> Hi!
>
>> Libcamera requires the cropping information for each mode, so
>> add this information to the driver.
>
>> @@ -116,6 +124,9 @@ struct imx258_mode {
>> u32 link_freq_index;
>> /* Default register v
On 4/3/24 12:46, Pavel Machek wrote:
> Hi!
>
>> Libcamera requires the cropping information for each mode, so
>> add this information to the driver.
>
>> @@ -116,6 +124,9 @@ struct imx258_mode {
>> u32 link_freq_index;
>> /* Default register v
it is a very minor fix, I think it can be applied
在 2024/3/11 下午4:21, Xianting Tian 写道:
Guest moved avail idx not used idx when we need to print log if
'(vq->avail_idx - last_avail_idx) > vq->num', so fix it.
Signed-off-by: Xianting Tian
---
drivers/vhost/vhost.c | 2 +-
1 file changed, 1 i
Guest moved avail idx not used idx when we need to print log if
'(vq->avail_idx - last_avail_idx) > vq->num', so fix it.
Signed-off-by: Xianting Tian
---
drivers/vhost/vhost.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index
me that if the payload is larger than a trace entry, that
it is a trace entry. As trace entries have the interrupt context
information saved in a flags field, look at that location and report the
output of the flags.
If the payload is not a trace entry, there's no way to really know, and
the i
On Mon, 18 Dec 2023 17:01:06 -0500
Steven Rostedt wrote:
> @@ -3347,7 +3418,8 @@ static void check_buffer(struct ring_buffer_per_cpu
> *cpu_buffer,
> }
> }
> if ((full && ts > info->ts) ||
> - (!full && ts + info->delta != info->ts)) {
> + (!full && ts +
me that if the payload is larger than a trace entry, that
it is a trace entry. As trace entries have the interrupt context
information saved in a flags field, look at that location and report the
output of the flags.
If the payload is not a trace entry, there's no way to really know, and
the i
me that if the payload is larger than a trace entry, that
it is a trace entry. As trace entries have the interrupt context
information saved in a flags field, look at that location and report the
output of the flags.
If the payload is not a trace entry, there's no way to really know, and
the i
* desc_reopen_last() checked the caller_info, but there was no
* exclusive access at that point. The descriptor may have
* changed since then.
*/
- if (caller_id != info->caller_id)
+ if (!match(ci, &info->caller_info)
goto fail;
> + return in_task() ? task_pid_nr(current) | (smp_processor_id() <<
> CPU_ID_SHIFT) :
There are contexts and CONFIG options around pre-emption where
smp_processor_id()
will throw a warning. Use raw_smp_processor_id().
-Tony
On Fri, Sep 15, 2023 at 04:46:02PM +0800, Enlin Mu wrote:
> John Ogness 于2023年9月15日周五 16:34写道：
> >
> > On 2023-09-15, Enlin Mu wrote:
> > > Sometimes we want to print cpu id of printk() messages to consoles
> > >
> > > diff --git a/include/linux/threads.h b/include/linux/threads.h
> > > index c34
On Fri, Sep 15, 2023 at 03:40:34PM +0800, Enlin Mu wrote:
> From: Enlin Mu
>
> Sometimes we want to print cpu id of printk() messages to consoles
This is rejected every few years. What has changes from the previous
times this was sent?
And why can't you use trace_printk()?
thanks,
greg k-h
John Ogness 于2023年9月15日周五 16:34写道：
>
> On 2023-09-15, Enlin Mu wrote:
> > Sometimes we want to print cpu id of printk() messages to consoles
> >
> > diff --git a/include/linux/threads.h b/include/linux/threads.h
> > index c34173e6c5f1..6700bd9a174f 100644
> > --- a/include/linux/threads.h
> > +++
On 2023-09-15, Enlin Mu wrote:
> Sometimes we want to print cpu id of printk() messages to consoles
>
> diff --git a/include/linux/threads.h b/include/linux/threads.h
> index c34173e6c5f1..6700bd9a174f 100644
> --- a/include/linux/threads.h
> +++ b/include/linux/threads.h
> @@ -34,6 +34,9 @@
> #d
From: Enlin Mu
Sometimes we want to print cpu id of printk() messages to consoles
Signed-off-by: Enlin Mu
---
include/linux/threads.h | 3 +++
kernel/printk/printk.c | 18 +-
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/include/linux/threads.h b/include/lin
I'll take a look. Generally if you want my attention you
should CC me on the patch.
Sorry for that! Did not notice the entire Cc list earlier.
Best regards,
Pankaj
On Wed, Dec 07, 2022 at 05:09:42AM +0100, Gupta, Pankaj wrote:
> +Cc [MST, virtualization-list]
>
> Hi Dan, MST,
>
> > This patch is reviewed and tested. Is there anything that needs to be
> > done from my side (e.g. sync with mainline)?
>
> If there are no further comments, Can we please merge
+Cc [MST, virtualization-list]
Hi Dan, MST,
This patch is reviewed and tested. Is there anything that needs to be
done from my side (e.g. sync with mainline)?
If there are no further comments, Can we please merge this patch?
Thank You,
Pankaj
(Adding my alternative email address to this t
This patch is reviewed and tested. Is there anything that needs to be
done from my side (e.g. sync with mainline)?
(Adding my alternative email address to this thread as I will soon
lose access to the address I am sending this email from.)
> > > > > > > > Compute the numa information for a virtio_pmem device from the
> > > > > > > > memory
> > > > > > > > range of the device. Previously, the target_node was always 0
> > > > > &
Compute the numa information for a virtio_pmem device from the memory
range of the device. Previously, the target_node was always 0 since
the ndr_desc.target_node field was never explicitly set. The code for
computing the numa node is taken from cxl_pmem_region_probe in
drivers/cxl/pmem.c.
Signed
On Sun, Nov 13, 2022 at 9:44 AM Pankaj Gupta
wrote:
>
> > > Pankaj Gupta wrote:
> > > > > > > Compute the numa information for a virtio_pmem device from the
> > > > > > > memory
> > > > > > > range of the device. Prev
> > Pankaj Gupta wrote:
> > > > > > Compute the numa information for a virtio_pmem device from the
> > > > > > memory
> > > > > > range of the device. Previously, the target_node was always 0 since
> > > > > > the
On Wed, Oct 26, 2022 at 2:50 PM Dan Williams wrote:
>
> Pankaj Gupta wrote:
> > > > > Compute the numa information for a virtio_pmem device from the memory
> > > > > range of the device. Previously, the target_node was always 0 since
> > > > >
Pankaj Gupta wrote:
> > > > Compute the numa information for a virtio_pmem device from the memory
> > > > range of the device. Previously, the target_node was always 0 since
> > > > the ndr_desc.target_node field was never explicitly set. The code for
> >
On Mon, Oct 17, 2022 at 1:11 PM Michael Sammler wrote:
>
> Compute the numa information for a virtio_pmem device from the memory
> range of the device. Previously, the target_node was always 0 since
> the ndr_desc.target_node field was never explicitly set. The code for
> computin
1 - 100 of 3477 matches
Mail list logo
