From: Joerg Roedel <joro@8bytes.org>
To: Minchan Kim <minchan.kim@lge.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH] staging: zsmalloc: Fix link error on ARM
Date: Wed, 27 Mar 2013 01:23:57 +0100 [thread overview]
Message-ID: <20130327002357.GG30540@8bytes.org> (raw)
In-Reply-To: <20130327000552.GA13283@blaptop>
On Wed, Mar 27, 2013 at 09:05:52AM +0900, Minchan Kim wrote:
> Oops, it was my fault. When I tested [1] on CONFIG_SMP machine on ARM,
> it worked well. It means it's not always problem on every CONFIG_SMP
> on ARM machine but some SMP machine define flush_tlb_kernel_range,
> others don't.
>
> At that time, Russell King already suggested same thing with your patch
> and I meant to clean it up because the patch was already merged but I didn't.
> Because we didn't catch up that it breaks build on some configuration
> so I thought it's just clean up patch and Greg didn't want to accept
> NOT-BUG patch of any z* family.
>
> Now, it's BUG patch.
>
> Remained problem is that Greg doesn't want to export core function for
> staging driver and it's reasonable for me.
Okay, I see. So that is probably also the reason for the
reimplementation of unmap_kernel_range in the zsmalloc module :)
> So my opinion is remove zsmalloc module build and could recover it with
> making unmap_kernel_range exported function after we merged it into
> mainline.
Sounds reasonable, I update the patch to only allow zsmalloc to be
built-in. The benefit is that this still allows to use
unmap_kernel_range() in the driver.
Thanks,
Joerg
--
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: Joerg Roedel <joro@8bytes.org>
To: Minchan Kim <minchan.kim@lge.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH] staging: zsmalloc: Fix link error on ARM
Date: Wed, 27 Mar 2013 01:23:57 +0100 [thread overview]
Message-ID: <20130327002357.GG30540@8bytes.org> (raw)
In-Reply-To: <20130327000552.GA13283@blaptop>
On Wed, Mar 27, 2013 at 09:05:52AM +0900, Minchan Kim wrote:
> Oops, it was my fault. When I tested [1] on CONFIG_SMP machine on ARM,
> it worked well. It means it's not always problem on every CONFIG_SMP
> on ARM machine but some SMP machine define flush_tlb_kernel_range,
> others don't.
>
> At that time, Russell King already suggested same thing with your patch
> and I meant to clean it up because the patch was already merged but I didn't.
> Because we didn't catch up that it breaks build on some configuration
> so I thought it's just clean up patch and Greg didn't want to accept
> NOT-BUG patch of any z* family.
>
> Now, it's BUG patch.
>
> Remained problem is that Greg doesn't want to export core function for
> staging driver and it's reasonable for me.
Okay, I see. So that is probably also the reason for the
reimplementation of unmap_kernel_range in the zsmalloc module :)
> So my opinion is remove zsmalloc module build and could recover it with
> making unmap_kernel_range exported function after we merged it into
> mainline.
Sounds reasonable, I update the patch to only allow zsmalloc to be
built-in. The benefit is that this still allows to use
unmap_kernel_range() in the driver.
Thanks,
Joerg
next prev parent reply other threads:[~2013-03-27 0:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-26 22:33 [PATCH] staging: zsmalloc: Fix link error on ARM Joerg Roedel
2013-03-26 22:33 ` Joerg Roedel
2013-03-26 22:45 ` Greg Kroah-Hartman
2013-03-26 22:45 ` Greg Kroah-Hartman
2013-03-26 23:03 ` Joerg Roedel
2013-03-26 23:03 ` Joerg Roedel
2013-03-26 23:09 ` Greg Kroah-Hartman
2013-03-26 23:09 ` Greg Kroah-Hartman
2013-03-26 23:19 ` Joerg Roedel
2013-03-26 23:19 ` Joerg Roedel
2013-03-26 23:24 ` Greg Kroah-Hartman
2013-03-26 23:24 ` Greg Kroah-Hartman
2013-03-26 23:47 ` Joerg Roedel
2013-03-26 23:47 ` Joerg Roedel
2013-03-27 0:05 ` Minchan Kim
2013-03-27 0:05 ` Minchan Kim
2013-03-27 0:23 ` Joerg Roedel [this message]
2013-03-27 0:23 ` Joerg Roedel
2013-03-27 0:43 ` Joerg Roedel
2013-03-27 0:43 ` Joerg Roedel
2013-03-27 1:09 ` Minchan Kim
2013-03-27 1:09 ` Minchan Kim
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=20130327002357.GG30540@8bytes.org \
--to=joro@8bytes.org \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan.kim@lge.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.