All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Szyprowski <m.szyprowski@samsung.com>
To: "'Hiroshi Doyu'" <hdoyu@nvidia.com>
Cc: pullip.cho@samsung.com, linux-arm-kernel@lists.infradead.org,
	linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, kyungmin.park@samsung.com,
	arnd@arndb.de, linux@arm.linux.org.uk, chunsang.jeong@linaro.org,
	"'Krishna Reddy'" <vdumpa@nvidia.com>,
	konrad.wilk@oracle.com, subashrp@gmail.com, minchan@kernel.org
Subject: RE: [RFC 2/4] ARM: dma-mapping: IOMMU allocates pages from pool with GFP_ATOMIC
Date: Thu, 23 Aug 2012 09:52:07 +0200	[thread overview]
Message-ID: <014501cd8104$35a8ce40$a0fa6ac0$%szyprowski@samsung.com> (raw)
In-Reply-To: <20120823091519.804aeae4ba93bcfe011e787c@nvidia.com>

Hi Hiroshi,

On Thursday, August 23, 2012 8:15 AM Hiroshi Doyu wrote:

> On Thu, 23 Aug 2012 07:58:34 +0200
> Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> 
> > Hello,
> >
> > On Wednesday, August 22, 2012 3:37 PM Hiroshi Doyu wrote:
> >
> > > KyongHo Cho <pullip.cho@samsung.com> wrote @ Wed, 22 Aug 2012 14:47:00 +0200:
> > >
> > > > vzalloc() call in __iommu_alloc_buffer() also causes BUG() in atomic context.
> > >
> > > Right.
> > >
> > > I've been thinking that kzalloc() may be enough here, since
> > > vzalloc() was introduced to avoid allocation failure for big chunk of
> > > memory, but I think that it's unlikely that the number of page array
> > > can be so big. So I propose to drop vzalloc() here, and just simply to
> > > use kzalloc only as below(*1).
> >
> > We already had a discussion about this, so I don't think it makes much sense to
> > change it back to kzalloc. This vmalloc() call won't hurt anyone. It should not
> > be considered a problem for atomic allocations, because no sane driver will try
> > to allocate buffers larger than a dozen KiB with GFP_ATOMIC flag. I would call
> > such try a serious bug, which we should not care here.
> 
> Ok, I've already sent v2 just now, where, instead of changing it back,
> just with GFP_ATOMIC, kzalloc() would be selected, just in case. I guess
> that this would be ok(a bit safer?)

I've posted some comments to v2. If you agree with my suggestion, no changes around
those vmalloc() calls will be needed.

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center




WARNING: multiple messages have this Message-ID (diff)
From: Marek Szyprowski <m.szyprowski@samsung.com>
To: 'Hiroshi Doyu' <hdoyu@nvidia.com>
Cc: pullip.cho@samsung.com, linux-arm-kernel@lists.infradead.org,
	linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, kyungmin.park@samsung.com,
	arnd@arndb.de, linux@arm.linux.org.uk, chunsang.jeong@linaro.org,
	'Krishna Reddy' <vdumpa@nvidia.com>,
	konrad.wilk@oracle.com, subashrp@gmail.com, minchan@kernel.org
Subject: RE: [RFC 2/4] ARM: dma-mapping: IOMMU allocates pages from pool with GFP_ATOMIC
Date: Thu, 23 Aug 2012 09:52:07 +0200	[thread overview]
Message-ID: <014501cd8104$35a8ce40$a0fa6ac0$%szyprowski@samsung.com> (raw)
In-Reply-To: <20120823091519.804aeae4ba93bcfe011e787c@nvidia.com>

Hi Hiroshi,

On Thursday, August 23, 2012 8:15 AM Hiroshi Doyu wrote:

> On Thu, 23 Aug 2012 07:58:34 +0200
> Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> 
> > Hello,
> >
> > On Wednesday, August 22, 2012 3:37 PM Hiroshi Doyu wrote:
> >
> > > KyongHo Cho <pullip.cho@samsung.com> wrote @ Wed, 22 Aug 2012 14:47:00 +0200:
> > >
> > > > vzalloc() call in __iommu_alloc_buffer() also causes BUG() in atomic context.
> > >
> > > Right.
> > >
> > > I've been thinking that kzalloc() may be enough here, since
> > > vzalloc() was introduced to avoid allocation failure for big chunk of
> > > memory, but I think that it's unlikely that the number of page array
> > > can be so big. So I propose to drop vzalloc() here, and just simply to
> > > use kzalloc only as below(*1).
> >
> > We already had a discussion about this, so I don't think it makes much sense to
> > change it back to kzalloc. This vmalloc() call won't hurt anyone. It should not
> > be considered a problem for atomic allocations, because no sane driver will try
> > to allocate buffers larger than a dozen KiB with GFP_ATOMIC flag. I would call
> > such try a serious bug, which we should not care here.
> 
> Ok, I've already sent v2 just now, where, instead of changing it back,
> just with GFP_ATOMIC, kzalloc() would be selected, just in case. I guess
> that this would be ok(a bit safer?)

I've posted some comments to v2. If you agree with my suggestion, no changes around
those vmalloc() calls will be needed.

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: m.szyprowski@samsung.com (Marek Szyprowski)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 2/4] ARM: dma-mapping: IOMMU allocates pages from pool with GFP_ATOMIC
Date: Thu, 23 Aug 2012 09:52:07 +0200	[thread overview]
Message-ID: <014501cd8104$35a8ce40$a0fa6ac0$%szyprowski@samsung.com> (raw)
In-Reply-To: <20120823091519.804aeae4ba93bcfe011e787c@nvidia.com>

Hi Hiroshi,

On Thursday, August 23, 2012 8:15 AM Hiroshi Doyu wrote:

> On Thu, 23 Aug 2012 07:58:34 +0200
> Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> 
> > Hello,
> >
> > On Wednesday, August 22, 2012 3:37 PM Hiroshi Doyu wrote:
> >
> > > KyongHo Cho <pullip.cho@samsung.com> wrote @ Wed, 22 Aug 2012 14:47:00 +0200:
> > >
> > > > vzalloc() call in __iommu_alloc_buffer() also causes BUG() in atomic context.
> > >
> > > Right.
> > >
> > > I've been thinking that kzalloc() may be enough here, since
> > > vzalloc() was introduced to avoid allocation failure for big chunk of
> > > memory, but I think that it's unlikely that the number of page array
> > > can be so big. So I propose to drop vzalloc() here, and just simply to
> > > use kzalloc only as below(*1).
> >
> > We already had a discussion about this, so I don't think it makes much sense to
> > change it back to kzalloc. This vmalloc() call won't hurt anyone. It should not
> > be considered a problem for atomic allocations, because no sane driver will try
> > to allocate buffers larger than a dozen KiB with GFP_ATOMIC flag. I would call
> > such try a serious bug, which we should not care here.
> 
> Ok, I've already sent v2 just now, where, instead of changing it back,
> just with GFP_ATOMIC, kzalloc() would be selected, just in case. I guess
> that this would be ok(a bit safer?)

I've posted some comments to v2. If you agree with my suggestion, no changes around
those vmalloc() calls will be needed.

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center

  reply	other threads:[~2012-08-23  7:52 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-22 10:20 [RFC 0/4] ARM: dma-mapping: IOMMU atomic allocation Hiroshi Doyu
2012-08-22 10:20 ` Hiroshi Doyu
2012-08-22 10:20 ` Hiroshi Doyu
2012-08-22 10:20 ` [RFC 1/4] ARM: dma-mapping: Refactor out to introduce __alloc_fill_pages Hiroshi Doyu
2012-08-22 10:20   ` Hiroshi Doyu
2012-08-22 10:20   ` Hiroshi Doyu
2012-08-22 10:20 ` [RFC 2/4] ARM: dma-mapping: IOMMU allocates pages from pool with GFP_ATOMIC Hiroshi Doyu
2012-08-22 10:20   ` Hiroshi Doyu
2012-08-22 10:20   ` Hiroshi Doyu
2012-08-22 12:29   ` Marek Szyprowski
2012-08-22 12:29     ` Marek Szyprowski
2012-08-22 12:29     ` Marek Szyprowski
2012-08-22 12:52     ` Hiroshi Doyu
2012-08-22 12:52       ` Hiroshi Doyu
2012-08-22 12:52       ` Hiroshi Doyu
2012-08-22 12:47   ` KyongHo Cho
2012-08-22 12:47     ` KyongHo Cho
2012-08-22 13:36     ` Hiroshi Doyu
2012-08-22 13:36       ` Hiroshi Doyu
2012-08-22 13:36       ` Hiroshi Doyu
2012-08-23  3:49       ` Minchan Kim
2012-08-23  3:49         ` Minchan Kim
2012-08-23  3:49         ` Minchan Kim
2012-08-23  3:57       ` KyongHo Cho
2012-08-23  3:57         ` KyongHo Cho
2012-08-23  5:58       ` Marek Szyprowski
2012-08-23  5:58         ` Marek Szyprowski
2012-08-23  5:58         ` Marek Szyprowski
2012-08-23  6:15         ` Hiroshi Doyu
2012-08-23  6:15           ` Hiroshi Doyu
2012-08-23  6:15           ` Hiroshi Doyu
2012-08-23  7:52           ` Marek Szyprowski [this message]
2012-08-23  7:52             ` Marek Szyprowski
2012-08-23  7:52             ` Marek Szyprowski
2012-08-22 10:20 ` [RFC 3/4] ARM: dma-mapping: Return cpu addr when dma_alloc(GFP_ATOMIC) Hiroshi Doyu
2012-08-22 10:20   ` Hiroshi Doyu
2012-08-22 10:20   ` Hiroshi Doyu
2012-08-22 10:20 ` [RFC 4/4] ARM: dma-mapping: dma_{alloc,free}_coherent with empty attrs Hiroshi Doyu
2012-08-22 10:21   ` [RFC 4/4] ARM: dma-mapping: dma_{alloc, free}_coherent " Hiroshi Doyu
2012-08-22 10:20   ` [RFC 4/4] ARM: dma-mapping: dma_{alloc,free}_coherent " Hiroshi Doyu
2012-08-22 12:04 ` [RFC 0/4] ARM: dma-mapping: IOMMU atomic allocation Marek Szyprowski
2012-08-22 12:04   ` Marek Szyprowski
2012-08-22 12:04   ` Marek Szyprowski
2012-08-22 14:44   ` Hiroshi Doyu
2012-08-22 14:44     ` Hiroshi Doyu
2012-08-22 14:44     ` Hiroshi Doyu

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='014501cd8104$35a8ce40$a0fa6ac0$%szyprowski@samsung.com' \
    --to=m.szyprowski@samsung.com \
    --cc=arnd@arndb.de \
    --cc=chunsang.jeong@linaro.org \
    --cc=hdoyu@nvidia.com \
    --cc=konrad.wilk@oracle.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux@arm.linux.org.uk \
    --cc=minchan@kernel.org \
    --cc=pullip.cho@samsung.com \
    --cc=subashrp@gmail.com \
    --cc=vdumpa@nvidia.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 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.