From: Christoph Hellwig <hch@lst.de>
To: Chaitanya Kulkarni <chaitanyak@nvidia.com>
Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
Geert Uytterhoeven <geert@linux-m68k.org>,
"linux-m68k@lists.linux-m68k.org"
<linux-m68k@lists.linux-m68k.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: [PATCH 2/2] block: pass a phys_addr_t to get_max_segment_size
Date: Sun, 7 Jul 2024 08:40:37 +0200 [thread overview]
Message-ID: <20240707064037.GA432@lst.de> (raw)
In-Reply-To: <6ae64d5e-bc86-4c4b-bc3a-3d72e86d0dbf@nvidia.com>
On Sat, Jul 06, 2024 at 10:37:11AM +0000, Chaitanya Kulkarni wrote:
> > - return min(mask - offset, (unsigned long)lim->max_segment_size - 1) + 1;
> > + return min_t(unsigned long, len,
> > + min(lim->seg_boundary_mask - (lim->seg_boundary_mask & paddr),
> > + (unsigned long)lim->max_segment_size - 1) + 1);
> > }
> >
>
> Looks good, is it possible to re-write last
> return min_t(..., ..., min(..., ...)) statement something like totally
> untested in [1] ?
> paddr_seg_boundry =
> lim->seg_boundary_mask - (lim->seg_boundary_mask & paddr);
> /*
> * Prevent an overflow if mask = ULONG_MAX and offset = 0 by
> adding 1
> * after having calculated the minimum.
> */
> paddr_max_seg_allowed_len = min(paddr_seg_boundry,
> (unsigned long)lim->max_segment_size -
> 1) + 1;
> return min_t(unsigned long, paddr_len, paddr_max_seg_allowed_len);
> }
What would be the point of that? It is way harder to read and longer.
But except for that we probably could.
>
>
---end quoted text---
next prev parent reply other threads:[~2024-07-07 6:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-06 7:52 add a bvec_phys helper v3 Christoph Hellwig
2024-07-06 7:52 ` [PATCH 1/2] block: add a bvec_phys helper Christoph Hellwig
2024-07-06 9:57 ` Chaitanya Kulkarni
2024-07-06 7:52 ` [PATCH 2/2] block: pass a phys_addr_t to get_max_segment_size Christoph Hellwig
2024-07-06 10:37 ` Chaitanya Kulkarni
2024-07-07 6:40 ` Christoph Hellwig [this message]
2024-07-09 12:39 ` Geert Uytterhoeven
2024-07-10 5:52 ` Christoph Hellwig
2024-07-10 7:08 ` Geert Uytterhoeven
2024-07-08 7:52 ` add a bvec_phys helper v3 Jens Axboe
-- strict thread matches above, loose matches on Subject: below --
2024-07-05 12:32 add a bvec_phys helper v2 Christoph Hellwig
2024-07-05 12:32 ` [PATCH 2/2] block: pass a phys_addr_t to get_max_segment_size Christoph Hellwig
2024-07-06 6:21 ` Jens Axboe
2024-07-06 6:22 ` Christoph Hellwig
2024-07-06 6:24 ` Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240707064037.GA432@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=chaitanyak@nvidia.com \
--cc=geert@linux-m68k.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.