Linux IOMMU Development
 help / color / mirror / Atom feed
From: Nicolin Chen <nicolinc@nvidia.com>
To: Steve Sistare <steven.sistare@oracle.com>
Cc: <iommu@lists.linux.dev>, Jason Gunthorpe <jgg@nvidia.com>,
	Kevin Tian <kevin.tian@intel.com>
Subject: Re: [PATCH V2 2/9] iommufd: generalize iopt_pages address
Date: Tue, 24 Sep 2024 13:31:37 -0700	[thread overview]
Message-ID: <ZvMhqXo5MQ24xVND@Asurada-Nvidia> (raw)
In-Reply-To: <1727190338-385692-3-git-send-email-steven.sistare@oracle.com>

Hi Steve,

Some nitpickings.

On Tue, Sep 24, 2024 at 08:05:31AM -0700, Steve Sistare wrote:
> +static int iopt_map_common(struct iommufd_ctx *ictx,
> +			     struct io_pagetable *iopt,
> +                          struct iopt_pages *pages,
> +                          unsigned long *iova,
> +                          unsigned long length,
> +                          unsigned long start_byte,
> +                          int iommu_prot,
> +                          unsigned int flags)

I think we should follow the existing coding style by combining
lines that could fit within 80 characters each.

>  /**
>   * iopt_map_user_pages() - Map a user VA to an iova in the io page table
>   * @ictx: iommufd_ctx the iopt is part of
> @@ -399,29 +431,15 @@ int iopt_map_user_pages(struct iommufd_ctx *ictx, struct io_pagetable *iopt,
>                         unsigned long length, int iommu_prot,
>                         unsigned int flags)
>  {
[...]
> -       return 0;
> +       return iopt_map_common(ictx, iopt, pages, iova, length,
> +                              uptr - pages->uptr,
> +                              iommu_prot, flags);

The last line could fit into the previous one.

> +enum iopt_address_type {
> +       IOPT_ADDRESS_USER = 0,
> +};
> +
>  /*
>   * This holds a pinned page list for multiple areas of IO address space. The
>   * pages always originate from a linear chunk of userspace VA. Multiple
> @@ -195,7 +199,10 @@ struct iopt_pages {
>         struct task_struct *source_task;
>         struct mm_struct *source_mm;
>         struct user_struct *source_user;
> -       void __user *uptr;
> +       enum iopt_address_type type;
> +       union {
> +               void __user *uptr;              /* IOPT_ADDRESS_USER */
> +       };
>         bool writable:1;
>         u8 account_mode;

We only have one line in the kdoc mentioning the "address" word.
So, I personally prefer "iopt_pages_type" and "IOPT_PAGES_USER",
matching with existing functions iopt_alloc/map_user_pages also.

> +struct iopt_pages *iopt_alloc_user_pages(void __user *uptr,
> +                                        unsigned long length, bool writable)
> +{
> +       struct iopt_pages *pages;
> +       unsigned long end;
> +       void __user *uptr_down = (void __user *) ALIGN_DOWN((uintptr_t)uptr, PAGE_SIZE);

+	void __user *uptr_aligned =
+		(void __user *) ALIGN_DOWN((uintptr_t)uptr, PAGE_SIZE);
+       struct iopt_pages *pages;
+       unsigned long end;

Thanks
Nicolin

  reply	other threads:[~2024-09-24 20:32 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-24 15:05 [PATCH V2 0/9] iommu_ioas_map_file Steve Sistare
2024-09-24 15:05 ` [PATCH V2 1/9] iommufd: rename uptr in iopt_alloc_iova Steve Sistare
2024-09-27 15:59   ` Jason Gunthorpe
2024-09-24 15:05 ` [PATCH V2 2/9] iommufd: generalize iopt_pages address Steve Sistare
2024-09-24 20:31   ` Nicolin Chen [this message]
2024-09-25 22:43     ` Jason Gunthorpe
2024-09-25 23:04       ` Nicolin Chen
2024-09-26 14:48         ` Jason Gunthorpe
2024-09-26 15:48           ` Steven Sistare
2024-10-01 19:54   ` Jason Gunthorpe
2024-09-24 15:05 ` [PATCH V2 3/9] iommufd: pfn reader for file mappings Steve Sistare
2024-09-24 20:53   ` Nicolin Chen
2024-09-26 15:59     ` Steven Sistare
2024-09-25  1:32   ` kernel test robot
2024-09-25  1:55   ` kernel test robot
2024-09-26 14:10   ` Steven Sistare
2024-09-24 15:05 ` [PATCH V2 4/9] iommufd: IOMMU_IOAS_MAP_FILE interface Steve Sistare
2024-10-01 19:58   ` Jason Gunthorpe
2024-09-24 15:05 ` [PATCH V2 5/9] iommufd: IOMMU_IOAS_MAP_FILE implementation Steve Sistare
2024-09-24 21:08   ` Nicolin Chen
2024-09-26 15:50     ` Steven Sistare
2024-10-01 20:05   ` Jason Gunthorpe
2024-10-02 17:26     ` Steven Sistare
2024-09-24 15:05 ` [PATCH V2 6/9] iommufd: file mappings for mdev Steve Sistare
2024-10-01 20:09   ` Jason Gunthorpe
2024-10-02 17:26     ` Steven Sistare
2024-09-24 15:05 ` [PATCH V2 7/9] iommufd: pfn reader local variables Steve Sistare
2024-10-02 17:29   ` Steven Sistare
2024-10-04 12:16     ` Jason Gunthorpe
2024-09-24 15:05 ` [PATCH V2 8/9] iommufd: optimize file mapping Steve Sistare
2024-10-01 21:03   ` Jason Gunthorpe
2024-10-02 17:26     ` Steven Sistare
2024-10-02 17:29       ` Jason Gunthorpe
2024-10-02 17:51         ` Steven Sistare
2024-09-24 15:05 ` [PATCH V2 9/9] iommufd: map file selftest Steve Sistare
2024-10-01 21:05   ` Jason Gunthorpe
2024-10-02 17:26     ` Steven Sistare
2024-10-02 17:29       ` Jason Gunthorpe

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=ZvMhqXo5MQ24xVND@Asurada-Nvidia \
    --to=nicolinc@nvidia.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@nvidia.com \
    --cc=kevin.tian@intel.com \
    --cc=steven.sistare@oracle.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox