* [PATCH ndctl] libcxl: don't calculate max_available_extent when start == ULLONG_MAX [not found] <CGME20231006170340uscas1p1cb7a65c371984266b3fe06ffce9d7d55@uscas1p1.samsung.com> @ 2023-10-06 17:03 ` Jim Harris 2023-10-06 17:09 ` Jim Harris 0 siblings, 1 reply; 3+ messages in thread From: Jim Harris @ 2023-10-06 17:03 UTC (permalink / raw) To: linux-cxl@vger.kernel.org `cxl list` can be run as non-root, but some sysfs entries such as decoderX.Y/start are only root-readable. In this case, decoder->start gets set to ULLONG_MAX and cxl_decoder_max_available_extent() would try to calculate a size based on the value. This would result in a value slightly less than ULLONG_MAX which would emit odd (and obviously incorrect) values for max_available_extent. If we just return ULLONG_MAX in this case, the max_available_extent is not emitted which is the desirable behavior in this case. If users need the value, they can run `cxl list` as root. Signed-off-by: Jim Harris <jim.harris@samsung.com> --- cxl/lib/libcxl.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/cxl/lib/libcxl.c b/cxl/lib/libcxl.c index af4ca44..eb9ccf1 100644 --- a/cxl/lib/libcxl.c +++ b/cxl/lib/libcxl.c @@ -2002,6 +2002,9 @@ cxl_decoder_calc_max_available_extent(struct cxl_decoder *decoder) return ULLONG_MAX; } + if (decoder->start == ULLONG_MAX) + return ULLONG_MAX; + /* * Preload prev_end with an imaginary region that ends just before * the decoder's start, so that the extent calculation for the ^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH ndctl] libcxl: don't calculate max_available_extent when start == ULLONG_MAX 2023-10-06 17:03 ` [PATCH ndctl] libcxl: don't calculate max_available_extent when start == ULLONG_MAX Jim Harris @ 2023-10-06 17:09 ` Jim Harris 2023-10-06 17:19 ` Verma, Vishal L 0 siblings, 1 reply; 3+ messages in thread From: Jim Harris @ 2023-10-06 17:09 UTC (permalink / raw) To: Jim Harris; +Cc: linux-cxl@vger.kernel.org I see I should have sent “ndctl" as a prefix instead of version. Let me know if a should send a v2 with the corrected, otherwise I’ll use the prefix next time around. > On Oct 6, 2023, at 10:03 AM, Jim Harris <jim.harris@samsung.com> wrote: ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH ndctl] libcxl: don't calculate max_available_extent when start == ULLONG_MAX 2023-10-06 17:09 ` Jim Harris @ 2023-10-06 17:19 ` Verma, Vishal L 0 siblings, 0 replies; 3+ messages in thread From: Verma, Vishal L @ 2023-10-06 17:19 UTC (permalink / raw) To: jim.harris@samsung.com; +Cc: linux-cxl@vger.kernel.org On Fri, 2023-10-06 at 17:09 +0000, Jim Harris wrote: > I see I should have sent “ndctl" as a prefix instead of version. Let me know if > a should send a v2 with the corrected, otherwise I’ll use the prefix next time > around. Hi Jim, No worries, and no need for a resend - in fact b4-send's prefix handling also does the same thing - "PATCH ndctl". In pre-b4 days "ndctl PATCH" was indeed the norm, but I'd rather use b4 and live with the former, so this is completely fine! ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-10-06 17:20 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CGME20231006170340uscas1p1cb7a65c371984266b3fe06ffce9d7d55@uscas1p1.samsung.com>
2023-10-06 17:03 ` [PATCH ndctl] libcxl: don't calculate max_available_extent when start == ULLONG_MAX Jim Harris
2023-10-06 17:09 ` Jim Harris
2023-10-06 17:19 ` Verma, Vishal L
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox