On Thu, Jun 19, 2025 at 11:32:58PM +0530, Brahmajit Das wrote:
> On 19.06.2025 18:03, Mark Harmstone wrote:
> > On 19/06/2025 3.06 pm, Brahmajit Das wrote:
> > > strcpy is deprecated due to lack of bounds checking. This patch replaces
> > > strcpy with strscpy, the recommended alternative for null
On Fri, Jun 20, 2025 at 07:13:44AM +0530, Brahmajit Das wrote:
> strcpy is deprecated due to lack of bounds checking. This patch replaces
> strcpy with strscpy, the recommended alternative for null terminated
> strings, to follow best practices.
>
> There are instances where strscpy cannot be used
On 20/06/2025 2.43 am, Brahmajit Das wrote:
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -215,7 +215,7 @@ void btrfs_describe_block_groups(u64 bg_flags, char *buf,
u32 size_buf)
u32 size_bp = size_buf;
if (!flags) {
- strcpy(bp, "NONE");
+ memcp
On 19.06.2025 18:03, Mark Harmstone wrote:
> On 19/06/2025 3.06 pm, Brahmajit Das wrote:
> > strcpy is deprecated due to lack of bounds checking. This patch replaces
> > strcpy with strscpy, the recommended alternative for null terminated
> > strings, to follow best practices.
>
> I think calling
On 19/06/2025 6.59 pm, Brahmajit Das wrote:
On 19.06.2025 18:06, Mark Harmstone wrote:
On 19/06/2025 4.39 pm, Brahmajit Das wrote:
...
Surely this doesn't compile... strscpy takes three parameters.
It does, the third parameter is optional. From include/linux/string.h
#define strscpy(dst, s
On 19.06.2025 18:06, Mark Harmstone wrote:
> On 19/06/2025 4.39 pm, Brahmajit Das wrote:
...
>
> Surely this doesn't compile... strscpy takes three parameters.
>
It does, the third parameter is optional. From include/linux/string.h
#define strscpy(dst, src, ...) \
CONCATENATE(__strscpy,
On 19/06/2025 4.39 pm, Brahmajit Das wrote:
strcpy is deprecated due to lack of bounds checking. This patch replaces
strcpy with strscpy, the recommended alternative for null terminated
strings, to follow best practices.
There are instances where strscpy cannot be used such as where both the
sou
On 19/06/2025 3.06 pm, Brahmajit Das wrote:
strcpy is deprecated due to lack of bounds checking. This patch replaces
strcpy with strscpy, the recommended alternative for null terminated
strings, to follow best practices.
I think calling strcpy "deprecated" is a bit tendentious. IMHO the way to
On Sat, Apr 26, 2025 at 12:55:21AM -0600, Gustavo A. R. Silva wrote:
>
>
> On 26/04/25 00:23, Kees Cook wrote:
> > In preparation for making the kmalloc family of allocators type aware,
> > we need to make sure that the returned type from the allocation matches
> > the type of the variable being
On Fri, Apr 25, 2025 at 11:23:29PM -0700, Kees Cook wrote:
> In preparation for making the kmalloc family of allocators type aware,
> we need to make sure that the returned type from the allocation matches
> the type of the variable being assigned. (Before, the allocator would
> always return "void
On 26/04/25 00:23, Kees Cook wrote:
In preparation for making the kmalloc family of allocators type aware,
we need to make sure that the returned type from the allocation matches
the type of the variable being assigned. (Before, the allocator would
always return "void *", which can be implicit
在 2025/4/26 15:53, Kees Cook 写道:
In preparation for making the kmalloc family of allocators type aware,
we need to make sure that the returned type from the allocation matches
the type of the variable being assigned. (Before, the allocator would
always return "void *", which can be implicitly
On 2025/3/12 20:05, Yunsheng Lin wrote:
On 2025/3/12 9:45, Gao Xiang wrote:
On 2025/3/12 06:55, NeilBrown wrote:
On Mon, 10 Mar 2025, Gao Xiang wrote:
- Your new api covers narrow cases compared to the existing
api, although all in-tree callers may be converted
properly,
On Mon, 10 Mar 2025, Gao Xiang wrote:
>
> - Your new api covers narrow cases compared to the existing
> api, although all in-tree callers may be converted
> properly, but it increases mental burden of all users.
> And maybe complicate future potential users again which
> really h
On Mon, 10 Mar 2025, Yunsheng Lin wrote:
> On 3/8/2025 5:02 AM, NeilBrown wrote:
>
> ...
>
> >>
> >>>allocated pages in the array - just like the current
> >>>alloc_pages_bulk().
> >>
> >> I guess 'the total number of allocated pages in the array ' include
> >> the pages which are already
On 2025/3/10 8:32, Gao Xiang wrote:
...
>>
>> Also, it seems the fstests doesn't support erofs yet?
>
> erofs is an read-only filesystem, and almost all xfstests
> cases is unsuitable for erofs since erofs needs to preset
> dataset in advance for runtime testing and only
> read-related interface
On 2025/3/10 20:31, Yunsheng Lin wrote:
On 2025/3/10 8:32, Gao Xiang wrote:
...
Also, it seems the fstests doesn't support erofs yet?
erofs is an read-only filesystem, and almost all xfstests
cases is unsuitable for erofs since erofs needs to preset
dataset in advance for runtime testing
On 2025/3/9 21:40, Yunsheng Lin wrote:
On 3/8/2025 2:43 PM, Dave Chinner wrote:
...
I tested XFS using the below cmd and testcase, testing seems
to be working fine, or am I missing something obvious here
as I am not realy familiar with fs subsystem yet:
That's hardly what I'd call a test.
On 3/8/2025 2:43 PM, Dave Chinner wrote:
...
I tested XFS using the below cmd and testcase, testing seems
to be working fine, or am I missing something obvious here
as I am not realy familiar with fs subsystem yet:
That's hardly what I'd call a test. It barely touches the filesystem
at all, a
On 3/8/2025 5:02 AM, NeilBrown wrote:
...
allocated pages in the array - just like the current
alloc_pages_bulk().
I guess 'the total number of allocated pages in the array ' include
the pages which are already in the array before calling the above
API?
Yes - just what the current f
On Tue, Mar 04, 2025 at 08:09:35PM +0800, Yunsheng Lin wrote:
> On 2025/3/4 16:18, Dave Chinner wrote:
>
> ...
>
> >
> >>
> >> 1.
> >> https://lore.kernel.org/all/bd8c2f5c-464d-44ab-b607-390a87ea4...@huawei.com/
> >> 2.
> >> https://lore.kernel.org/all/20250212092552.1779679-1-linyunsh...@huaw
.
They lends weight to the suggestion that the current return value isn't
ideal.
>
> If the new API do the page defragmentation, then it will always return
> the same value for different layout of the same number of NULL pointers.
> I guess the new one is the more perfered behavior
s it provides a more
defined semantic.
>
> sunrpc could usefully use both of these interfaces.
>
> alloc_pages_bulk() could be implemented by initialising the array and
> then calling alloc_pages_bulk_refill(). Or alloc_pages_bulk_refill()
> could be implemented by compact
pages_bulk_refill(). Or alloc_pages_bulk_refill()
could be implemented by compacting the pages and then calling
alloc_pages_bulk().
If we could duplicate the code and have two similar but different
functions.
The documentation for _refill() should make it clear that the pages
might get re-ordered.
On 2025/3/6 7:41, NeilBrown wrote:
> On Wed, 05 Mar 2025, Yunsheng Lin wrote:
>>
>> For the existing btrfs and sunrpc case, I am agreed that there
>> might be valid use cases too, we just need to discuss how to
>> meet the requirements of different use cases using simpler, more
>> unified and effec
On Wed, 05 Mar 2025, Yunsheng Lin wrote:
>
> For the existing btrfs and sunrpc case, I am agreed that there
> might be valid use cases too, we just need to discuss how to
> meet the requirements of different use cases using simpler, more
> unified and effective APIs.
We don't need "more unified".
On 2025/3/4 17:17, Qu Wenruo wrote:
>
>
> 在 2025/2/28 20:14, Yunsheng Lin 写道:
>> As mentioned in [1], it seems odd to check NULL elements in
>> the middle of page bulk allocating, and it seems caller can
>> do a better job of bulk allocating pages into a whole array
>> sequentially without checki
On 2025/3/4 16:18, Dave Chinner wrote:
...
>
>>
>> 1.
>> https://lore.kernel.org/all/bd8c2f5c-464d-44ab-b607-390a87ea4...@huawei.com/
>> 2.
>> https://lore.kernel.org/all/20250212092552.1779679-1-linyunsh...@huawei.com/
>> CC: Jesper Dangaard Brouer
>> CC: Luiz Capitulino
>> CC: Mel Gorman
On 2025/3/4 6:13, Chuck Lever wrote:
> On 2/28/25 4:44 AM, Yunsheng Lin wrote:
>> As mentioned in [1], it seems odd to check NULL elements in
>> the middle of page bulk allocating, and it seems caller can
>> do a better job of bulk allocating pages into a whole array
>> sequentially without checkin
在 2025/2/28 20:14, Yunsheng Lin 写道:
As mentioned in [1], it seems odd to check NULL elements in
the middle of page bulk allocating, and it seems caller can
do a better job of bulk allocating pages into a whole array
sequentially without checking NULL elements first before
doing the page bulk a
On Fri, Feb 28, 2025 at 05:44:20PM +0800, Yunsheng Lin wrote:
> As mentioned in [1], it seems odd to check NULL elements in
> the middle of page bulk allocating, and it seems caller can
> do a better job of bulk allocating pages into a whole array
> sequentially without checking NULL elements first
On 2/28/25 4:44 AM, Yunsheng Lin wrote:
> As mentioned in [1], it seems odd to check NULL elements in
> the middle of page bulk allocating, and it seems caller can
> do a better job of bulk allocating pages into a whole array
> sequentially without checking NULL elements first before
> doing the pa
On Tue, Feb 25, 2025 at 08:26:14PM +0100, Thorsten Blum wrote:
> strncpy() is deprecated for NUL-terminated destination buffers. Use
> strscpy() instead and don't zero-initialize the param array.
>
> Compile-tested only.
>
> Link: https://github.com/KSPP/linux/issues/90
> Cc: linux-harden...@vger
On 25. Feb 2025, at 13:28, David Sterba wrote:
> On Tue, Feb 25, 2025 at 10:29:49AM +0100, Thorsten Blum wrote:
>> strncpy() is deprecated for NUL-terminated destination buffers. Use
>> strscpy_pad() instead and don't zero-initialize the param array.
>>
>> Compile-tested only.
>>
>> Link: https:/
On Tue, Feb 25, 2025 at 10:29:49AM +0100, Thorsten Blum wrote:
> strncpy() is deprecated for NUL-terminated destination buffers. Use
> strscpy_pad() instead and don't zero-initialize the param array.
>
> Compile-tested only.
>
> Link: https://github.com/KSPP/linux/issues/90
> Cc: linux-harden...@
On 2025/2/18 22:17, Chuck Lever wrote:
> On 2/18/25 4:16 AM, Yunsheng Lin wrote:
>> On 2025/2/17 22:20, Chuck Lever wrote:
>>> On 2/17/25 7:31 AM, Yunsheng Lin wrote:
As mentioned in [1], it seems odd to check NULL elements in
the middle of page bulk allocating,
>>>
>>> I think I requeste
On 2025/2/19 5:14, Dave Chinner wrote:
> On Tue, Feb 18, 2025 at 05:21:27PM +0800, Yunsheng Lin wrote:
>> On 2025/2/18 5:31, Dave Chinner wrote:
>>
>> ...
>>
>>> .
>>>
diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
index 15bb790359f8..9e1ce0ab9c35 100644
--- a/fs/xfs/xfs_buf.c
On Tue, Feb 18, 2025 at 05:21:27PM +0800, Yunsheng Lin wrote:
> On 2025/2/18 5:31, Dave Chinner wrote:
>
> ...
>
> > .
> >
> >> diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
> >> index 15bb790359f8..9e1ce0ab9c35 100644
> >> --- a/fs/xfs/xfs_buf.c
> >> +++ b/fs/xfs/xfs_buf.c
> >> @@ -377,1
On 2/18/25 4:16 AM, Yunsheng Lin wrote:
> On 2025/2/17 22:20, Chuck Lever wrote:
>> On 2/17/25 7:31 AM, Yunsheng Lin wrote:
>>> As mentioned in [1], it seems odd to check NULL elements in
>>> the middle of page bulk allocating,
>>
>> I think I requested that check to be added to the bulk page alloc
On 2025/2/18 5:31, Dave Chinner wrote:
...
> .
>
>> diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
>> index 15bb790359f8..9e1ce0ab9c35 100644
>> --- a/fs/xfs/xfs_buf.c
>> +++ b/fs/xfs/xfs_buf.c
>> @@ -377,16 +377,17 @@ xfs_buf_alloc_pages(
>> * least one extra page.
>> */
>>
On 2025/2/17 22:20, Chuck Lever wrote:
> On 2/17/25 7:31 AM, Yunsheng Lin wrote:
>> As mentioned in [1], it seems odd to check NULL elements in
>> the middle of page bulk allocating,
>
> I think I requested that check to be added to the bulk page allocator.
>
> When sending an RPC reply, NFSD mig
On Mon, Feb 17, 2025 at 08:31:23PM +0800, Yunsheng Lin wrote:
> As mentioned in [1], it seems odd to check NULL elements in
> the middle of page bulk allocating, and it seems caller can
> do a better job of bulk allocating pages into a whole array
> sequentially without checking NULL elements first
On 2/17/25 7:31 AM, Yunsheng Lin wrote:
> As mentioned in [1], it seems odd to check NULL elements in
> the middle of page bulk allocating,
I think I requested that check to be added to the bulk page allocator.
When sending an RPC reply, NFSD might release pages in the middle of
the rq_pages arra
On Mon, 2025-02-17 at 20:31 +0800, Yunsheng Lin wrote:
> As mentioned in [1], it seems odd to check NULL elements in
> the middle of page bulk allocating, and it seems caller can
> do a better job of bulk allocating pages into a whole array
> sequentially without checking NULL elements first before
On 11/7/24 1:58 PM, Ira Weiny wrote:
> A git tree of this series can be found here:
>
> https://github.com/weiny2/linux-kernel/tree/dcd-v4-2024-11-07
>
> This is a quick spin with minor clean ups Dave was going to apply as
> well as a couple of clean ups I had slated for after V4 landed.
On 10/30/24 7:48 AM, Jonathan Cameron wrote:
> On Tue, 29 Oct 2024 15:34:35 -0500
> Ira Weiny wrote:
>
>> A git tree of this series can be found here:
>>
>> https://github.com/weiny2/linux-kernel/tree/dcd-v4-2024-10-29
>>
>> Series info
>> ===
>>
>> This series has 4 parts:
>>
>>
On Tue, 29 Oct 2024 15:34:35 -0500
Ira Weiny wrote:
> A git tree of this series can be found here:
>
> https://github.com/weiny2/linux-kernel/tree/dcd-v4-2024-10-29
>
> Series info
> ===
>
> This series has 4 parts:
>
> Patch 1: Add core range_overlaps() function
> Patch 2-6: CX
On Thu, Oct 17, 2024 at 03:57:50PM -0500, Ira Weiny wrote:
> Bagas Sanjaya wrote:
> > On Mon, Oct 07, 2024 at 06:16:08PM -0500, Ira Weiny wrote:
> > > +Struct Range
> > > +
> > > +
> > > +::
> > > +
> > > + %pra[range 0x6000-0x6fff]
> > > + %pra[range 0x0
Jonathan Cameron wrote:
>
> > > > +EXPORT_SYMBOL_GPL(dax_region_add_resource);
> > > Adding quite a few exports. Is it time to namespace DAX exports?
> > > Perhaps a follow up series.
> >
> > Perhaps. The calls have a dax_ prefix. In addition, I thought use of the
> > export namespaces were
Jonathan Cameron wrote:
> On Mon, 07 Oct 2024 18:16:33 -0500
> Ira Weiny wrote:
>
[snip]
> >
> > Signed-off-by: Ira Weiny
> Might be worth breaking up into refactor (the static cases) and
> then new stuff.
I had it split but the rework became difficult. And this is test code so
I merged it.
On Mon, Oct 07, 2024 at 06:16:26PM -0500, Ira Weiny wrote:
> 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 ad
Fan Ni wrote:
> On Mon, Oct 07, 2024 at 06:16:23PM -0500, Ira Weiny wrote:
> > Dynamic Capacity Devices (DCD) require event interrupts to process
> > memory addition or removal. BIOS may have control over non-DCD event
> > processing. DCD interrupt configuration needs to be separate from
> > memo
Fan Ni wrote:
> On Mon, Oct 07, 2024 at 06:16:25PM -0500, ira.we...@intel.com wrote:
> > From: Navneet Singh
> >
[snip]
> >
> > +static int cxl_irqsetup(struct cxl_memdev_state *mds,
> > + struct cxl_event_interrupt_policy *policy,
> > + bool native_cxl)
>
On Mon, Oct 07, 2024 at 06:16:21PM -0500, Ira Weiny wrote:
> create_pmem_region_store() and create_ram_region_store() are identical
> with the exception of the region mode. With the addition of DC region
> mode this would end up being 3 copies of the same code.
>
> Refactor create_pmem_region_sto
Jonathan Cameron wrote:
> On Mon, 07 Oct 2024 18:16:34 -0500
> Ira Weiny wrote:
>
[snip]
> >
> > Signed-off-by: Ira Weiny
>
> Superficial review only.
>
> Looks fine to me but I've been reviewing too long today to be at all sure
> I'd spot if it was wrong in a subtle way. So no tag for now
Jonathan Cameron wrote:
> On Mon, 07 Oct 2024 18:16:32 -0500
> ira.we...@intel.com wrote:
>
> > From: Navneet Singh
> >
> > CXL rev 3.1 section 8.2.9.2.1 adds the Dynamic Capacity Event Records.
> > User space can use trace events for debugging of DC capacity changes.
> >
> > Add DC trace point
Jonathan Cameron wrote:
> On Mon, 07 Oct 2024 18:16:31 -0500
> ira.we...@intel.com wrote:
>
> > From: Navneet Singh
> >
[snip]
> >
> One buglet, and a request for an error message.
> With those.
> Reviewed-by: Jonathan Cameron
Thanks.
>
> > diff --git a/drivers/cxl/core/mbox.c b/drivers/c
> > > +EXPORT_SYMBOL_GPL(dax_region_add_resource);
> > Adding quite a few exports. Is it time to namespace DAX exports?
> > Perhaps a follow up series.
>
> Perhaps. The calls have a dax_ prefix. In addition, I thought use of the
> export namespaces were out of favor?
I guess I missed a ch
.e. move
> dev_set_drvdata(device, dax_resource);
> to here.
Oh boy... I probably needed a better comment on this one. No we can't do that
as written because no_free_ptr() was used to flag that the pointer was handed
off. Thus at this point dax_resource is always NULL.
That said, I
On Mon, 21 Oct 2024 09:47:49 -0700
Fan Ni wrote:
> On Mon, Oct 07, 2024 at 06:16:06PM -0500, Ira Weiny wrote:
> > A git tree of this series can be found here:
> >
> > https://github.com/weiny2/linux-kernel/tree/dcd-v4-2024-10-04
> >
> > Series info
> > ===
> >
>
> Hi Ira,
> I ha
On Mon, 21 Oct 2024 13:45:57 -0500
Ira Weiny wrote:
> Jonathan Cameron wrote:
> > On Thu, 17 Oct 2024 16:39:57 -0500
> > Ira Weiny wrote:
> >
> > > Jonathan Cameron wrote:
> > > > On Mon, 07 Oct 2024 18:16:27 -0500
> > > > ira.we...@intel.com wrote:
> > > >
>
> [snip]
>
> > > > > Sim
Jonathan Cameron wrote:
> On Mon, 07 Oct 2024 18:16:29 -0500
> Ira Weiny wrote:
[snip]
> > Signed-off-by: Ira Weiny
> > ---
> > Changes:
> > [Jonathan: Fix handling of alloc]
>
> Trivial comments inline.
> Not an area I know much about, so treat this one as a 'smells ok'
> type of tag.
NP
>
Jonathan Cameron wrote:
> On Thu, 17 Oct 2024 16:39:57 -0500
> Ira Weiny wrote:
>
> > Jonathan Cameron wrote:
> > > On Mon, 07 Oct 2024 18:16:27 -0500
> > > ira.we...@intel.com wrote:
> > >
[snip]
> > > > Simplify extent tracking with the following restrictions.
> > > >
> > > > 1) F
On Mon, Oct 07, 2024 at 06:16:06PM -0500, Ira Weiny wrote:
> A git tree of this series can be found here:
>
> https://github.com/weiny2/linux-kernel/tree/dcd-v4-2024-10-04
>
> Series info
> ===
>
Hi Ira,
I have a question here for DCD.
For CXL spec 3.0 and later, the output paylo
> >
> >
> > Alternative form for what you have...
>
> Sure but lots of indentation on the common path which I have grown
> to avoid... :-/
>
> Looking at this fresh... A helper function works best.
Agreed this looks better
Jonathan
Jonathan Cameron wrote:
> On Thu, 17 Oct 2024 16:15:03 -0500
> Ira Weiny wrote:
>
> > Jonathan Cameron wrote:
> > > On Wed, 9 Oct 2024 14:49:09 -0500
> > > Ira Weiny wrote:
> > >
> > > > Li, Ming4 wrote:
> > > > > On 10/8/2024 7:16 AM, ira.we...@intel.com wrote:
> > > > > > From: Navnee
On Fri, 18 Oct 2024 13:26:14 -0500
Ira Weiny wrote:
> Jonathan Cameron wrote:
> > On Mon, 07 Oct 2024 18:16:28 -0500
> > ira.we...@intel.com wrote:
> >
> > > From: Navneet Singh
> > >
> > > Extent information can be helpful to the user to coordinate memory usage
> > > with the external orche
Jonathan Cameron wrote:
> On Mon, 07 Oct 2024 18:16:28 -0500
> ira.we...@intel.com wrote:
>
> > From: Navneet Singh
> >
> > 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 creatin
On Thu, 17 Oct 2024 16:39:57 -0500
Ira Weiny wrote:
> Jonathan Cameron wrote:
> > On Mon, 07 Oct 2024 18:16:27 -0500
> > ira.we...@intel.com wrote:
> >
> > > From: Navneet Singh
> > >
> > > A dynamic capacity device (DCD) sends events to signal the host for
> > > changes in the availability
On Thu, 17 Oct 2024 16:15:03 -0500
Ira Weiny wrote:
> Jonathan Cameron wrote:
> > On Wed, 9 Oct 2024 14:49:09 -0500
> > Ira Weiny wrote:
> >
> > > Li, Ming4 wrote:
> > > > On 10/8/2024 7:16 AM, ira.we...@intel.com wrote:
> > > > > From: Navneet Singh
> > > > >
>
> [snip]
>
> > >
Jonathan Cameron wrote:
> On Mon, 07 Oct 2024 18:16:27 -0500
> ira.we...@intel.com wrote:
>
> > From: Navneet Singh
> >
> > A dynamic capacity device (DCD) sends events to signal the host for
> > changes in the availability of Dynamic Capacity (DC) memory. These
> > events contain extents descr
Jonathan Cameron wrote:
> On Wed, 9 Oct 2024 14:49:09 -0500
> Ira Weiny wrote:
>
> > Li, Ming4 wrote:
> > > On 10/8/2024 7:16 AM, ira.we...@intel.com wrote:
> > > > From: Navneet Singh
> > > >
[snip]
> >
> > > > +static int cxl_send_dc_response(struct cxl_memdev_state *mds, int
> > > > o
Bagas Sanjaya wrote:
> On Mon, Oct 07, 2024 at 06:16:08PM -0500, Ira Weiny wrote:
> > +Struct Range
> > +
> > +
> > +::
> > +
> > + %pra[range 0x6000-0x6fff]
> > + %pra[range 0x6000]
> > +
> > +For printing struct range. struct range hold
Jonathan Cameron wrote:
> On Mon, 07 Oct 2024 18:16:21 -0500
> Ira Weiny wrote:
>
> > create_pmem_region_store() and create_ram_region_store() are identical
> > with the exception of the region mode. With the addition of DC region
> > mode this would end up being 3 copies of the same code.
> >
Jonathan Cameron wrote:
> On Mon, 07 Oct 2024 18:16:20 -0500
> ira.we...@intel.com wrote:
>
> > From: Navneet Singh
> >
> > Endpoint decoder mode is used to represent the partition the decoder
> > points to such as ram or pmem.
> >
> > Expand the mode to allow a decoder to point to a specific D
Jonathan Cameron wrote:
> On Mon, 07 Oct 2024 18:16:19 -0500
> ira.we...@intel.com wrote:
>
> > From: Navneet Singh
> >
> > To properly configure CXL regions on Dynamic Capacity Devices (DCD),
> > user space will need to know the details of the DC partitions available.
> >
> > Expose dynamic ca
On Wed, Oct 16, 2024 at 04:54:15PM +0100, Jonathan Cameron wrote:
> On Sun, 13 Oct 2024 19:05:11 -0500
> Ira Weiny wrote:
>
> > Jonathan Cameron wrote:
> > > On Mon, 07 Oct 2024 18:16:14 -0500
> > > ira.we...@intel.com wrote:
> > >
> > > > From: Navneet Singh
> > > >
> > > > Devices which op
On Sun, 13 Oct 2024 19:05:11 -0500
Ira Weiny wrote:
> Jonathan Cameron wrote:
> > On Mon, 07 Oct 2024 18:16:14 -0500
> > ira.we...@intel.com wrote:
> >
> > > From: Navneet Singh
> > >
> > > Devices which optionally support Dynamic Capacity (DC) are configured
> > > via mailbox commands. CXL
On Fri, 11 Oct 2024 15:40:58 -0500
Ira Weiny wrote:
> Jonathan Cameron wrote:
> > On Mon, 07 Oct 2024 18:16:11 -0500
> > Ira Weiny wrote:
> >
> > > The device DAX structure is being enhanced to track additional DCD
> > > information.
> > >
> > > The current range tuple was not fully document
On 10/11/2024 10:38 PM, Ira Weiny wrote:
Rafael J. Wysocki wrote:
On Tue, Oct 8, 2024 at 1:17 AM Ira Weiny wrote:
[snip]
diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
index 199afc2cd122..387fc821703a 100644
--- a/include/acpi/actbl1.h
+++ b/include/acpi/actbl1.h
@@ -403,6 +403
On Mon, Oct 07, 2024 at 06:16:29PM -0500, Ira Weiny wrote:
> Dynamic Capacity regions must limit dev dax resources to those areas
> which have extents backing real memory. Such DAX regions are dubbed
> 'sparse' regions. In order to manage where memory is available four
> alternatives were conside
On Mon, Oct 07, 2024 at 06:16:28PM -0500, ira.we...@intel.com wrote:
> From: Navneet Singh
>
> 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.
>
Li, Ming4 wrote:
> On 10/10/2024 3:49 AM, Ira Weiny wrote:
> > Li, Ming4 wrote:
> >> On 10/8/2024 7:16 AM, ira.we...@intel.com wrote:
> >>> From: Navneet Singh
[snip]
> > This should fix it:
> >
> > diff --git a/drivers/cxl/core/mbox.c b/drivers/cxl/core/mbox.c
> > index d66beec687a0..99200274de
Fan Ni wrote:
> On Mon, Oct 07, 2024 at 06:16:19PM -0500, ira.we...@intel.com wrote:
> > From: Navneet Singh
> >
[snip]
> > +
> > +static ssize_t show_read_only_dcN(struct cxl_memdev *cxlmd, char *buf, int
> > pos)
> > +{
> > + struct cxl_memdev_state *mds = to_cxl_memdev_state(cxlmd->cxlds)
Fan Ni wrote:
> On Mon, Oct 07, 2024 at 06:16:18PM -0500, Ira Weiny wrote:
> > Additional DCD region (partition) information is contained in the DSMAS
> > CDAT tables, including performance, read only, and shareable attributes.
> >
> > Match DCD partitions with DSMAS tables and store the meta data
Andy Shevchenko wrote:
> On Wed, Oct 09, 2024 at 05:45:10PM +0300, Andy Shevchenko wrote:
> > On Tue, Oct 08, 2024 at 06:10:32PM +0200, David Sterba wrote:
> > > On Mon, Oct 07, 2024 at 06:16:10PM -0500, Ira Weiny wrote:
>
> ...
>
> > > > +static inline bool range_overlaps(struct range *r1, struc
Andy Shevchenko wrote:
> On Wed, Oct 09, 2024 at 03:30:14PM +0200, Rasmus Villemoes wrote:
>
> ...
>
> > Rather than the struct assignments, I think it's easier to read if you
> > just do
> >
> > struct range r;
> >
> > r.start = 0xc0ffee00ba5eba11;
> > r.end = r.start;
> > ...
> >
>
Jonathan Cameron wrote:
> On Mon, 07 Oct 2024 18:16:14 -0500
> ira.we...@intel.com wrote:
>
> > From: Navneet Singh
> >
> > Devices which optionally support Dynamic Capacity (DC) are configured
> > via mailbox commands. CXL 3.1 requires the host to issue the Get DC
> > Configuration command in
Jonathan Cameron wrote:
> On Mon, 07 Oct 2024 18:16:11 -0500
> Ira Weiny wrote:
>
> > The device DAX structure is being enhanced to track additional DCD
> > information.
> >
> > The current range tuple was not fully documented. Document it prior to
> > adding information for DC.
> >
> > Sugges
Rafael J. Wysocki wrote:
> On Tue, Oct 8, 2024 at 1:17 AM Ira Weiny wrote:
> >
[snip]
> > diff --git a/include/acpi/actbl1.h b/include/acpi/actbl1.h
> > index 199afc2cd122..387fc821703a 100644
> > --- a/include/acpi/actbl1.h
> > +++ b/include/acpi/actbl1.h
> > @@ -403,6 +403,8 @@ struct acpi_cda
On Thu, Oct 10, 2024 at 03:50:14PM +0100, Jonathan Cameron wrote:
> On Wed, 9 Oct 2024 14:49:09 -0500
> Ira Weiny wrote:
>
> > Li, Ming4 wrote:
> > > On 10/8/2024 7:16 AM, ira.we...@intel.com wrote:
> > > > From: Navneet Singh
> > > >
> >
> > [snip]
> >
> > > >
> > > > Signed-off-by: Navne
Rasmus Villemoes wrote:
> Ira Weiny writes:
>
> > ---
> > Documentation/core-api/printk-formats.rst | 13
> > lib/test_printf.c | 26 +++
> > lib/vsprintf.c| 55
> > +++
> > 3 files changed, 88
Petr Mladek wrote:
> On Mon 2024-10-07 18:16:07, Ira Weiny wrote:
> > The printk tests for struct resource were stubbed out. struct range
> > printing will leverage the struct resource implementation.
> >
> > To prevent regression add some basic sanity tests for struct resource.
> >
> > To: Petr
On Mon, Oct 07, 2024 at 06:16:19PM -0500, ira.we...@intel.com wrote:
> +What:/sys/bus/cxl/devices/memX/dcY/qos_class
> +Date:December, 2024
> +KernelVersion: v6.13
> +Contact: linux-...@vger.kernel.org
> +Description:
> + (RO) Dynamic Capacity (
On Mon, Oct 07, 2024 at 06:16:08PM -0500, Ira Weiny wrote:
> +Struct Range
> +
> +
> +::
> +
> + %pra[range 0x6000-0x6fff]
> + %pra[range 0x6000]
> +
> +For printing struct range. struct range holds an arbitrary range of u64
> +values
On Mon, Oct 07, 2024 at 06:16:26PM -0500, Ira Weiny wrote:
> 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 ad
On Mon, Oct 07, 2024 at 06:16:25PM -0500, ira.we...@intel.com wrote:
> From: Navneet Singh
>
> Dynamic Capacity Devices (DCD) support extent change notifications
> through the event log mechanism. The interrupt mailbox commands were
> extended in CXL 3.1 to support these notifications. Firmware
On Mon, Oct 07, 2024 at 06:16:24PM -0500, Ira Weiny wrote:
> Dynamic Capacity Devices (DCD) require event interrupts to process
> memory addition or removal. BIOS may have control over non-DCD event
> processing. DCD interrupt configuration needs to be separate from
> memory event interrupt confi
On Mon, Oct 07, 2024 at 06:16:23PM -0500, Ira Weiny wrote:
> Dynamic Capacity Devices (DCD) require event interrupts to process
> memory addition or removal. BIOS may have control over non-DCD event
> processing. DCD interrupt configuration needs to be separate from
> memory event interrupt confi
On Mon, Oct 07, 2024 at 06:16:22PM -0500, ira.we...@intel.com wrote:
> From: Navneet Singh
>
> Dynamic Capacity CXL regions must allow memory to be added or removed
> dynamically. In addition to the quantity of memory available the
> location of the memory within a DC partition is dynamic based
1 - 100 of 14455 matches
Mail list logo
