Re: [PATCH] epoll: fix use-after-free in eventpoll_release_file

[Cyrill Gorcunov]

On Tue, Jun 17, 2014 at 06:58:05AM +0400, Konstantin Khlebnikov wrote:
> This fixes use-after-free of epi->fllink.next inside list loop macro.
> This loop actually releases elements in the body. List is rcu-protected
> but here we cannot hold rcu_read_lock because we need to lock mutex inside.
> 
> Obvious solution is to use list_for_each_entry_safe(). RCU-ness isn't 
> essential
> because nobody can change this list under us, it's final fput for this file.
> 
> Bug is here since ae10b2b4eb01bedc91d29d5c5bb9e416fd806c40
> ("epoll: optimize EPOLL_CTL_DEL using rcu")
> 
> Signed-off-by: Konstantin Khlebnikov 
> Reported-by: Cyrill Gorcunov 
> Cc: Stable  # 3.13+
> Cc: Sasha Levin 
> Cc: Jason Baron 
Acked-by: Cyrill Gorcunov 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 4/8] staging: lustre: lclient: lcommon_cl.c fixing coding style issues

[Anil Belur]

From: Anil Belur 

fixed: WARNING: Missing a blank line after declarations
Signed-off-by: Anil Belur 
---
 drivers/staging/lustre/lustre/lclient/lcommon_cl.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/staging/lustre/lustre/lclient/lcommon_cl.c 
b/drivers/staging/lustre/lustre/lclient/lcommon_cl.c
index 1b0c216..1f39219 100644
--- a/drivers/staging/lustre/lustre/lclient/lcommon_cl.c
+++ b/drivers/staging/lustre/lustre/lclient/lcommon_cl.c
@@ -126,6 +126,7 @@ void ccc_key_fini(const struct lu_context *ctx,
 struct lu_context_key *key, void *data)
 {
struct ccc_thread_info *info = data;
+
OBD_SLAB_FREE_PTR(info, ccc_thread_kmem);
 }
 
@@ -144,6 +145,7 @@ void ccc_session_key_fini(const struct lu_context *ctx,
 struct lu_context_key *key, void *data)
 {
struct ccc_session *session = data;
+
OBD_SLAB_FREE_PTR(session, ccc_session_kmem);
 }
 
@@ -572,6 +574,7 @@ void ccc_lock_delete(const struct lu_env *env,
 void ccc_lock_fini(const struct lu_env *env, struct cl_lock_slice *slice)
 {
struct ccc_lock *clk = cl2ccc_lock(slice);
+
OBD_SLAB_FREE_PTR(clk, ccc_lock_kmem);
 }
 
@@ -733,6 +736,7 @@ int ccc_io_one_lock(const struct lu_env *env, struct cl_io 
*io,
loff_t start, loff_t end)
 {
struct cl_object *obj = io->ci_obj;
+
return ccc_io_one_lock_index(env, io, enqflags, mode,
 cl_index(obj, start), cl_index(obj, end));
 }
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 3/8] staging: lustre: lclient: lcommon_misc.c fixing coding style issues

[Anil Belur]

From: Anil Belur 

fixed warning:
* WARNING: min() should probably be min_t(__u32, desc.ld_tgt_count,
LOV_MAX_STRIPE_COUNT)

Signed-off-by: Anil Belur 
---
 drivers/staging/lustre/lustre/lclient/lcommon_misc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/lclient/lcommon_misc.c 
b/drivers/staging/lustre/lustre/lclient/lcommon_misc.c
index 21de1cd..0900bef 100644
--- a/drivers/staging/lustre/lustre/lclient/lcommon_misc.c
+++ b/drivers/staging/lustre/lustre/lclient/lcommon_misc.c
@@ -63,7 +63,7 @@ int cl_init_ea_size(struct obd_export *md_exp, struct 
obd_export *dt_exp)
if (rc)
return rc;
 
-   stripes = min(desc.ld_tgt_count, (__u32)LOV_MAX_STRIPE_COUNT);
+   stripes = min_t(__u32, desc.ld_tgt_count, (__u32)LOV_MAX_STRIPE_COUNT);
lsm.lsm_stripe_count = stripes;
easize = obd_size_diskmd(dt_exp, );
 
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 8/8] staging: lustre: lclient: lcommon_cl.c fixing coding style issues

[Anil Belur]

From: Anil Belur 

fixed: WARNING: suspect code indent for conditional statements (32, 32)
Signed-off-by: Anil Belur 
---
 drivers/staging/lustre/lustre/lclient/lcommon_cl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/lclient/lcommon_cl.c 
b/drivers/staging/lustre/lustre/lclient/lcommon_cl.c
index e2da397..3b2b995 100644
--- a/drivers/staging/lustre/lustre/lclient/lcommon_cl.c
+++ b/drivers/staging/lustre/lustre/lclient/lcommon_cl.c
@@ -825,8 +825,8 @@ int ccc_prep_size(const struct lu_env *env, struct 
cl_object *obj,
loff_t size_index = ((size - 1) >> 
PAGE_CACHE_SHIFT);
 
if ((size == 0 && cur_index != 0) ||
-   (size_index < cur_index))
-   *exceed = 1;
+   (size_index < cur_index))
+   *exceed = 1;
}
return result;
} else {
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 2/8] staging: lustre: lclient: glimpse.c fixing coding style issues

[Anil Belur]

From: Anil Belur 

fixed "WARNING: labels should not be indented"

Signed-off-by: Anil Belur 
---
 drivers/staging/lustre/lustre/lclient/glimpse.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/lclient/glimpse.c 
b/drivers/staging/lustre/lustre/lclient/glimpse.c
index f669645..a658116 100644
--- a/drivers/staging/lustre/lustre/lclient/glimpse.c
+++ b/drivers/staging/lustre/lustre/lclient/glimpse.c
@@ -204,7 +204,7 @@ int cl_glimpse_size0(struct inode *inode, int agl)
 
result = cl_io_get(inode, , , );
if (result > 0) {
-   again:
+again:
io->ci_verify_layout = 1;
result = cl_io_init(env, io, CIT_MISC, io->ci_obj);
if (result > 0)
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 7/8] staging: lustre: lclient: lcommon_cl.c fixing coding style issues

[Anil Belur]

From: Anil Belur 

fixed: WARNING: line over 80 characters, used a new variable 'size_index' to
store the offset. Replaceed "unsigned long" with  "loff_t" type for
'cur_index'

Signed-off-by: Anil Belur 
---
 drivers/staging/lustre/lustre/lclient/lcommon_cl.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lustre/lclient/lcommon_cl.c 
b/drivers/staging/lustre/lustre/lclient/lcommon_cl.c
index 2f51b76..e2da397 100644
--- a/drivers/staging/lustre/lustre/lclient/lcommon_cl.c
+++ b/drivers/staging/lustre/lustre/lclient/lcommon_cl.c
@@ -821,10 +821,11 @@ int ccc_prep_size(const struct lu_env *env, struct 
cl_object *obj,
 * linux-2.6.18-128.1.1 miss to do that.
 * --bug 17336 */
loff_t size = cl_isize_read(inode);
-   unsigned long cur_index = start >> 
PAGE_CACHE_SHIFT;
+   loff_t cur_index = start >> PAGE_CACHE_SHIFT;
+   loff_t size_index = ((size - 1) >> 
PAGE_CACHE_SHIFT);
 
if ((size == 0 && cur_index != 0) ||
-   (((size - 1) >> PAGE_CACHE_SHIFT) < 
cur_index))
+   (size_index < cur_index))
*exceed = 1;
}
return result;
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 6/8] staging: lustre: lclient: lcommon_cl.c fixing coding style issues

[Anil Belur]

From: Anil Belur 

fixed: ERROR: inline keyword should sit between storage class and type
Signed-off-by: Anil Belur 
---
 drivers/staging/lustre/lustre/lclient/lcommon_cl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/lclient/lcommon_cl.c 
b/drivers/staging/lustre/lustre/lclient/lcommon_cl.c
index de0ad37e..2f51b76 100644
--- a/drivers/staging/lustre/lustre/lclient/lcommon_cl.c
+++ b/drivers/staging/lustre/lustre/lclient/lcommon_cl.c
@@ -1273,7 +1273,7 @@ struct lov_stripe_md *ccc_inode_lsm_get(struct inode 
*inode)
return lov_lsm_get(cl_i2info(inode)->lli_clob);
 }
 
-void inline ccc_inode_lsm_put(struct inode *inode, struct lov_stripe_md *lsm)
+inline void ccc_inode_lsm_put(struct inode *inode, struct lov_stripe_md *lsm)
 {
lov_lsm_put(cl_i2info(inode)->lli_clob, lsm);
 }
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 5/8] staging: lustre: lclient: lcommon_cl.c fixing coding style issues

[Anil Belur]

From: Anil Belur 

fixed:  ERROR: do not initialise statics to 0 or NULL
Signed-off-by: Anil Belur 
---
 drivers/staging/lustre/lustre/lclient/lcommon_cl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/lclient/lcommon_cl.c 
b/drivers/staging/lustre/lustre/lclient/lcommon_cl.c
index 1f39219..de0ad37e 100644
--- a/drivers/staging/lustre/lustre/lclient/lcommon_cl.c
+++ b/drivers/staging/lustre/lustre/lclient/lcommon_cl.c
@@ -266,7 +266,7 @@ int ccc_req_init(const struct lu_env *env, struct cl_device 
*dev,
  * fails. Access to this environment is serialized by ccc_inode_fini_guard
  * mutex.
  */
-static struct lu_env *ccc_inode_fini_env = NULL;
+static struct lu_env *ccc_inode_fini_env;
 
 /**
  * A mutex serializing calls to slp_inode_fini() under extreme memory
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 1/8] staging: lustre: lclient: glimpse.c fixing coding style issues

[Anil Belur]

From: Anil Belur 

Fixed "ERROR: need consistent spacing around '+' (ctx:WxV)"

Signed-off-by: Anil Belur 
---
 drivers/staging/lustre/lustre/lclient/glimpse.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/lclient/glimpse.c 
b/drivers/staging/lustre/lustre/lclient/glimpse.c
index 7bbca4b..f669645 100644
--- a/drivers/staging/lustre/lustre/lclient/glimpse.c
+++ b/drivers/staging/lustre/lustre/lclient/glimpse.c
@@ -177,7 +177,7 @@ static int cl_io_get(struct inode *inode, struct lu_env 
**envout,
io->ci_obj = clob;
*envout = env;
*ioout  = io;
-   result = +1;
+   result = 1;
} else
result = PTR_ERR(env);
} else
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6] staging: lustre: lclient: fixing coding style issues

[Anil Belur]

Revised PATCH 7/8 and updated the comment, as suggested by 
"oleg.dro...@intel.com"

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Nouveau] REGRESSION: Kernel PANIC 8777c5c11764d8336d8270f96778158c34c92108 - drm/nouveau/dp: probe dpcd to determine connectedness

[Thomas Glanzmann]

Hello Ben,

> > 8777c5c11764d8336d8270f96778158c34c92108 (which is mentioned as the
> > first bad commit above...) is a tiny commit, so I have no idea what
> > you mean by "too large for your taste".

for example I would not export a symbol and do something else in the
same commit, but would split them up in two. I do the minimum work per
commit without breaking compilation or functionality. That way it is
easier to identify issues later on.

> In any case, I encountered the oops myself earlier (absolutely nothing
> to do with that commit) and fixed it here.  I've sent it onto Dave for
> the next -fixes merge, so hopefully it'll help your case too.

Can you please send me your fix. I can reboot my machine remotely, but
only once. That way I can tell you if your fix works, or not.

> I have no idea why gmail doesn't auto-add you to the Cc list on reply
> all.. But.. Done :)

thanks.

Cheers,
Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Nouveau] REGRESSION: Kernel PANIC 8777c5c11764d8336d8270f96778158c34c92108 - drm/nouveau/dp: probe dpcd to determine connectedness

[Ben Skeggs]

On Tue, Jun 17, 2014 at 3:39 PM, Ben Skeggs  wrote:
> On Tue, Jun 17, 2014 at 3:33 PM, Thomas Glanzmann  wrote:
>> Hello Ben,
>>
>>> Are you able to double-check that bisect?  I'm not at all sure how
>>> that particular commit could trigger the issue you're seeing.  Some of
>>> the others, certainly.  It might be worth trying a couple of times
>>> before marking something as "good", in case there's a timing aspect to
>>> the problem.
>>
>> please CC me, otherwise I might not see your message. The bug is very
>> clear, I boot my machine, the screen turns black as soon as the X server
>> is booted and the system does not ping anymore. I rebooted several times
>> before the bisect and the bug always hit me. For my taste the offending
>> commit is to large. So maybe I can split it in multiple smaller commits
>> and than debug it. However I'm currently out of the office, so maybe
>> tomorrow. If you do any progress on this, please CC me in order to avoid
>> duplicate effort.
> 8777c5c11764d8336d8270f96778158c34c92108 (which is mentioned as the
> first bad commit above...) is a tiny commit, so I have no idea what
> you mean by "too large for your taste".
>
> In any case, I encountered the oops myself earlier (absolutely nothing
> to do with that commit) and fixed it here.  I've sent it onto Dave for
> the next -fixes merge, so hopefully it'll help your case too.
I have no idea why gmail doesn't auto-add you to the Cc list on reply
all.. But.. Done :)

>
> Thanks,
> Ben.
>
>>
>> Cheers,
>> Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Nouveau] REGRESSION: Kernel PANIC 8777c5c11764d8336d8270f96778158c34c92108 - drm/nouveau/dp: probe dpcd to determine connectedness

[Ben Skeggs]

On Tue, Jun 17, 2014 at 3:33 PM, Thomas Glanzmann  wrote:
> Hello Ben,
>
>> Are you able to double-check that bisect?  I'm not at all sure how
>> that particular commit could trigger the issue you're seeing.  Some of
>> the others, certainly.  It might be worth trying a couple of times
>> before marking something as "good", in case there's a timing aspect to
>> the problem.
>
> please CC me, otherwise I might not see your message. The bug is very
> clear, I boot my machine, the screen turns black as soon as the X server
> is booted and the system does not ping anymore. I rebooted several times
> before the bisect and the bug always hit me. For my taste the offending
> commit is to large. So maybe I can split it in multiple smaller commits
> and than debug it. However I'm currently out of the office, so maybe
> tomorrow. If you do any progress on this, please CC me in order to avoid
> duplicate effort.
8777c5c11764d8336d8270f96778158c34c92108 (which is mentioned as the
first bad commit above...) is a tiny commit, so I have no idea what
you mean by "too large for your taste".

In any case, I encountered the oops myself earlier (absolutely nothing
to do with that commit) and fixed it here.  I've sent it onto Dave for
the next -fixes merge, so hopefully it'll help your case too.

Thanks,
Ben.

>
> Cheers,
> Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] iommu/intel: Exclude devices using RMRRs from IOMMU API domains

[Alex Williamson]

On Fri, 2014-06-13 at 10:30 -0600, Alex Williamson wrote:
> The user of the IOMMU API domain expects to have full control of
> the IOVA space for the domain.  RMRRs are fundamentally incompatible
> with that idea.  We can neither map the RMRR into the IOMMU API
> domain, nor can we guarantee that the device won't continue DMA with
> the area described by the RMRR as part of the new domain.  Therefore
> we must prevent such devices from being used by the IOMMU API.
> 
> Signed-off-by: Alex Williamson 
> Cc: sta...@vger.kernel.org
> ---

David,

Any idea what an off-the-shelf Asus motherboard would be doing with an
RMRR on the Intel HD graphics?

dmar: RMRR base: 0x00bb80 end: 0x00bf9f
IOMMU: Setting identity map for device :00:02.0 [0xbb80 - 0xbf9f]

Thanks,

Alex

> v2: consolidate test to a single, well documented function.
> 
>  drivers/iommu/intel-iommu.c |   49 
> ++-
>  1 file changed, 39 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index c4f11c0..253d598 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -2511,22 +2511,46 @@ static bool device_has_rmrr(struct device *dev)
>   return false;
>  }
>  
> +/*
> + * There are a couple cases where we need to restrict the functionality of
> + * devices associated with RMRRs.  The first is when evaluating a device for
> + * identity mapping because problems exist when devices are moved in and out
> + * of domains and their respective RMRR information is lost.  This means that
> + * a device with associated RMRRs will never be in a "passthrough" domain.
> + * The second is use of the device through the IOMMU API.  This interface
> + * expects to have full control of the IOVA space for the device.  We cannot
> + * satisfy both the requirement that RMRR access is maintained and have an
> + * unencumbered IOVA space.  We also have no ability to quiesce the device's
> + * use of the RMRR space or even inform the IOMMU API user of the 
> restriction.
> + * We therefore prevent devices associated with an RMRR from participating in
> + * the IOMMU API, which eliminates them from device assignment.
> + *
> + * In both cases we assume that PCI USB devices with RMRRs have them largely
> + * for historical reasons and that the RMRR space is not actively used post
> + * boot.  This exclusion may change if vendors begin to abuse it.
> + */
> +static bool device_is_rmrr_locked(struct device *dev)
> +{
> + if (!device_has_rmrr(dev))
> + return false;
> +
> + if (dev_is_pci(dev)) {
> + struct pci_dev *pdev = to_pci_dev(dev);
> +
> + if ((pdev->class >> 8) == PCI_CLASS_SERIAL_USB)
> + return false;
> + }
> +
> + return true;
> +}
> +
>  static int iommu_should_identity_map(struct device *dev, int startup)
>  {
>  
>   if (dev_is_pci(dev)) {
>   struct pci_dev *pdev = to_pci_dev(dev);
>  
> - /*
> -  * We want to prevent any device associated with an RMRR from
> -  * getting placed into the SI Domain. This is done because
> -  * problems exist when devices are moved in and out of domains
> -  * and their respective RMRR info is lost. We exempt USB devices
> -  * from this process due to their usage of RMRRs that are known
> -  * to not be needed after BIOS hand-off to OS.
> -  */
> - if (device_has_rmrr(dev) &&
> - (pdev->class >> 8) != PCI_CLASS_SERIAL_USB)
> + if (device_is_rmrr_locked(dev))
>   return 0;
>  
>   if ((iommu_identity_mapping & IDENTMAP_AZALIA) && 
> IS_AZALIA(pdev))
> @@ -4171,6 +4195,11 @@ static int intel_iommu_attach_device(struct 
> iommu_domain *domain,
>   int addr_width;
>   u8 bus, devfn;
>  
> + if (device_is_rmrr_locked(dev)) {
> + dev_warn(dev, "Device is ineligible for IOMMU domain attach due 
> to platform RMRR requirement.  Contact your platform vendor.\n");
> + return -EPERM;
> + }
> +
>   /* normally dev is not mapped */
>   if (unlikely(domain_context_mapped(dev))) {
>   struct dmar_domain *old_domain;
> 
> ___
> iommu mailing list
> io...@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Nouveau] REGRESSION: Kernel PANIC 8777c5c11764d8336d8270f96778158c34c92108 - drm/nouveau/dp: probe dpcd to determine connectedness

[Thomas Glanzmann]

Hello Ben,

> Are you able to double-check that bisect?  I'm not at all sure how
> that particular commit could trigger the issue you're seeing.  Some of
> the others, certainly.  It might be worth trying a couple of times
> before marking something as "good", in case there's a timing aspect to
> the problem.

please CC me, otherwise I might not see your message. The bug is very
clear, I boot my machine, the screen turns black as soon as the X server
is booted and the system does not ping anymore. I rebooted several times
before the bisect and the bug always hit me. For my taste the offending
commit is to large. So maybe I can split it in multiple smaller commits
and than debug it. However I'm currently out of the office, so maybe
tomorrow. If you do any progress on this, please CC me in order to avoid
duplicate effort.

Cheers,
Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

帳戶升級

[Bryn Robinson]

您無法接收新收到的郵件為您的渡渡鳥郵箱已超過其配額限制由您WebAdmin.Click載下面的鏈接，以增
加您的Webmail配額。 
http://openwebmail-itservicedesk.webs.com

[RFC Patch V2 03/16] ACPI, x86/PCI: Move resource_to_addr() to acpi generic

[Jiang Liu]

From: Yinghai Lu 

Rui Wang reported ioapic hot-add does not work on his machine
that _CRS have MEMORY_FIXED.
He also proposed to expose resource_to_addr() and use it for ioapic.

We should move it to acpi generic, as ioapi.c current is in
drivers/pci/.

Or should move it to acpica?

Signed-off-by: Yinghai Lu 
Signed-off-by: Jiang Liu 
---
 arch/x86/pci/acpi.c |   50 ++-
 drivers/acpi/resource.c |   46 +++
 include/linux/acpi.h|3 +++
 3 files changed, 51 insertions(+), 48 deletions(-)

diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index 91bef49df228..e766cc7d3abe 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -218,59 +218,13 @@ static void teardown_mcfg_map(struct pci_root_info *info)
 }
 #endif
 
-static acpi_status resource_to_addr(struct acpi_resource *resource,
-   struct acpi_resource_address64 *addr)
-{
-   acpi_status status;
-   struct acpi_resource_memory24 *memory24;
-   struct acpi_resource_memory32 *memory32;
-   struct acpi_resource_fixed_memory32 *fixed_memory32;
-
-   memset(addr, 0, sizeof(*addr));
-   switch (resource->type) {
-   case ACPI_RESOURCE_TYPE_MEMORY24:
-   memory24 = >data.memory24;
-   addr->resource_type = ACPI_MEMORY_RANGE;
-   addr->minimum = memory24->minimum;
-   addr->address_length = memory24->address_length;
-   addr->maximum = addr->minimum + addr->address_length - 1;
-   return AE_OK;
-   case ACPI_RESOURCE_TYPE_MEMORY32:
-   memory32 = >data.memory32;
-   addr->resource_type = ACPI_MEMORY_RANGE;
-   addr->minimum = memory32->minimum;
-   addr->address_length = memory32->address_length;
-   addr->maximum = addr->minimum + addr->address_length - 1;
-   return AE_OK;
-   case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
-   fixed_memory32 = >data.fixed_memory32;
-   addr->resource_type = ACPI_MEMORY_RANGE;
-   addr->minimum = fixed_memory32->address;
-   addr->address_length = fixed_memory32->address_length;
-   addr->maximum = addr->minimum + addr->address_length - 1;
-   return AE_OK;
-   case ACPI_RESOURCE_TYPE_ADDRESS16:
-   case ACPI_RESOURCE_TYPE_ADDRESS32:
-   case ACPI_RESOURCE_TYPE_ADDRESS64:
-   status = acpi_resource_to_address64(resource, addr);
-   if (ACPI_SUCCESS(status) &&
-   (addr->resource_type == ACPI_MEMORY_RANGE ||
-   addr->resource_type == ACPI_IO_RANGE) &&
-   addr->address_length > 0) {
-   return AE_OK;
-   }
-   break;
-   }
-   return AE_ERROR;
-}
-
 static acpi_status count_resource(struct acpi_resource *acpi_res, void *data)
 {
struct pci_root_info *info = data;
struct acpi_resource_address64 addr;
acpi_status status;
 
-   status = resource_to_addr(acpi_res, );
+   status = acpi_mem_addr_resource_to_address64(acpi_res, );
if (ACPI_SUCCESS(status))
info->res_num++;
return AE_OK;
@@ -285,7 +239,7 @@ static acpi_status setup_resource(struct acpi_resource 
*acpi_res, void *data)
unsigned long flags;
u64 start, orig_end, end;
 
-   status = resource_to_addr(acpi_res, );
+   status = acpi_mem_addr_resource_to_address64(acpi_res, );
if (!ACPI_SUCCESS(status))
return AE_OK;
 
diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 0bdacc5e26a3..e91deebf0930 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -424,6 +424,52 @@ void acpi_dev_free_resource_list(struct list_head *list)
 }
 EXPORT_SYMBOL_GPL(acpi_dev_free_resource_list);
 
+acpi_status acpi_mem_addr_resource_to_address64(struct acpi_resource *resource,
+   struct acpi_resource_address64 *addr)
+{
+   acpi_status status;
+   struct acpi_resource_memory24 *memory24;
+   struct acpi_resource_memory32 *memory32;
+   struct acpi_resource_fixed_memory32 *fixed_memory32;
+
+   memset(addr, 0, sizeof(*addr));
+   switch (resource->type) {
+   case ACPI_RESOURCE_TYPE_MEMORY24:
+   memory24 = >data.memory24;
+   addr->resource_type = ACPI_MEMORY_RANGE;
+   addr->minimum = memory24->minimum;
+   addr->address_length = memory24->address_length;
+   addr->maximum = addr->minimum + addr->address_length - 1;
+   return AE_OK;
+   case ACPI_RESOURCE_TYPE_MEMORY32:
+   memory32 = >data.memory32;
+   addr->resource_type = ACPI_MEMORY_RANGE;
+   addr->minimum = memory32->minimum;
+   addr->address_length = memory32->address_length;
+   addr->maximum = 

[RFC Patch V2 02/16] x86, ioapic: Find usable ioapic id for 64bit.

[Jiang Liu]

From: Yinghai Lu 

Checking the id in register, if that is duplicated, will pick one and
update id register.

Signed-off-by: Yinghai Lu 
Cc: Joerg Roedel 
Cc: Konrad Rzeszutek Wilk 
Cc: Sebastian Andrzej Siewior 
Signed-off-by: Jiang Liu 
---
 arch/x86/kernel/apic/io_apic.c |   38 +-
 1 file changed, 33 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index e97ec28f5269..e56bb94cd32a 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3566,26 +3566,54 @@ static int __init io_apic_get_unique_id(int ioapic, int 
apic_id)
return apic_id;
 }
 
-static u8 __init io_apic_unique_id(u8 id)
+static u8 io_apic_unique_id(int idx, u8 id)
 {
if ((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) &&
!APIC_XAPIC(apic_version[boot_cpu_physical_apicid]))
-   return io_apic_get_unique_id(nr_ioapics, id);
+   return io_apic_get_unique_id(idx, id);
else
return id;
 }
 #else
-static u8 __init io_apic_unique_id(u8 id)
+static u8 io_apic_unique_id(int idx, u8 id)
 {
int i;
+   u8 new_id;
+   unsigned long flags;
DECLARE_BITMAP(used, 256);
+   union IO_APIC_reg_00 reg_00;
 
bitmap_zero(used, 256);
for_each_ioapic(i)
__set_bit(mpc_ioapic_id(i), used);
if (!test_bit(id, used))
return id;
-   return find_first_zero_bit(used, 256);
+
+   /* check register at first */
+   raw_spin_lock_irqsave(_lock, flags);
+   reg_00.raw = io_apic_read(idx, 0);
+   raw_spin_unlock_irqrestore(_lock, flags);
+   new_id = reg_00.bits.ID;
+   if (!test_bit(new_id, used)) {
+   apic_printk(APIC_VERBOSE, KERN_INFO
+   "IOAPIC[%d]: Using reg apic_id %d instead of %d\n",
+idx, new_id, id);
+   return new_id;
+   }
+
+   new_id = find_first_zero_bit(used, 256);
+   reg_00.bits.ID = new_id;
+   raw_spin_lock_irqsave(_lock, flags);
+   io_apic_write(idx, 0, reg_00.raw);
+   reg_00.raw = io_apic_read(idx, 0);
+   raw_spin_unlock_irqrestore(_lock, flags);
+
+   /* Sanity check */
+   if (reg_00.bits.ID != new_id)
+   pr_warn("IOAPIC[%d]: Unable to change apic_id to %d!\n",
+   idx, new_id);
+
+   return new_id;
 }
 #endif
 
@@ -3851,7 +3879,7 @@ void __init mp_register_ioapic(int id, u32 address, u32 
gsi_base,
return;
}
 
-   ioapics[idx].mp_config.apicid = io_apic_unique_id(id);
+   ioapics[idx].mp_config.apicid = io_apic_unique_id(idx, id);
ioapics[idx].mp_config.apicver = io_apic_get_version(idx);
 
/*
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC Patch V2 13/16] x86, irq, ACPI: implement interface to support ACPI based IOAPIC hot-removal

[Jiang Liu]

Implement acpi_unregister_ioapic() to support ACPI based IOAPIC hot-removal.
An IOAPIC could only be removed when all its pins are unused.

Signed-off-by: Jiang Liu 
---
 arch/x86/include/asm/io_apic.h |1 +
 arch/x86/kernel/acpi/boot.c|   13 +++---
 arch/x86/kernel/apic/io_apic.c |   55 
 3 files changed, 65 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 94d05bd6586f..ce63cf34c93c 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -190,6 +190,7 @@ extern int mp_map_gsi_to_irq(u32 gsi, unsigned int flags);
 extern void mp_unmap_irq(int irq);
 extern int mp_register_ioapic(int id, u32 address, u32 gsi_base,
  struct ioapic_domain_cfg *cfg);
+extern int mp_unregister_ioapic(u32 gsi_base);
 extern int mp_irqdomain_map(struct irq_domain *domain, unsigned int virq,
irq_hw_number_t hwirq);
 extern void mp_irqdomain_unmap(struct irq_domain *domain, unsigned int virq);
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 85caf3221cde..8a1b25d2aa4c 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -804,15 +804,20 @@ int acpi_register_ioapic(acpi_handle handle, u64 
phys_addr, u32 gsi_base)
 
return ret;
 }
-
 EXPORT_SYMBOL(acpi_register_ioapic);
 
 int acpi_unregister_ioapic(acpi_handle handle, u32 gsi_base)
 {
-   /* TBD */
-   return -EINVAL;
-}
+   int ret = -ENOSYS;
+
+#ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
+   down_write(_ioapic_rwsem);
+   ret  = mp_unregister_ioapic(gsi_base);
+   up_write(_ioapic_rwsem);
+#endif
 
+   return ret;
+}
 EXPORT_SYMBOL(acpi_unregister_ioapic);
 
 static int __init acpi_parse_sbf(struct acpi_table_header *table)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index d26fd3ac1b4b..22bbecb05345 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -112,6 +112,7 @@ static struct ioapic {
struct ioapic_domain_cfg irqdomain_cfg;
struct irq_domain *irqdomain;
struct mp_pin_info *pin_info;
+   struct resource *iomem_res;
 } ioapics[MAX_IO_APICS];
 
 #define mpc_ioapic_ver(ioapic_idx) ioapics[ioapic_idx].mp_config.apicver
@@ -250,6 +251,12 @@ static void alloc_ioapic_saved_registers(int idx)
pr_err("IOAPIC %d: suspend/resume impossible!\n", idx);
 }
 
+static void free_ioapic_saved_registers(int idx)
+{
+   kfree(ioapics[idx].saved_registers);
+   ioapics[idx].saved_registers = NULL;
+}
+
 int __init arch_early_irq_init(void)
 {
struct irq_cfg *cfg;
@@ -2967,6 +2974,16 @@ static int mp_irqdomain_create(int ioapic)
return 0;
 }
 
+static void ioapic_destroy_irqdomain(int idx)
+{
+   if (ioapics[idx].irqdomain) {
+   irq_domain_remove(ioapics[idx].irqdomain);
+   ioapics[idx].irqdomain = NULL;
+   }
+   kfree(ioapics[idx].pin_info);
+   ioapics[idx].pin_info = NULL;
+}
+
 void __init setup_IO_APIC(void)
 {
int ioapic;
@@ -3724,6 +3741,7 @@ static struct resource * __init 
ioapic_setup_resources(void)
snprintf(mem, IOAPIC_RESOURCE_NAME_SIZE, "IOAPIC %u", i);
mem += IOAPIC_RESOURCE_NAME_SIZE;
num++;
+   ioapics[i].iomem_res = res;
}
 
ioapic_resources = res;
@@ -3946,6 +3964,43 @@ int mp_register_ioapic(int id, u32 address, u32 gsi_base,
return 0;
 }
 
+int mp_unregister_ioapic(u32 gsi_base)
+{
+   int ioapic, pin;
+   int found = 0;
+   struct mp_pin_info *pin_info;
+
+   for_each_ioapic(ioapic)
+   if (ioapics[ioapic].gsi_config.gsi_base == gsi_base) {
+   found = 1;
+   break;
+   }
+   if (!found) {
+   pr_warn("can't find IOAPIC for GSI %d\n", gsi_base);
+   return -ENODEV;
+   }
+
+   for_each_pin(ioapic, pin) {
+   pin_info = mp_pin_info(ioapic, pin);
+   if (pin_info->count) {
+   pr_warn("pin%d on IOAPIC%d is still in use.\n",
+   pin, ioapic);
+   return -EBUSY;
+   }
+   }
+
+   /* Mark entry not present */
+   ioapics[ioapic].nr_registers  = 0;
+   ioapic_destroy_irqdomain(ioapic);
+   free_ioapic_saved_registers(ioapic);
+   if (ioapics[ioapic].iomem_res)
+   release_resource(ioapics[ioapic].iomem_res);
+   clear_fixmap(FIX_IO_APIC_BASE_0 + ioapic);
+   memset([ioapic], 0, sizeof(ioapics[ioapic]));
+
+   return 0;
+}
+
 int mp_irqdomain_map(struct irq_domain *domain, unsigned int virq,
 irq_hw_number_t hwirq)
 {
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org

[RFC Patch V2 06/16] ACPI, ioapic: Add acpi_get_ioapic_id()

[Jiang Liu]

From: Yinghai Lu 

For ioapic hotplug, we need to parse apic id for ioapic registration.

We could check _MAT and MADT to get io apic id, just like cpu hotplug
path to get apic id.

Signed-off-by: Yinghai Lu 
Signed-off-by: Jiang Liu 
---
 drivers/acpi/apic_id.c |   97 +++-
 include/linux/acpi.h   |3 ++
 2 files changed, 98 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/apic_id.c b/drivers/acpi/apic_id.c
index ac3b10a9f92d..a74a3fcd8362 100644
--- a/drivers/acpi/apic_id.c
+++ b/drivers/acpi/apic_id.c
@@ -2,6 +2,10 @@
  * Copyright (C) 2005 Intel Corporation
  * Copyright (C) 2009 Hewlett-Packard Development Company, L.P.
  * All routines dealing with CPU APIC ID are moved from processor_core.c
+ *
+ * I/O APIC hotplug support
+ * Yinghai Lu 
+ * Jiang Liu 
  */
 #include 
 #include 
@@ -9,6 +13,9 @@
 
 #include "internal.h"
 
+static struct acpi_table_madt *madt;
+static int read_madt;
+
 static int map_lapic_id(struct acpi_subtable_header *entry,
 u32 acpi_id, int *apic_id)
 {
@@ -64,8 +71,6 @@ static int map_lsapic_id(struct acpi_subtable_header *entry,
 static int map_madt_entry(int type, u32 acpi_id)
 {
unsigned long madt_end, entry;
-   static struct acpi_table_madt *madt;
-   static int read_madt;
int apic_id = -1;
 
if (!read_madt) {
@@ -200,3 +205,91 @@ int acpi_get_cpuid(acpi_handle handle, int type, u32 
acpi_id)
return acpi_map_cpuid(apic_id, acpi_id);
 }
 EXPORT_SYMBOL_GPL(acpi_get_cpuid);
+
+#ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
+static int map_ioapic_id(struct acpi_subtable_header *entry, u32 gsi_base,
+u64 *phys_addr, int *ioapic_id)
+{
+   struct acpi_madt_io_apic *ioapic = (struct acpi_madt_io_apic *)entry;
+
+   if (ioapic->global_irq_base != gsi_base)
+   return 0;
+
+   *phys_addr = ioapic->address;
+   *ioapic_id = ioapic->id;
+   return 1;
+}
+
+static int map_madt_ioapic_entry(u32 gsi_base, u64 *phys_addr)
+{
+   struct acpi_subtable_header *hdr;
+   unsigned long madt_end, entry;
+   int apic_id = -1;
+
+   if (!read_madt) {
+   if (ACPI_FAILURE(acpi_get_table(ACPI_SIG_MADT, 0,
+   (struct acpi_table_header **
+   madt = NULL;
+   read_madt++;
+   }
+
+   if (!madt)
+   return apic_id;
+
+   entry = (unsigned long)madt;
+   madt_end = entry + madt->header.length;
+
+   /* Parse all entries looking for a match. */
+   entry += sizeof(struct acpi_table_madt);
+   while (entry + sizeof(struct acpi_subtable_header) < madt_end) {
+   hdr = (struct acpi_subtable_header *)entry;
+   if (hdr->type == ACPI_MADT_TYPE_IO_APIC &&
+   map_ioapic_id(hdr, gsi_base, phys_addr, _id))
+   break;
+   else
+   entry += hdr->length;
+   }
+
+   return apic_id;
+}
+
+static int map_mat_ioapic_entry(acpi_handle handle, u32 gsi_base,
+   u64 *phys_addr)
+{
+   struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+   union acpi_object *obj;
+   struct acpi_subtable_header *header;
+   int apic_id = -1;
+
+   if (ACPI_FAILURE(acpi_evaluate_object(handle, "_MAT", NULL, )))
+   goto exit;
+
+   if (!buffer.length || !buffer.pointer)
+   goto exit;
+
+   obj = buffer.pointer;
+   if (obj->type != ACPI_TYPE_BUFFER ||
+   obj->buffer.length < sizeof(struct acpi_subtable_header)) {
+   goto exit;
+   }
+
+   header = (struct acpi_subtable_header *)obj->buffer.pointer;
+   if (header->type == ACPI_MADT_TYPE_IO_APIC)
+   map_ioapic_id(header, gsi_base, phys_addr, _id);
+
+exit:
+   kfree(buffer.pointer);
+   return apic_id;
+}
+
+int acpi_get_ioapic_id(acpi_handle handle, u32 gsi_base, u64 *phys_addr)
+{
+   int apic_id;
+
+   apic_id = map_mat_ioapic_entry(handle, gsi_base, phys_addr);
+   if (apic_id == -1)
+   apic_id = map_madt_ioapic_entry(gsi_base, phys_addr);
+
+   return apic_id;
+}
+#endif /* CONFIG_ACPI_HOTPLUG_IOAPIC */
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 5c432e842921..f478af87f575 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -148,6 +148,9 @@ int acpi_unmap_lsapic(int cpu);
 int acpi_get_apicid(acpi_handle, int type, u32 acpi_id);
 int acpi_map_cpuid(int apic_id, u32 acpi_id);
 int acpi_get_cpuid(acpi_handle, int type, u32 acpi_id);
+#ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
+int acpi_get_ioapic_id(acpi_handle handle, u32 gsi_base, u64 *phys_addr);
+#endif
 
 int acpi_register_ioapic(acpi_handle handle, u64 phys_addr, u32 gsi_base);
 int acpi_unregister_ioapic(acpi_handle handle, u32 gsi_base);
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 

[RFC Patch V2 14/16] x86, irq: introduce helper to check whether an IOAPIC has been registered

[Jiang Liu]

Introduce acpi_ioapic_registered() to check whether an IOAPIC has already
been registered, it will be used when enabling IOAPIC hotplug.

Signed-off-by: Jiang Liu 
---
 arch/x86/include/asm/io_apic.h |1 +
 arch/x86/kernel/acpi/boot.c|   11 +++
 arch/x86/kernel/apic/io_apic.c |   11 +++
 include/linux/acpi.h   |1 +
 4 files changed, 24 insertions(+)

diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index ce63cf34c93c..0db2b7037e4b 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -191,6 +191,7 @@ extern void mp_unmap_irq(int irq);
 extern int mp_register_ioapic(int id, u32 address, u32 gsi_base,
  struct ioapic_domain_cfg *cfg);
 extern int mp_unregister_ioapic(u32 gsi_base);
+extern int mp_ioapic_registered(u32 gsi_base);
 extern int mp_irqdomain_map(struct irq_domain *domain, unsigned int virq,
irq_hw_number_t hwirq);
 extern void mp_irqdomain_unmap(struct irq_domain *domain, unsigned int virq);
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 8a1b25d2aa4c..bab37bd6296a 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -820,6 +820,17 @@ int acpi_unregister_ioapic(acpi_handle handle, u32 
gsi_base)
 }
 EXPORT_SYMBOL(acpi_unregister_ioapic);
 
+int acpi_ioapic_registered(acpi_handle handle, u32 gsi_base)
+{
+   int ret;
+
+   down_write(_ioapic_rwsem);
+   ret  = mp_ioapic_registered(gsi_base);
+   up_write(_ioapic_rwsem);
+
+   return ret;
+}
+
 static int __init acpi_parse_sbf(struct acpi_table_header *table)
 {
struct acpi_table_boot *sb;
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 22bbecb05345..176433c03cf5 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -4001,6 +4001,17 @@ int mp_unregister_ioapic(u32 gsi_base)
return 0;
 }
 
+int mp_ioapic_registered(u32 gsi_base)
+{
+   int ioapic;
+
+   for_each_ioapic(ioapic)
+   if (ioapics[ioapic].gsi_config.gsi_base == gsi_base)
+   return 1;
+
+   return 0;
+}
+
 int mp_irqdomain_map(struct irq_domain *domain, unsigned int virq,
 irq_hw_number_t hwirq)
 {
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index f478af87f575..7cf20a2e29cc 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -154,6 +154,7 @@ int acpi_get_ioapic_id(acpi_handle handle, u32 gsi_base, 
u64 *phys_addr);
 
 int acpi_register_ioapic(acpi_handle handle, u64 phys_addr, u32 gsi_base);
 int acpi_unregister_ioapic(acpi_handle handle, u32 gsi_base);
+int acpi_ioapic_registered(acpi_handle handle, u32 gsi_base);
 void acpi_irq_stats_init(void);
 extern u32 acpi_irq_handled;
 extern u32 acpi_irq_not_handled;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC Patch V2 11/16] x86, irq, ACPI: introduce a rwsem to protect IOAPIC operations from hotplug

[Jiang Liu]

We are going to support ACPI based IOAPIC hotplug, so introduce a rwsem
to protect IOAPIC data structures from IOAPIC hotplug. We choose to
serialize in ACPI instead of in the IOAPIC core because:
1) currently we are only plan to support ACPI based IOAPIC hotplug
2) it's much more clean and easy
3) It does't affect IOAPIC discovered by devicetree, SFI and mppparse.

Signed-off-by: Jiang Liu 
---
 arch/x86/kernel/acpi/boot.c |   13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 8c28023924bf..120b573f1e96 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -76,6 +76,8 @@ int acpi_fix_pin2_polarity __initdata;
 static u64 acpi_lapic_addr __initdata = APIC_DEFAULT_PHYS_BASE;
 #endif
 
+static DECLARE_RWSEM(acpi_ioapic_rwsem);
+
 #ifndef __HAVE_ARCH_CMPXCHG
 #warning ACPI uses CMPXCHG, i486 and later hardware
 #endif
@@ -608,8 +610,11 @@ void __init acpi_pic_sci_set_trigger(unsigned int irq, u16 
trigger)
 
 int acpi_gsi_to_irq(u32 gsi, unsigned int *irqp)
 {
-   int irq = mp_map_gsi_to_irq(gsi, IOAPIC_MAP_ALLOC | IOAPIC_MAP_CHECK);
+   int irq;
 
+   down_read(_ioapic_rwsem);
+   irq = mp_map_gsi_to_irq(gsi, IOAPIC_MAP_ALLOC | IOAPIC_MAP_CHECK);
+   up_read(_ioapic_rwsem);
if (irq >= 0) {
*irqp = irq;
return 0;
@@ -650,7 +655,9 @@ static int acpi_register_gsi_ioapic(struct device *dev, u32 
gsi,
int irq = gsi;
 
 #ifdef CONFIG_X86_IO_APIC
+   down_read(_ioapic_rwsem);
irq = mp_register_gsi(dev, gsi, trigger, polarity);
+   up_read(_ioapic_rwsem);
 #endif
 
return irq;
@@ -659,7 +666,9 @@ static int acpi_register_gsi_ioapic(struct device *dev, u32 
gsi,
 static void acpi_unregister_gsi_ioapic(u32 gsi)
 {
 #ifdef CONFIG_X86_IO_APIC
+   down_read(_ioapic_rwsem);
mp_unregister_gsi(gsi);
+   up_read(_ioapic_rwsem);
 #endif
 }
 
@@ -1185,7 +1194,9 @@ static void __init acpi_process_madt(void)
/*
 * Parse MADT IO-APIC entries
 */
+   down_write(_ioapic_rwsem);
error = acpi_parse_madt_ioapic_entries();
+   up_write(_ioapic_rwsem);
if (!error) {
acpi_set_irq_model_ioapic();
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC Patch V2 15/16] pci, ioapic: kill ioapic PCI driver

[Jiang Liu]

Originally the ioapic PCI driver is designed to support IOAPIC hotplug,
but it never works because no architecture has implemented required
interface to support it. We plan to reimplement it as an ACPI driver
instead of PCI driver due to:
1) To support IOAPIC hotplug, an IOAPIC unit must have an companion
   ACPI device, but it may or may not be presented in PCI domain.
2) All other PCI devices have dependency on IOAPIC, so we must hot-add
   it before all other PCI devices and hot-remove it after all other
   PCI devices. So we need to explicitly control the order to add/remove
   IOAPIC devices.

So kill the ioapic PCI driver and will reimplement it as an ACPI driver.

Signed-off-by: Jiang Liu 
---
 drivers/pci/Kconfig  |7 ---
 drivers/pci/Makefile |2 -
 drivers/pci/ioapic.c |  121 --
 3 files changed, 130 deletions(-)
 delete mode 100644 drivers/pci/ioapic.c

diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 893503fa1782..39866d18004e 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -104,13 +104,6 @@ config PCI_PASID
 
  If unsure, say N.
 
-config PCI_IOAPIC
-   bool "PCI IO-APIC hotplug support" if X86
-   depends on PCI
-   depends on ACPI
-   depends on X86_IO_APIC
-   default !X86
-
 config PCI_LABEL
def_bool y if (DMI || ACPI)
select NLS
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index e04fe2d9df3b..73e4af400a5a 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -13,8 +13,6 @@ obj-$(CONFIG_PCI_QUIRKS) += quirks.o
 # Build PCI Express stuff if needed
 obj-$(CONFIG_PCIEPORTBUS) += pcie/
 
-obj-$(CONFIG_PCI_IOAPIC) += ioapic.o
-
 # Build the PCI Hotplug drivers if we were asked to
 obj-$(CONFIG_HOTPLUG_PCI) += hotplug/
 ifdef CONFIG_HOTPLUG_PCI
diff --git a/drivers/pci/ioapic.c b/drivers/pci/ioapic.c
deleted file mode 100644
index 6b2b7dddbbdb..
--- a/drivers/pci/ioapic.c
+++ /dev/null
@@ -1,121 +0,0 @@
-/*
- * IOAPIC/IOxAPIC/IOSAPIC driver
- *
- * Copyright (C) 2009 Fujitsu Limited.
- * (c) Copyright 2009 Hewlett-Packard Development Company, L.P.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-/*
- * This driver manages PCI I/O APICs added by hotplug after boot.  We try to
- * claim all I/O APIC PCI devices, but those present at boot were registered
- * when we parsed the ACPI MADT, so we'll fail when we try to re-register
- * them.
- */
-
-#include 
-#include 
-#include 
-#include 
-
-struct ioapic {
-   acpi_handle handle;
-   u32 gsi_base;
-};
-
-static int ioapic_probe(struct pci_dev *dev, const struct pci_device_id *ent)
-{
-   acpi_handle handle;
-   acpi_status status;
-   unsigned long long gsb;
-   struct ioapic *ioapic;
-   int ret;
-   char *type;
-   struct resource *res;
-
-   handle = ACPI_HANDLE(>dev);
-   if (!handle)
-   return -EINVAL;
-
-   status = acpi_evaluate_integer(handle, "_GSB", NULL, );
-   if (ACPI_FAILURE(status))
-   return -EINVAL;
-
-   /*
-* The previous code in acpiphp evaluated _MAT if _GSB failed, but
-* ACPI spec 4.0 sec 6.2.2 requires _GSB for hot-pluggable I/O APICs.
-*/
-
-   ioapic = kzalloc(sizeof(*ioapic), GFP_KERNEL);
-   if (!ioapic)
-   return -ENOMEM;
-
-   ioapic->handle = handle;
-   ioapic->gsi_base = (u32) gsb;
-
-   if (dev->class == PCI_CLASS_SYSTEM_PIC_IOAPIC)
-   type = "IOAPIC";
-   else
-   type = "IOxAPIC";
-
-   ret = pci_enable_device(dev);
-   if (ret < 0)
-   goto exit_free;
-
-   pci_set_master(dev);
-
-   if (pci_request_region(dev, 0, type))
-   goto exit_disable;
-
-   res = >resource[0];
-   if (acpi_register_ioapic(ioapic->handle, res->start, ioapic->gsi_base))
-   goto exit_release;
-
-   pci_set_drvdata(dev, ioapic);
-   dev_info(>dev, "%s at %pR, GSI %u\n", type, res, ioapic->gsi_base);
-   return 0;
-
-exit_release:
-   pci_release_region(dev, 0);
-exit_disable:
-   pci_disable_device(dev);
-exit_free:
-   kfree(ioapic);
-   return -ENODEV;
-}
-
-static void ioapic_remove(struct pci_dev *dev)
-{
-   struct ioapic *ioapic = pci_get_drvdata(dev);
-
-   acpi_unregister_ioapic(ioapic->handle, ioapic->gsi_base);
-   pci_release_region(dev, 0);
-   pci_disable_device(dev);
-   kfree(ioapic);
-}
-
-
-static DEFINE_PCI_DEVICE_TABLE(ioapic_devices) = {
-   { PCI_DEVICE_CLASS(PCI_CLASS_SYSTEM_PIC_IOAPIC, ~0) },
-   { PCI_DEVICE_CLASS(PCI_CLASS_SYSTEM_PIC_IOXAPIC, ~0) },
-   { }
-};
-MODULE_DEVICE_TABLE(pci, ioapic_devices);
-
-static struct pci_driver ioapic_driver = {
-   .name   = "ioapic",
-   .id_table   = 

[RFC Patch V2 16/16] x86, irq, ACPI: implement ACPI driver to support IOAPIC hotplug

[Jiang Liu]

Enable support of IOAPIC hotplug by:
1) reintroducing ACPI based IOAPIC driver
2) enhance pci_root driver to hook hotplug events

The ACPI IOAPIC driver is always enabled if system supports all of
ACPI, PCI and IOAPIC.

Signed-off-by: Jiang Liu 
---
 drivers/acpi/Kconfig|6 ++
 drivers/acpi/Makefile   |1 +
 drivers/acpi/internal.h |7 ++
 drivers/acpi/ioapic.c   |  231 +++
 drivers/acpi/pci_root.c |3 +
 5 files changed, 248 insertions(+)
 create mode 100644 drivers/acpi/ioapic.c

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index ab686b310100..2d0ed9da6fea 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -292,6 +292,12 @@ config ACPI_HOTPLUG_MEMORY
  To compile this driver as a module, choose M here:
  the module will be called acpi_memhotplug.
 
+config ACPI_HOTPLUG_IOAPIC
+   bool
+   depends on PCI
+   depends on X86_IO_APIC
+   default y
+
 config ACPI_SBS
tristate "Smart Battery System"
depends on X86
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index d922febd9164..b85b226a7f49 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_ACPI_PROCESSOR)  += processor.o
 obj-$(CONFIG_ACPI_CONTAINER)   += container.o
 obj-$(CONFIG_ACPI_THERMAL) += thermal.o
 obj-$(CONFIG_ACPI_HOTPLUG_MEMORY) += acpi_memhotplug.o
+obj-$(CONFIG_ACPI_HOTPLUG_IOAPIC) += ioapic.o
 obj-$(CONFIG_ACPI_BATTERY) += battery.o
 obj-$(CONFIG_ACPI_SBS) += sbshc.o
 obj-$(CONFIG_ACPI_SBS) += sbs.o
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 957391306cbf..e8023cd81da3 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -52,6 +52,13 @@ void acpi_memory_hotplug_init(void);
 #else
 static inline void acpi_memory_hotplug_init(void) {}
 #endif
+#ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
+int acpi_ioapic_add(struct acpi_pci_root *root);
+int acpi_ioapic_remove(struct acpi_pci_root *root);
+#else
+static inline int acpi_ioapic_add(struct acpi_pci_root *root) { return 0; }
+static inline int acpi_ioapic_remove(struct acpi_pci_root *root) { return 0; }
+#endif
 #ifdef CONFIG_X86
 void acpi_cmos_rtc_init(void);
 #else
diff --git a/drivers/acpi/ioapic.c b/drivers/acpi/ioapic.c
new file mode 100644
index ..3c9442899782
--- /dev/null
+++ b/drivers/acpi/ioapic.c
@@ -0,0 +1,231 @@
+/*
+ * IOAPIC/IOxAPIC/IOSAPIC driver
+ *
+ * Copyright (C) 2009 Fujitsu Limited.
+ * (c) Copyright 2009 Hewlett-Packard Development Company, L.P.
+ *
+ * Copyright (C) 2014 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Based on original drivers/pci/ioapic.c
+ * Yinghai Lu 
+ * Jiang Liu 
+ */
+
+/*
+ * This driver manages I/O APICs added by hotplug after boot.
+ * We try to claim all I/O APIC devices, but those present at boot were
+ * registered when we parsed the ACPI MADT, so we'll fail when we try to
+ * re-register them.
+ */
+
+#define pr_fmt(fmt) "ACPI : IOAPIC: " fmt
+
+#include 
+#include 
+#include 
+#include 
+
+struct acpi_pci_ioapic {
+   acpi_handle root_handle;
+   acpi_handle handle;
+   u32 gsi_base;
+   struct resource res;
+   struct pci_dev  *pdev;
+   struct list_head list;
+};
+
+static LIST_HEAD(ioapic_list);
+static DEFINE_MUTEX(ioapic_list_lock);
+
+static acpi_status setup_res(struct acpi_resource *acpi_res, void *data)
+{
+   struct resource *res = data;
+   struct acpi_resource_address64 addr;
+   acpi_status status;
+
+   status = acpi_mem_addr_resource_to_address64(acpi_res, );
+   if (!ACPI_SUCCESS(status))
+   return AE_OK;
+
+   if (addr.resource_type != ACPI_MEMORY_RANGE ||
+   addr.info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
+   return AE_OK;
+
+   res->flags = IORESOURCE_MEM;
+   res->start = addr.minimum + addr.translation_offset;
+   res->end = addr.maximum + addr.translation_offset;
+
+   return AE_OK;
+}
+
+static bool acpi_is_ioapic(acpi_handle handle, char **type)
+{
+   acpi_status status;
+   struct acpi_device_info *info;
+   char *hid = NULL;
+   bool match = false;
+
+   if (!acpi_has_method(handle, "_GSB"))
+   return false;
+
+   status = acpi_get_object_info(handle, );
+   if (ACPI_SUCCESS(status)) {
+   if (info->valid & ACPI_VALID_HID)
+   hid = info->hardware_id.string;
+   if (hid) {
+   if (strcmp(hid, "ACPI0009") == 0) {
+   *type = "IOxAPIC";
+   match = true;
+   } else if (strcmp(hid, "ACPI000A") == 0) {
+   *type = "IOAPIC";
+   match = 

[RFC Patch V2 09/16] x86, irq: remove __init marker for functions will be used by IOAPIC hotplug

[Jiang Liu]

Signed-off-by: Jiang Liu 
---
 arch/x86/include/asm/io_apic.h |4 ++--
 arch/x86/kernel/apic/io_apic.c |   14 +++---
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 0aeed5ca356e..0b31aebd9405 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -188,8 +188,8 @@ extern int mp_find_ioapic_pin(int ioapic, u32 gsi);
 extern u32 mp_pin_to_gsi(int ioapic, int pin);
 extern int mp_map_gsi_to_irq(u32 gsi, unsigned int flags);
 extern void mp_unmap_irq(int irq);
-extern void __init mp_register_ioapic(int id, u32 address, u32 gsi_base,
- struct ioapic_domain_cfg *cfg);
+extern void mp_register_ioapic(int id, u32 address, u32 gsi_base,
+  struct ioapic_domain_cfg *cfg);
 extern int mp_irqdomain_map(struct irq_domain *domain, unsigned int virq,
irq_hw_number_t hwirq);
 extern void mp_irqdomain_unmap(struct irq_domain *domain, unsigned int virq);
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index e56bb94cd32a..15a7d36d4a9c 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3445,7 +3445,7 @@ io_apic_setup_irq_pin(unsigned int irq, int node, struct 
io_apic_irq_attr *attr)
return ret;
 }
 
-static int __init io_apic_get_redir_entries(int ioapic)
+static int io_apic_get_redir_entries(int ioapic)
 {
union IO_APIC_reg_01reg_01;
unsigned long flags;
@@ -3491,7 +3491,7 @@ int __init arch_probe_nr_irqs(void)
 }
 
 #ifdef CONFIG_X86_32
-static int __init io_apic_get_unique_id(int ioapic, int apic_id)
+static int io_apic_get_unique_id(int ioapic, int apic_id)
 {
union IO_APIC_reg_00 reg_00;
static physid_mask_t apic_id_map = PHYSID_MASK_NONE;
@@ -3617,7 +3617,7 @@ static u8 io_apic_unique_id(int idx, u8 id)
 }
 #endif
 
-static int __init io_apic_get_version(int ioapic)
+static int io_apic_get_version(int ioapic)
 {
union IO_APIC_reg_01reg_01;
unsigned long flags;
@@ -3821,7 +3821,7 @@ int mp_find_ioapic_pin(int ioapic, u32 gsi)
return gsi - gsi_cfg->gsi_base;
 }
 
-static __init int bad_ioapic(unsigned long address)
+static int bad_ioapic(unsigned long address)
 {
if (nr_ioapics >= MAX_IO_APICS) {
pr_warn("WARNING: Max # of I/O APICs (%d) exceeded (found %d), 
skipping\n",
@@ -3835,7 +3835,7 @@ static __init int bad_ioapic(unsigned long address)
return 0;
 }
 
-static __init int bad_ioapic_register(int idx)
+static int bad_ioapic_register(int idx)
 {
union IO_APIC_reg_00 reg_00;
union IO_APIC_reg_01 reg_01;
@@ -3854,8 +3854,8 @@ static __init int bad_ioapic_register(int idx)
return 0;
 }
 
-void __init mp_register_ioapic(int id, u32 address, u32 gsi_base,
-  struct ioapic_domain_cfg *cfg)
+void mp_register_ioapic(int id, u32 address, u32 gsi_base,
+   struct ioapic_domain_cfg *cfg)
 {
int idx = 0;
int entries;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC Patch V2 10/16] x86, irq: refine mp_register_ioapic() to prepare for IOAPIC hotplug

[Jiang Liu]

Refine mp_register_ioapic() to prepare for IOAPIC hotplug by:
1) change return value from void to int.
2) check for gsi range conflicts
3) check for IOAPIC physical address conflicts
4) enhance the way to allocate IOAPIC index

Signed-off-by: Jiang Liu 
---
 arch/x86/include/asm/io_apic.h |4 +-
 arch/x86/kernel/apic/io_apic.c |   80 
 2 files changed, 51 insertions(+), 33 deletions(-)

diff --git a/arch/x86/include/asm/io_apic.h b/arch/x86/include/asm/io_apic.h
index 0b31aebd9405..94d05bd6586f 100644
--- a/arch/x86/include/asm/io_apic.h
+++ b/arch/x86/include/asm/io_apic.h
@@ -188,8 +188,8 @@ extern int mp_find_ioapic_pin(int ioapic, u32 gsi);
 extern u32 mp_pin_to_gsi(int ioapic, int pin);
 extern int mp_map_gsi_to_irq(u32 gsi, unsigned int flags);
 extern void mp_unmap_irq(int irq);
-extern void mp_register_ioapic(int id, u32 address, u32 gsi_base,
-  struct ioapic_domain_cfg *cfg);
+extern int mp_register_ioapic(int id, u32 address, u32 gsi_base,
+ struct ioapic_domain_cfg *cfg);
 extern int mp_irqdomain_map(struct irq_domain *domain, unsigned int virq,
irq_hw_number_t hwirq);
 extern void mp_irqdomain_unmap(struct irq_domain *domain, unsigned int virq);
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 15a7d36d4a9c..e1cce02e9f55 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3821,20 +3821,6 @@ int mp_find_ioapic_pin(int ioapic, u32 gsi)
return gsi - gsi_cfg->gsi_base;
 }
 
-static int bad_ioapic(unsigned long address)
-{
-   if (nr_ioapics >= MAX_IO_APICS) {
-   pr_warn("WARNING: Max # of I/O APICs (%d) exceeded (found %d), 
skipping\n",
-   MAX_IO_APICS, nr_ioapics);
-   return 1;
-   }
-   if (!address) {
-   pr_warn("WARNING: Bogus (zero) I/O APIC address found in table, 
skipping!\n");
-   return 1;
-   }
-   return 0;
-}
-
 static int bad_ioapic_register(int idx)
 {
union IO_APIC_reg_00 reg_00;
@@ -3854,29 +3840,44 @@ static int bad_ioapic_register(int idx)
return 0;
 }
 
-void mp_register_ioapic(int id, u32 address, u32 gsi_base,
-   struct ioapic_domain_cfg *cfg)
+static int find_free_ioapic_entry(void)
 {
-   int idx = 0;
-   int entries;
+   return nr_ioapics;
+}
+
+int mp_register_ioapic(int id, u32 address, u32 gsi_base,
+  struct ioapic_domain_cfg *cfg)
+{
+   u32 gsi_end;
+   int idx, ioapic, entries;
struct mp_ioapic_gsi *gsi_cfg;
 
-   if (bad_ioapic(address))
-   return;
+   if (!address) {
+   pr_warn("Bogus (zero) I/O APIC address found, skipping!\n");
+   return -EINVAL;
+   }
+   for_each_ioapic(ioapic)
+   if (ioapics[ioapic].mp_config.apicaddr == address) {
+   pr_warn("address 0x%x conflicts with IOAPIC%d\n",
+   address, ioapic);
+   return -EEXIST;
+   }
 
-   idx = nr_ioapics;
+   idx = find_free_ioapic_entry();
+   if (idx >= MAX_IO_APICS) {
+   pr_warn("Max # of I/O APICs (%d) exceeded (found %d), 
skipping\n",
+   MAX_IO_APICS, idx);
+   return -ENOSPC;
+   }
 
ioapics[idx].mp_config.type = MP_IOAPIC;
ioapics[idx].mp_config.flags = MPC_APIC_USABLE;
ioapics[idx].mp_config.apicaddr = address;
-   ioapics[idx].irqdomain = NULL;
-   ioapics[idx].irqdomain_cfg = *cfg;
 
set_fixmap_nocache(FIX_IO_APIC_BASE_0 + idx, address);
-
if (bad_ioapic_register(idx)) {
clear_fixmap(FIX_IO_APIC_BASE_0 + idx);
-   return;
+   return -ENODEV;
}
 
ioapics[idx].mp_config.apicid = io_apic_unique_id(idx, id);
@@ -3887,24 +3888,41 @@ void mp_register_ioapic(int id, u32 address, u32 
gsi_base,
 * and to prevent reprogramming of IOAPIC pins (PCI GSIs).
 */
entries = io_apic_get_redir_entries(idx);
+   gsi_end = gsi_base + entries - 1;
+   for_each_ioapic(ioapic) {
+   gsi_cfg = mp_ioapic_gsi_routing(ioapic);
+   if ((gsi_base >= gsi_cfg->gsi_base &&
+gsi_base <= gsi_cfg->gsi_end) ||
+   (gsi_end >= gsi_cfg->gsi_base &&
+gsi_end <= gsi_cfg->gsi_end)) {
+   pr_warn("GSI range [%u-%u] for new IOAPIC conflicts 
with GSI[%u-%u]\n",
+   gsi_base, gsi_end,
+   gsi_cfg->gsi_base, gsi_cfg->gsi_end);
+   clear_fixmap(FIX_IO_APIC_BASE_0 + idx);
+   return -ENOSPC;
+   }
+   }
gsi_cfg = mp_ioapic_gsi_routing(idx);
gsi_cfg->gsi_base = gsi_base;
-   gsi_cfg->gsi_end = gsi_base + 

[RFC Patch V2 07/16] x86, irq, ACPI: protect acpi_pci_irq_enable() from reentrance

[Jiang Liu]

Function acpi_pci_irq_enable() may be called twice for each PCI device
present at boot time as below:
1) pci_acpi_init()
--> acpi_pci_irq_enable()
2) pci_enable_device()
--> pcibios_enable_device()
--> acpi_pci_irq_enable()

So protect acpi_pci_irq_enable() from reentrance to correctly manage
IOAPIC pin reference count.

Signed-off-by: Jiang Liu 
---
 drivers/acpi/pci_irq.c |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/pci_irq.c b/drivers/acpi/pci_irq.c
index 6ba463ceccc6..9d2ebd5fd9aa 100644
--- a/drivers/acpi/pci_irq.c
+++ b/drivers/acpi/pci_irq.c
@@ -413,6 +413,9 @@ int acpi_pci_irq_enable(struct pci_dev *dev)
return 0;
}
 
+   if (dev->irq > 0)
+   return 0;
+
entry = acpi_pci_irq_lookup(dev, pin);
if (!entry) {
/*
@@ -498,6 +501,8 @@ void acpi_pci_irq_disable(struct pci_dev *dev)
 */
 
dev_dbg(>dev, "PCI INT %c disabled\n", pin_name(pin));
-   if (gsi >= 0 && dev->irq > 0)
+   if (gsi >= 0 && dev->irq > 0) {
acpi_unregister_gsi(gsi);
+   dev->irq = 0;
+   }
 }
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC Patch V2 12/16] x86, irq, ACPI: implement interface to support ACPI based IOAPIC hot-addition

[Jiang Liu]

Implement acpi_register_ioapic() and enhance mp_register_ioapic()
to support ACPI based IOAPIC hot-addition.

Signed-off-by: Jiang Liu 
---
 arch/x86/kernel/acpi/boot.c|   37 +++--
 arch/x86/kernel/apic/io_apic.c |   27 ---
 2 files changed, 59 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 120b573f1e96..85caf3221cde 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -768,8 +768,41 @@ EXPORT_SYMBOL(acpi_unmap_lsapic);
 
 int acpi_register_ioapic(acpi_handle handle, u64 phys_addr, u32 gsi_base)
 {
-   /* TBD */
-   return -EINVAL;
+   int ret = -ENOSYS;
+#ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
+   int ioapic_id;
+   u64 addr;
+   struct ioapic_domain_cfg cfg = {
+   .type = IOAPIC_DOMAIN_DYNAMIC,
+   .ops = _irqdomain_ops,
+   };
+
+   ioapic_id = acpi_get_ioapic_id(handle, gsi_base, );
+   if (ioapic_id >= 0) {
+   if (addr != phys_addr) {
+   acpi_handle_warn(handle,
+   "IOAPIC physical address doesn't match.\n");
+   return -EINVAL;
+   }
+   } else  {
+   unsigned long long uid;
+   acpi_status status;
+
+   status = acpi_evaluate_integer(handle, METHOD_NAME__UID,
+  NULL, );
+   if (ACPI_FAILURE(status)) {
+   acpi_handle_warn(handle, "failed to get IOAPIC ID.\n");
+   return -EINVAL;
+   }
+   ioapic_id = (int)uid;
+   }
+
+   down_write(_ioapic_rwsem);
+   ret  = mp_register_ioapic(ioapic_id, phys_addr, gsi_base, );
+   up_write(_ioapic_rwsem);
+#endif
+
+   return ret;
 }
 
 EXPORT_SYMBOL(acpi_register_ioapic);
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index e1cce02e9f55..d26fd3ac1b4b 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3842,7 +3842,13 @@ static int bad_ioapic_register(int idx)
 
 static int find_free_ioapic_entry(void)
 {
-   return nr_ioapics;
+   int idx;
+
+   for (idx = 0; idx < MAX_IO_APICS; idx++)
+   if (ioapics[idx].nr_registers == 0)
+   return idx;
+
+   return MAX_IO_APICS;
 }
 
 int mp_register_ioapic(int id, u32 address, u32 gsi_base,
@@ -3858,8 +3864,15 @@ int mp_register_ioapic(int id, u32 address, u32 gsi_base,
}
for_each_ioapic(ioapic)
if (ioapics[ioapic].mp_config.apicaddr == address) {
-   pr_warn("address 0x%x conflicts with IOAPIC%d\n",
-   address, ioapic);
+   /*
+* IOAPIC unit may also be visible in PCI scope.
+* When ioapic PCI driver's probe() is called,
+* the IOAPIC unit may have already been initialized
+* at boot time.
+*/
+   if (!ioapic_initialized)
+   pr_warn("address 0x%x conflicts with 
IOAPIC%d\n",
+   address, ioapic);
return -EEXIST;
}
 
@@ -3909,6 +3922,14 @@ int mp_register_ioapic(int id, u32 address, u32 gsi_base,
ioapics[idx].irqdomain = NULL;
ioapics[idx].irqdomain_cfg = *cfg;
 
+   if (ioapic_initialized) {
+   if (mp_irqdomain_create(idx)) {
+   clear_fixmap(FIX_IO_APIC_BASE_0 + idx);
+   return -ENOMEM;
+   }
+   alloc_ioapic_saved_registers(idx);
+   }
+
if (gsi_cfg->gsi_end >= gsi_top)
gsi_top = gsi_cfg->gsi_end + 1;
if (nr_ioapics <= idx)
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC Patch V2 08/16] PCI: kill wrong warning message in pcieport driver

[Jiang Liu]

For hot-added PCIe ports, it always generates a warning message on x86
platforms when binding to pcieport driver as:
"device [8086:0e0b] has invalid IRQ; check vendor BIOS".

It's due to that we check pci_dev->irq before actually allocating IRQ
number for the PCI device:
if (!dev->irq && dev->pin) {
dev_warn(>dev, "device [%04x:%04x] has invalid IRQ; "
 "check vendor BIOS\n", dev->vendor, dev->device);
}
status = pcie_port_device_register(dev);
-->pci_enable_device(dev);
-->pci_enable_device_flags()
-->do_pci_enable_device()
-->pcibios_enable_device()
-->pcibios_enable_irq()

This warning message isn't generated for PCIe ports present at boot time
because x86 arch code has called acpi_pci_irq_enable() in pci_acpi_init()
for each PCI device for safety.

Signed-off-by: Jiang Liu 
---
 drivers/pci/pcie/portdrv_pci.c |4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/pci/pcie/portdrv_pci.c b/drivers/pci/pcie/portdrv_pci.c
index 0d8fdc48e642..0e35f9670066 100644
--- a/drivers/pci/pcie/portdrv_pci.c
+++ b/drivers/pci/pcie/portdrv_pci.c
@@ -203,10 +203,6 @@ static int pcie_portdrv_probe(struct pci_dev *dev,
 (pci_pcie_type(dev) != PCI_EXP_TYPE_DOWNSTREAM)))
return -ENODEV;
 
-   if (!dev->irq && dev->pin) {
-   dev_warn(>dev, "device [%04x:%04x] has invalid IRQ; "
-"check vendor BIOS\n", dev->vendor, dev->device);
-   }
status = pcie_port_device_register(dev);
if (status)
return status;
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC Patch V2 05/16] ACPI: Move acpi_get_cpuid() to separated file

[Jiang Liu]

From: Yinghai Lu 

Will need to reuse searching MADT for ioapic, but should add
related function like acpi_get_ioapic_id to processor_core.c
to pollute the file.

Move related cpu apic id search to separated file.

Signed-off-by: Yinghai Lu 
Signed-off-by: Jiang Liu 
---
 drivers/acpi/Makefile |1 +
 drivers/acpi/apic_id.c|  202 +
 drivers/acpi/processor_core.c |  193 ---
 include/acpi/processor.h  |3 -
 include/linux/acpi.h  |4 +
 5 files changed, 207 insertions(+), 196 deletions(-)
 create mode 100644 drivers/acpi/apic_id.c

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 0331f91d56e6..d922febd9164 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -34,6 +34,7 @@ acpi-$(CONFIG_ACPI_SLEEP) += proc.o
 acpi-y += bus.o glue.o
 acpi-y += scan.o
 acpi-y += resource.o
+acpi-y += apic_id.o
 acpi-y += acpi_processor.o
 acpi-y += processor_core.o
 acpi-y += ec.o
diff --git a/drivers/acpi/apic_id.c b/drivers/acpi/apic_id.c
new file mode 100644
index ..ac3b10a9f92d
--- /dev/null
+++ b/drivers/acpi/apic_id.c
@@ -0,0 +1,202 @@
+/*
+ * Copyright (C) 2005 Intel Corporation
+ * Copyright (C) 2009 Hewlett-Packard Development Company, L.P.
+ * All routines dealing with CPU APIC ID are moved from processor_core.c
+ */
+#include 
+#include 
+#include 
+
+#include "internal.h"
+
+static int map_lapic_id(struct acpi_subtable_header *entry,
+u32 acpi_id, int *apic_id)
+{
+   struct acpi_madt_local_apic *lapic =
+   (struct acpi_madt_local_apic *)entry;
+
+   if (!(lapic->lapic_flags & ACPI_MADT_ENABLED))
+   return -ENODEV;
+
+   if (lapic->processor_id != acpi_id)
+   return -EINVAL;
+
+   *apic_id = lapic->id;
+   return 0;
+}
+
+static int map_x2apic_id(struct acpi_subtable_header *entry,
+int device_declaration, u32 acpi_id, int *apic_id)
+{
+   struct acpi_madt_local_x2apic *apic =
+   (struct acpi_madt_local_x2apic *)entry;
+
+   if (!(apic->lapic_flags & ACPI_MADT_ENABLED))
+   return -ENODEV;
+
+   if (device_declaration && (apic->uid == acpi_id)) {
+   *apic_id = apic->local_apic_id;
+   return 0;
+   }
+
+   return -EINVAL;
+}
+
+static int map_lsapic_id(struct acpi_subtable_header *entry,
+   int device_declaration, u32 acpi_id, int *apic_id)
+{
+   struct acpi_madt_local_sapic *lsapic =
+   (struct acpi_madt_local_sapic *)entry;
+
+   if (!(lsapic->lapic_flags & ACPI_MADT_ENABLED))
+   return -ENODEV;
+
+   if (device_declaration) {
+   if ((entry->length < 16) || (lsapic->uid != acpi_id))
+   return -EINVAL;
+   } else if (lsapic->processor_id != acpi_id)
+   return -EINVAL;
+
+   *apic_id = (lsapic->id << 8) | lsapic->eid;
+   return 0;
+}
+
+static int map_madt_entry(int type, u32 acpi_id)
+{
+   unsigned long madt_end, entry;
+   static struct acpi_table_madt *madt;
+   static int read_madt;
+   int apic_id = -1;
+
+   if (!read_madt) {
+   if (ACPI_FAILURE(acpi_get_table(ACPI_SIG_MADT, 0,
+   (struct acpi_table_header **
+   madt = NULL;
+   read_madt++;
+   }
+
+   if (!madt)
+   return apic_id;
+
+   entry = (unsigned long)madt;
+   madt_end = entry + madt->header.length;
+
+   /* Parse all entries looking for a match. */
+
+   entry += sizeof(struct acpi_table_madt);
+   while (entry + sizeof(struct acpi_subtable_header) < madt_end) {
+   struct acpi_subtable_header *header =
+   (struct acpi_subtable_header *)entry;
+   if (header->type == ACPI_MADT_TYPE_LOCAL_APIC) {
+   if (!map_lapic_id(header, acpi_id, _id))
+   break;
+   } else if (header->type == ACPI_MADT_TYPE_LOCAL_X2APIC) {
+   if (!map_x2apic_id(header, type, acpi_id, _id))
+   break;
+   } else if (header->type == ACPI_MADT_TYPE_LOCAL_SAPIC) {
+   if (!map_lsapic_id(header, type, acpi_id, _id))
+   break;
+   }
+   entry += header->length;
+   }
+   return apic_id;
+}
+
+static int map_mat_entry(acpi_handle handle, int type, u32 acpi_id)
+{
+   struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+   union acpi_object *obj;
+   struct acpi_subtable_header *header;
+   int apic_id = -1;
+
+   if (ACPI_FAILURE(acpi_evaluate_object(handle, "_MAT", 

[RFC Patch V2 04/16] ACPI: Make map_mat_entry handle x2apic entry

[Jiang Liu]

From: Yinghai Lu 

Now we have map_madt_entry/MADT to handle x2apic, but does not do
that with map_mat_entry _MAT.

For hotplug on system with x2apic only support, we need to add
support for x2apic map in _MAT.

Signed-off-by: Yinghai Lu 
Signed-off-by: Jiang Liu 
---
 drivers/acpi/processor_core.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index 71e2065639a6..c8a991e9d257 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -133,6 +133,8 @@ static int map_mat_entry(acpi_handle handle, int type, u32 
acpi_id)
header = (struct acpi_subtable_header *)obj->buffer.pointer;
if (header->type == ACPI_MADT_TYPE_LOCAL_APIC) {
map_lapic_id(header, acpi_id, _id);
+   } else if (header->type == ACPI_MADT_TYPE_LOCAL_X2APIC) {
+   map_x2apic_id(header, type, acpi_id, _id);
} else if (header->type == ACPI_MADT_TYPE_LOCAL_SAPIC) {
map_lsapic_id(header, type, acpi_id, _id);
}
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC Patch V2 00/16] Enable support of IOAPIC hotplug on x86 platforms

[Jiang Liu]

This patch set enhances IOAPIC core and ACPI drivers to support IOAPIC
hotplug on x86 platforms. It's based on another patch set "use irqdomain
to dynamically allocate IRQ for IOAPIC" at
https://lkml.org/lkml/2014/6/9/44

You may pull it from 
https://github.com/jiangliu/linux.git ioapic/hotplug_v2

We have pick up several patches from Yinghai's original IOAPIC hotplug
patch set and reimplemented IOAPIC driver as an ACPI driver instead of
a PCI driver.

It has been tested on a 4-socket Intel SDV with socket hot-addition
capability. Any suggestions are welcomed!

Jiang Liu (10):
  x86, irq, ACPI: protect acpi_pci_irq_enable() from reentrance
  PCI: kill wrong warning message in pcieport driver
  x86, irq: remove __init marker for functions will be used by IOAPIC
hotplug
  x86, irq: refine mp_register_ioapic() to prepare for IOAPIC hotplug
  x86, irq, ACPI: introduce a rwsem to protect IOAPIC operations from
hotplug
  x86, irq, ACPI: implement interface to support ACPI based IOAPIC
hot-addition
  x86, irq, ACPI: implement interface to support ACPI based IOAPIC
hot-removal
  x86, irq: introduce helper to check whether an IOAPIC has been
registered
  pci, ioapic: kill ioapic PCI driver
  x86, irq, ACPI: implement ACPI driver to support IOAPIC hotplug

Yinghai Lu (6):
  x86, irq: Split out alloc_ioapic_save_registers()
  x86, ioapic: Find usable ioapic id for 64bit.
  ACPI, x86/PCI: Move resource_to_addr() to acpi generic
  ACPI: Make map_mat_entry handle x2apic entry
  ACPI: Move acpi_get_cpuid() to separated file
  ACPI, ioapic: Add acpi_get_ioapic_id()

 arch/x86/include/asm/io_apic.h |6 +-
 arch/x86/kernel/acpi/boot.c|   74 +-
 arch/x86/kernel/apic/io_apic.c |  235 +---
 arch/x86/pci/acpi.c|   50 +--
 drivers/acpi/Kconfig   |6 +
 drivers/acpi/Makefile  |2 +
 drivers/acpi/apic_id.c |  295 
 drivers/acpi/internal.h|7 +
 drivers/acpi/ioapic.c  |  231 +++
 drivers/acpi/pci_irq.c |7 +-
 drivers/acpi/pci_root.c|3 +
 drivers/acpi/processor_core.c  |  191 --
 drivers/acpi/resource.c|   46 +++
 drivers/pci/Kconfig|7 -
 drivers/pci/Makefile   |2 -
 drivers/pci/ioapic.c   |  121 
 drivers/pci/pcie/portdrv_pci.c |4 -
 include/acpi/processor.h   |3 -
 include/linux/acpi.h   |   11 ++
 19 files changed, 868 insertions(+), 433 deletions(-)
 create mode 100644 drivers/acpi/apic_id.c
 create mode 100644 drivers/acpi/ioapic.c
 delete mode 100644 drivers/pci/ioapic.c

-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC Patch V2 01/16] x86, irq: Split out alloc_ioapic_save_registers()

[Jiang Liu]

From: Yinghai Lu 

Split alloc_ioapic_save_registers() from early_irq_init(),
so it will be used per ioapic.

Will call that later for hot-added ioapic controller.

Signed-off-by: Yinghai Lu 
Signed-off-by: Jiang Liu 
Cc: Joerg Roedel 
Cc: Konrad Rzeszutek Wilk 
Cc: Sebastian Andrzej Siewior 
---
 arch/x86/kernel/apic/io_apic.c |   22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 26490336ef6f..e97ec28f5269 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -237,6 +237,19 @@ static struct irq_pin_list *alloc_irq_pin_list(int node)
return kzalloc_node(sizeof(struct irq_pin_list), GFP_KERNEL, node);
 }
 
+static void alloc_ioapic_saved_registers(int idx)
+{
+   size_t size;
+
+   if (ioapics[idx].saved_registers)
+   return;
+
+   size = sizeof(struct IO_APIC_route_entry) * ioapics[idx].nr_registers;
+   ioapics[idx].saved_registers = kzalloc(size, GFP_KERNEL);
+   if (!ioapics[idx].saved_registers)
+   pr_err("IOAPIC %d: suspend/resume impossible!\n", idx);
+}
+
 int __init arch_early_irq_init(void)
 {
struct irq_cfg *cfg;
@@ -245,13 +258,8 @@ int __init arch_early_irq_init(void)
if (!nr_legacy_irqs())
io_apic_irqs = ~0UL;
 
-   for_each_ioapic(i) {
-   ioapics[i].saved_registers =
-   kzalloc(sizeof(struct IO_APIC_route_entry) *
-   ioapics[i].nr_registers, GFP_KERNEL);
-   if (!ioapics[i].saved_registers)
-   pr_err("IOAPIC %d: suspend/resume impossible!\n", i);
-   }
+   for_each_ioapic(i)
+   alloc_ioapic_saved_registers(i);
 
/*
 * For legacy IRQ's, start with assigning irq0 to irq15 to
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/6] KVM: x86: Wrong emulation on 'xadd X, X'

[Paolo Bonzini]

Il 16/06/2014 19:38, Bandan Das ha scritto:

Nadav Amit  writes:


The emulator does not emulate the xadd instruction correctly if the two
operands are the same.  In this (unlikely) situation the result should be the
sum of X and X (2X) when it is currently X.  The solution is to first perform
writeback to the source, before writing to the destination.  The only
instruction which should be affected is xadd, as the other instructions that
perform writeback to the source use the extended accumlator (e.g., RAX:RDX).

Signed-off-by: Nadav Amit 
---
 arch/x86/kvm/emulate.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index f0b0a10..3c8d867 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -4711,17 +4711,17 @@ special_insn:
goto done;

 writeback:
-   if (!(ctxt->d & NoWrite)) {
-   rc = writeback(ctxt, >dst);
-   if (rc != X86EMUL_CONTINUE)
-   goto done;
-   }
if (ctxt->d & SrcWrite) {
BUG_ON(ctxt->src.type == OP_MEM || ctxt->src.type == 
OP_MEM_STR);

While we are here, I think we should replace this BUG_ON with a warning
and return X86EMUL_UNHANDLEABLE if the condition is true.


Sure, please post a patch and I'll apply it right away.

Paolo

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1 RESEND] fs/ceph/export.c: add static to local function

[Fabian Frederick]

On Mon, 16 Jun 2014 17:02:17 -0700 (PDT)
David Rientjes  wrote:

> On Sun, 15 Jun 2014, Fabian Frederick wrote:
> 
> > ceph_get_parent is only used in fs/ceph/export.c
> > 
> > Cc: Sage Weil 
> > Cc: Andrew Morton 
> > Signed-off-by: Fabian Frederick 
> > ---
> >  fs/ceph/export.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/fs/ceph/export.c b/fs/ceph/export.c
> > index 00d6af6..8d7d782 100644
> > --- a/fs/ceph/export.c
> > +++ b/fs/ceph/export.c
> > @@ -169,7 +169,7 @@ static struct dentry *__get_parent(struct super_block 
> > *sb,
> > return dentry;
> >  }
> >  
> > -struct dentry *ceph_get_parent(struct dentry *child)
> > +static struct dentry *ceph_get_parent(struct dentry *child)
> >  {
> > /* don't re-export snaps */
> > if (ceph_snap(child->d_inode) != CEPH_NOSNAP)
> 
> Not sure what tree you're modifying, this is fixed by commit e84be11c5360 
> ("ceph: ceph_get_parent() can be static") in Linus's tree.
Strange, I sent first version some weeks ago and it wasn't there two days ago.
Maybe I missed a pull :)

Thanks,
Fabian 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mm/vmscan.c: fix an implementation flaw in proportional scanning

[Chen Yucong]

Via https://lkml.org/lkml/2013/4/10/897, we can know that the relative design
idea is to keep

scan_target[anon] : scan_target[file]
== really_scanned_num[anon] : really_scanned_num[file]

But we can find the following snippet in shrink_lruvec():

if (nr_file > nr_anon) {
...
} else {
...
}

However, the above code fragment broke the design idea. We can assume:

  nr[LRU_ACTIVE_FILE] = 30
  nr[LRU_INACTIVE_FILE] = 30
  nr[LRU_ACTIVE_ANON] = 0
  nr[LRU_INACTIVE_ANON] = 40

When the value of (nr_reclaimed < nr_to_reclaim) become false, there are
the following results:

  nr[LRU_ACTIVE_FILE] = 15
  nr[LRU_INACTIVE_FILE] = 15
  nr[LRU_ACTIVE_ANON] = 0
  nr[LRU_INACTIVE_ANON] = 25
  nr_file = 30
  nr_anon = 25
  file_percent = 30 / 60 = 0.5
  anon_percent = 25 / 40 = 0.65

According to the above design idea, we should scan some pages from ANON,
but in fact we execute the an error code path due to "if (nr_file > nr_anon)".
In this way, nr[lru] is likely to be a negative number. Luckily,
"nr[lru] -= min(nr[lru], nr_scanned)" can help us to filter this situation,
but it has rebelled against our design idea.

Signed-off-by: Chen Yucong 
---
 mm/vmscan.c |   39 ++-
 1 file changed, 18 insertions(+), 21 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index a8ffe4e..2c35e34 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2057,8 +2057,7 @@ out:
 static void shrink_lruvec(struct lruvec *lruvec, struct scan_control *sc)
 {
unsigned long nr[NR_LRU_LISTS];
-   unsigned long targets[NR_LRU_LISTS];
-   unsigned long nr_to_scan;
+   unsigned long file_target, anon_target;
enum lru_list lru;
unsigned long nr_reclaimed = 0;
unsigned long nr_to_reclaim = sc->nr_to_reclaim;
@@ -2067,8 +2066,8 @@ static void shrink_lruvec(struct lruvec *lruvec, struct 
scan_control *sc)
 
get_scan_count(lruvec, sc, nr);
 
-   /* Record the original scan target for proportional adjustments later */
-   memcpy(targets, nr, sizeof(nr));
+   file_target = nr[LRU_INACTIVE_FILE] + nr[LRU_ACTIVE_FILE];
+   anon_target = nr[LRU_INACTIVE_ANON] + nr[LRU_ACTIVE_ANON];
 
/*
 * Global reclaiming within direct reclaim at DEF_PRIORITY is a normal
@@ -2087,8 +2086,8 @@ static void shrink_lruvec(struct lruvec *lruvec, struct 
scan_control *sc)
blk_start_plug();
while (nr[LRU_INACTIVE_ANON] || nr[LRU_ACTIVE_FILE] ||
nr[LRU_INACTIVE_FILE]) {
-   unsigned long nr_anon, nr_file, percentage;
-   unsigned long nr_scanned;
+   unsigned long nr_anon, nr_file, file_percent, anon_percent;
+   unsigned long nr_to_scan, nr_scanned, percentage;
 
for_each_evictable_lru(lru) {
if (nr[lru]) {
@@ -2122,16 +2121,19 @@ static void shrink_lruvec(struct lruvec *lruvec, struct 
scan_control *sc)
if (!nr_file || !nr_anon)
break;
 
-   if (nr_file > nr_anon) {
-   unsigned long scan_target = targets[LRU_INACTIVE_ANON] +
-   targets[LRU_ACTIVE_ANON] + 1;
+   file_percent = nr_file * 100 / file_target;
+   anon_percent = nr_anon * 100 / anon_target;
+
+   if (file_percent > anon_percent) {
lru = LRU_BASE;
-   percentage = nr_anon * 100 / scan_target;
+   nr_scanned = file_target - nr_file;
+   nr_to_scan = file_target * (100 - anon_percent) / 100;
+   percentage = nr[LRU_FILE] * 100 / nr_file;
} else {
-   unsigned long scan_target = targets[LRU_INACTIVE_FILE] +
-   targets[LRU_ACTIVE_FILE] + 1;
lru = LRU_FILE;
-   percentage = nr_file * 100 / scan_target;
+   nr_scanned = anon_target - nr_anon;
+   nr_to_scan = anon_target * (100 - file_percent) / 100;
+   percentage = nr[LRU_BASE] * 100 / nr_anon;
}
 
/* Stop scanning the smaller of the LRU */
@@ -2143,14 +2145,9 @@ static void shrink_lruvec(struct lruvec *lruvec, struct 
scan_control *sc)
 * scan target and the percentage scanning already complete
 */
lru = (lru == LRU_FILE) ? LRU_BASE : LRU_FILE;
-   nr_scanned = targets[lru] - nr[lru];
-   nr[lru] = targets[lru] * (100 - percentage) / 100;
-   nr[lru] -= min(nr[lru], nr_scanned);
-
-   lru += LRU_ACTIVE;
-   nr_scanned = targets[lru] - nr[lru];
-   nr[lru] = targets[lru] * (100 - percentage) / 100;
-   nr[lru] -= min(nr[lru], nr_scanned);
+  

Re: [PATCH v5 7/8] staging: lustre: lclient: lcommon_cl.c fixing coding style issues

[Anil Shashikumar Belur]

On Tuesday 17 June 2014 07:38 AM, Drokin, Oleg wrote:
> On Jun 16, 2014, at 12:22 PM, Anil Belur wrote:
>
>> From: Anil Belur 
>>
>> fixed: WARNING: line over 80 characters, used a new variable 'size_index' to
>> store the offset. Replace "unsigned long" with  "u64" type for
> Apparently you forgot to update the comment.
Thanks Oleg - overlooked it, will fix this shortly.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 4/4] drivers: net: Add APM X-Gene SoC ethernet driver support.

[David Miller]

From: Iyappan Subramanian 
Date: Mon, 16 Jun 2014 17:18:46 -0700

> +static netdev_tx_t xgene_enet_start_xmit(struct sk_buff *skb,
> +  struct net_device *ndev)
> +{
> + struct xgene_enet_pdata *pdata = netdev_priv(ndev);
> + struct xgene_enet_desc_ring *tx_ring = pdata->tx_ring;
> + struct xgene_enet_desc_ring *cp_ring = tx_ring->cp_ring;
> + u32 tx_level, cq_level;
> +
> + tx_level = xgene_enet_ring_len(tx_ring);
> + cq_level = xgene_enet_ring_len(cp_ring);
> + if (unlikely(tx_level > pdata->tx_qcnt_hi ||
> +  cq_level > pdata->cp_qcnt_hi)) {
> + netif_stop_queue(ndev);
> + return NETDEV_TX_BUSY;
> + }
> +
> + if (xgene_enet_setup_tx_desc(tx_ring, skb))
> + return NETDEV_TX_OK;

If you return NETDEV_TX_OK, it is your responsibility to deal with the
SKB, because you own it.

In particular, you have to free the packet.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net/cadence/macb: clear interrupts simply and correctly

[Jongsung Kim]

On 06/17/2014 12:50 PM, Sören Brinkmann wrote:
> On Tue, 2014-06-17 at 11:38AM +0900, Jongsung Kim wrote:
>> On 06/16/2014 11:56 PM, Sören Brinkmann wrote:
>>> On Mon, 2014-06-16 at 02:00PM +0900, Jongsung Kim wrote:
 On 06/13/2014 12:44 AM, Sören Brinkmann wrote:
> This is now clearing all IRQ flags which is probably not what we want
> here. This is handling RX only. We still want the non-RX interrupts to go 
> to
> the actual interrupt service routing.

 The ISR(Interrupt Status Register) is read only in the interrupt service
 routine, macb_interrupt. But is partially cleared here and there. Further
 handler-functions decide jobs to be done by reading/checking other status
 registers. (e.g., TSR, RSR) So, clearing the ISR after reading looks not
 a bad idea.
>>>
>>> But you are clearing _all_ interrupt flags in the RX NAPI handler.
>>> Doesn't that mean we might miss certain events?
>>
>> Please inspect my patch again. What I did in the macb_poll is removing
>> statements clearing the Rx-complete interrupt, not clearing all the
>> interrupts.
> 
> Why is clearing those bits removed? It's probably not a big hit, but it might
> result in a pointless interrupt which could be avoided. But it should
> probably clear all RX interrupts - MACB_RX_INT_FLAGS - instead of just RCOMP.
> For clear-on-read implementations it shouldn't make a difference.

I agree. But I removed it because I think stepping the same procedure
regardless of the "gem_irq_clear_read" implementation is better than
implementation-specific optimization.

> And in the if-condition in that new helper, I'd add '&& status' to
> avoid writing back zeros.

Good point. I'll add it when I resend v2.

Jongsung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] net: tile: fix unused variable warning

[David Miller]

From: Chris Metcalf 
Date: Mon, 16 Jun 2014 13:14:05 -0400

> 'i' is unused in tile_net_dev_init() after commit d581ebf5a1f
> ("net: tile: Use helpers from linux/etherdevice.h to check/set MAC").
> 
> Signed-off-by: Chris Metcalf 
> ---
> v2: includes previous commit's summary line as suggested by Sergei Shtylyov.

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mm/sched/net: BUG when running simple code

[Dan Aloni]

On Mon, Jun 16, 2014 at 11:17:55PM -0400, Sasha Levin wrote:
> On 06/13/2014 12:13 AM, Dave Jones wrote:
> > On Fri, Jun 13, 2014 at 12:01:37AM -0400, Sasha Levin wrote:
> > another theory: Trinity can sometimes generate plausible looking module
> > addresses and pass those in structs etc.
> > 
> > I wonder if there's somewhere in that path that isn't checking that the 
> > address
> > in the optval it got is actually a userspace address before it tries to 
> > write to it.
> 
> It happened again, and this time I've left the kernel addresses in, and it's 
> quite
> interesting:
> 
> [   88.837926] Call Trace:
> [   88.837926]  [] __sock_create+0x292/0x3c0
> [   88.837926]  [] ? __sock_create+0x110/0x3c0
> [   88.837926]  [] sock_create+0x30/0x40
> [   88.837926]  [] SyS_socket+0x2c/0x70
> [   88.837926]  [] ? tracesys+0x7e/0xe6
> [   88.837926]  [] tracesys+0xe1/0xe6
> 
> tracesys() seems to live inside a module space here?

I think it's more likely kASLR. The Documentation/x86/x86_64/mm.txt doc needs 
updating.

-- 
Dan Aloni
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] slip: Fix deadlock in write_wakeup

[David Miller]

From: Tyler Hall 
Date: Sun, 15 Jun 2014 22:23:16 -0400

> Use schedule_work() to avoid potentially taking the spinlock in
> interrupt context.
> 
> Commit cc9fa74e2a ("slip/slcan: added locking in wakeup function") added
> necessary locking to the wakeup function and 367525c8c2/ddcde142be ("can:
> slcan: Fix spinlock variant") converted it to spin_lock_bh() because the lock
> is also taken in timers.
> 
> Disabling softirqs is not sufficient, however, as tty drivers may call
> write_wakeup from interrupt context. This driver calls tty->ops->write() with
> its spinlock held, which may immediately cause an interrupt on the same CPU 
> and
> subsequent spin_bug().
> 
> Simply converting to spin_lock_irq/irqsave() prevents this deadlock, but
> causes lockdep to point out a possible circular locking dependency
> between these locks:
> 
> (&(>lock)->rlock){-.}, at: slip_write_wakeup
> (_lock_key){-.}, at: serial8250_handle_irq.part.13
> 
> The slip transmit is holding the slip spinlock when calling the tty write.
> This grabs the port lock. On an interrupt, the handler grabs the port
> lock and calls write_wakeup which grabs the slip lock. This could be a
> problem if a serial interrupt occurs on another CPU during the slip
> transmit.
> 
> To deal with these issues, don't grab the lock in the wakeup function by
> deferring the writeout to a workqueue. Also hold the lock during close
> when de-assigning the tty pointer to safely disarm the worker and
> timers.
> 
> This bug is easily reproducible on the first transmit when slip is
> used with the standard 8250 serial driver.
 ...
> Signed-off-by: Tyler Hall 

Applied and queued up for -stable.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] slcan: Port write_wakeup deadlock fix from slip

[David Miller]

From: Tyler Hall 
Date: Sun, 15 Jun 2014 22:23:17 -0400

> The commit "slip: Fix deadlock in write_wakeup" fixes a deadlock caused
> by a change made in both slcan and slip. This is a direct port of that
> fix.
> 
> Signed-off-by: Tyler Hall 

Applied and queued up for -stable.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v3 1/6] i2c: s3c2410: Handle i2c sys_cfg register in i2c driver

[Pankaj Dubey]

Hi Tomasz,

> 
> Hi Pankaj,
> 
> On 10.05.2014 09:20, Pankaj Dubey wrote:
> > Let's handle i2c interrupt re-configuration in i2c driver. This will
> > help us in removing some soc specific checks from machine files.
> > Since only Exynos5250, and Exynos5420 need to do this, added syscon
> > based phandle to i2c device nodes of respective SoC DT files.
> > Also handle saving and restoring of SYS_I2C_CFG register during
> > suspend and resume of i2c driver. This will help in removing soc
> > specific check from mach-exynos/pm.c.
> >
> > CC: Rob Herring 
> > CC: Randy Dunlap 
> > CC: Wolfram Sang 
> > CC: Russell King 
> > CC: devicet...@vger.kernel.org
> > CC: linux-...@vger.kernel.org
> > CC: linux-...@vger.kernel.org
> > Signed-off-by: Pankaj Dubey 
> > ---
> >  .../devicetree/bindings/arm/samsung/sysreg.txt |1 +
> >  arch/arm/boot/dts/exynos5.dtsi |5 +++
> >  arch/arm/boot/dts/exynos5250.dtsi  |4 +++
> >  arch/arm/boot/dts/exynos5420.dtsi  |4 +++
> 
> What about Exynos5410 and Exynos5800?

OK, I will check user manuals of these two SoCs and if required will update.

> 
> >  drivers/i2c/busses/i2c-s3c2410.c   |   32
> 
> >  5 files changed, 46 insertions(+)
> 
> [snip]
> 
> > diff --git a/drivers/i2c/busses/i2c-s3c2410.c
> > b/drivers/i2c/busses/i2c-s3c2410.c
> > index ae44910..e707062 100644
> > --- a/drivers/i2c/busses/i2c-s3c2410.c
> > +++ b/drivers/i2c/busses/i2c-s3c2410.c
> > @@ -39,6 +39,8 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >
> >  #include 
> >
> > @@ -91,6 +93,9 @@
> >  /* Max time to wait for bus to become idle after a xfer (in us) */
> >  #define S3C2410_IDLE_TIMEOUT   5000
> >
> > +/* Exynos5 Sysreg offset */
> > +#define EXYNOS5_SYS_I2C_CFG0x0234
> > +
> >  /* i2c controller state */
> >  enum s3c24xx_i2c_state {
> > STATE_IDLE,
> > @@ -127,6 +132,8 @@ struct s3c24xx_i2c {  #if
> > defined(CONFIG_ARM_S3C24XX_CPUFREQ)
> > struct notifier_block   freq_transition;
> >  #endif
> > +   struct regmap   *sysreg;
> > +   unsigned intsys_i2s_cfg;
> 
> typo: s/i2s/i2c/

Oops, sorry I will correct this. 

> 
> >  };
> >
> >  static struct platform_device_id s3c24xx_driver_ids[] = { @@ -1075,6
> > +1082,8 @@ static void  s3c24xx_i2c_parse_dt(struct device_node *np,
> > struct s3c24xx_i2c *i2c)  {
> > struct s3c2410_platform_i2c *pdata = i2c->pdata;
> > +   u32 val = 0;
> > +   int id;
> >
> > if (!np)
> > return;
> > @@ -1084,6 +1093,23 @@ s3c24xx_i2c_parse_dt(struct device_node *np,
struct
> s3c24xx_i2c *i2c)
> > of_property_read_u32(np, "samsung,i2c-slave-addr",
>slave_addr);
> > of_property_read_u32(np, "samsung,i2c-max-bus-freq",
> > (u32 *)>frequency);
> > +   /*
> > +* Exynos5's legacy i2c controller and new high speed i2c
> > +* controller have muxed interrupt sources. By default the
> 
> What do you mean by "by default"? Is it a setting from the bootloader or
reset value?
> 

It's a reset value.

> Probably to ensure that the mux is set correctly, same thing should be
also added to
> hsi2c driver.
> 
> > +* interrupts for 4-channel HS-I2C controller are enabled.
> > +* If node for first four channels of legacy i2c controller
> > +* are available then re-configure the interrupts via the
> > +* system register.
> > +*/
> > +   id = of_alias_get_id(np, "i2c");
> > +   i2c->sysreg = syscon_regmap_lookup_by_phandle(np,
> > +   "samsung,syscon-phandle");
> > +   if (IS_ERR(i2c->sysreg)) {
> > +   /* As this is not compulsory do not return error */
> > +   pr_info("i2c-%d skipping re-configuration of interrutps\n",
id);
> > +   return;
> > +   }
> > +   regmap_update_bits(i2c->sysreg, EXYNOS5_SYS_I2C_CFG, BIT(id), val);
> 
> As Wolfram pointed, val can be replaced with immediate 0 here.

OK, I will take care as per suggestion.

> 
> >  }
> >  #else
> >  static void
> > @@ -1268,6 +1294,9 @@ static int s3c24xx_i2c_suspend_noirq(struct
> > device *dev)
> >
> > i2c->suspended = 1;
> >
> > +   if (!IS_ERR(i2c->sysreg))
> > +   regmap_read(i2c->sysreg, EXYNOS5_SYS_I2C_CFG, 
> >sys_i2s_cfg);
> > +
> > return 0;
> >  }
> >
> > @@ -1276,6 +1305,9 @@ static int s3c24xx_i2c_resume(struct device *dev)
> > struct platform_device *pdev = to_platform_device(dev);
> > struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev);
> >
> > +   if (!IS_ERR(i2c->sysreg))
> > +   regmap_write(i2c->sysreg, i2c->sys_i2s_cfg,
> EXYNOS5_SYS_I2C_CFG);
> 
> According to include/linux/regmap.h:
> 
> int regmap_write(struct regmap *map, unsigned int reg, unsigned int val);
> 
> So in your code reg is swapped with val.

Yes. I will correct this.

> 
> Best regards,
> Tomasz

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 

Re: [PATCH] Check if skb_alloc returns Null in function fw_download_code

[Dave Jones]

On Mon, Jun 16, 2014 at 09:07:45PM -0700, Greg KH wrote:
 > On Mon, Jun 16, 2014 at 11:23:13PM -0400, Nicholas Krause wrote:
 > > Signed-off-by: Nicholas Krause 
 > > ---
 > >  drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c | 2 ++
 > >  1 file changed, 2 insertions(+)
 > > 
 > > diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c 
 > > b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
 > > index 1a95d1f..11e915e 100644
 > > --- a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
 > > +++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
 > > @@ -61,11 +61,13 @@ static bool fw_download_code(struct net_device *dev, 
 > > u8 *code_virtual_address,
 > >}
 > >  
 > >skb  = dev_alloc_skb(frag_length + 4);
 > > +  if (!skb) {
 > >memcpy((unsigned char *)(skb->cb), , sizeof(dev));
 > >tcb_desc = (struct cb_desc *)(skb->cb + MAX_DEV_ADDR_SIZE);
 > >tcb_desc->queue_index = TXCMD_QUEUE;
 > >tcb_desc->bCmdOrInit = DESC_PACKET_TYPE_INIT;
 > >tcb_desc->bLastIniPkt = bLastIniPkt;
 > > +  }
 > >  
 > 
 > Please run your patches through scripts/checkpatch.pl to find the errors
 > before sending them out and having someone else point them out to you...

I suspect checkpatch would pick up the indentation mess, but
indentation is the least of this patch's problems.

if that alloc_skb fails, going around the loop again is pointless, and
harmful. (we'll oops right below that added bracket).

on failure, this should be returning 0 so that the caller
handles the failure appropriately.

Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Check if skb_alloc returns Null in function fw_download_code

[Greg KH]

On Mon, Jun 16, 2014 at 11:23:13PM -0400, Nicholas Krause wrote:
> Signed-off-by: Nicholas Krause 
> ---
>  drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c 
> b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> index 1a95d1f..11e915e 100644
> --- a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> +++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> @@ -61,11 +61,13 @@ static bool fw_download_code(struct net_device *dev, u8 
> *code_virtual_address,
>   }
>  
>   skb  = dev_alloc_skb(frag_length + 4);
> + if (!skb) {
>   memcpy((unsigned char *)(skb->cb), , sizeof(dev));
>   tcb_desc = (struct cb_desc *)(skb->cb + MAX_DEV_ADDR_SIZE);
>   tcb_desc->queue_index = TXCMD_QUEUE;
>   tcb_desc->bCmdOrInit = DESC_PACKET_TYPE_INIT;
>   tcb_desc->bLastIniPkt = bLastIniPkt;
> + }
>  

Please run your patches through scripts/checkpatch.pl to find the errors
before sending them out and having someone else point them out to you...

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Doug Anderson]

Tushar,

On Mon, Jun 16, 2014 at 8:36 PM, Tushar Behera  wrote:
> On Mon, Jun 16, 2014 at 10:19 PM, Doug Anderson  wrote:
>> Tushar,
>>
>> On Mon, Jun 16, 2014 at 4:19 AM, Tushar Behera  wrote:
>>> On 06/13/2014 10:33 PM, Doug Anderson wrote:
 Tushar,

 On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera  
 wrote:
> Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.

 If you want to be a stickler about it, peach-pi actually has a
 max98091.  That requires code changes to the i2c driver, though.
 ...and unfortunately listing two compatible strings for i2c devices is
 broken.  :(

>>> Hi Doug,
>>>
>>> You are right. I checked the boot logs, the detected codec type is
>>> MAX98091. Since both these CODECs are supported through a single driver
>>> and the detection of chip is done during runtime, I would suggest we go
>>> ahead with "max98090" compatible string. I will update the commit
>>> message accordingly.
>>>
>>> Does that sound okay to you?
>>
>> As per my understanding you shouldn't do this.  You should have two patches:
>>
>> 1. Add "max98091".  You could simply post Wonjoon's patch from
>> 
>>
>> 2. Change the device tree to refer to "max98091"
>>
>> The argument that the "current kernel driver has a single driver" is
>> an argument that you're not supposed to make for device tree.  The
>> same device tree is supposed to work for U-Boot, BSD, or any other
>> platform.  On those platforms it might not be a shared driver.
>>
>
> My argument is that the device type is getting detected during
> runtime, hence there is no need to differentiate between these two.
>
> But if you prefer that way, I will repost.

Yes please.

True that it is possible to detect 98090 vs. 98091.  ...but it's also
possible to detect exynos5250 vs. exynos5420 vs. exynos5800.  ...yet
they have different compatible strings.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4] lib: add size unit t/p/e to memparse

[Gui Hecheng]

On Mon, 2014-06-16 at 18:29 -0700, David Rientjes wrote:
> On Tue, 17 Jun 2014, Gui Hecheng wrote:
> 
> > > > diff --git a/lib/cmdline.c b/lib/cmdline.c
> > > > index d4932f7..76a712e 100644
> > > > --- a/lib/cmdline.c
> > > > +++ b/lib/cmdline.c
> > > > @@ -121,11 +121,7 @@ EXPORT_SYMBOL(get_options);
> > > >   * @retptr: (output) Optional pointer to next char after parse 
> > > > completes
> > > >   *
> > > >   * Parses a string into a number.  The number stored at @ptr is
> > > > - * potentially suffixed with %K (for kilobytes, or 1024 bytes),
> > > > - * %M (for megabytes, or 1048576 bytes), or %G (for gigabytes, or
> > > > - * 1073741824).  If the number is suffixed with K, M, or G, then
> > > > - * the return value is the number multiplied by one kilobyte, one
> > > > - * megabyte, or one gigabyte, respectively.
> > > > + * potentially suffixed with K, M, G, T, P, E.
> > > >   */
> > > >  
> > > >  unsigned long long memparse(const char *ptr, char **retptr)
> > > > @@ -135,6 +131,15 @@ unsigned long long memparse(const char *ptr, char 
> > > > **retptr)
> > > > unsigned long long ret = simple_strtoull(ptr, , 0);
> > > >  
> > > > switch (*endptr) {
> > > > +   case 'E':
> > > > +   case 'e':
> > > > +   ret <<= 10;
> > > > +   case 'P':
> > > > +   case 'p':
> > > > +   ret <<= 10;
> > > > +   case 'T':
> > > > +   case 't':
> > > > +   ret <<= 10;
> > > > case 'G':
> > > > case 'g':
> > > > ret <<= 10;
> > > 
> > > Seems fine since unsigned long long is always at least 64 bits, but 
> > > perhaps also change simple_strtoull() to use kstrtoull() at the same time 
> > > since the former is deprecated?
> > 
> > Yes, that is a point. But the deprecated function is a separate problem
> > and may not be included in this patch.
> > Also, I find that simple_strtoull is used in many places in the kernel
> > code, it is better to replace it globally?
> > 
> 
> If you're going to have a go at replacing the simple_strto*() functions 
> throughout the kernel, it's probably better to do it per subsystem (as 
> defined by the separate sections of MAINTAINERS) and propose the patches 
> individually to those maintainers.  Once it has been removed entirely, you 
> can submit a patch to remove the functions themselves.
> 
> Be aware that there are many callers to the deprecated functions so it may 
> take a significant amount of time.

H...It may really take a long time. But I am not sure whether this
is really a good idea to do this big replacement. Let's see whether
anyone would like to share his opinions.

-Gui

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] include: kernel.h: rewrite min3, max3 and clamp using min and max

[Steven Rostedt]

On Mon, 16 Jun 2014 20:21:20 -0400
Steven Rostedt  wrote:

> On Mon, 16 Jun 2014 16:54:32 -0700 (PDT)
> David Rientjes  wrote:
> 
> > 
> > 
> > On linux-next, allyesconfig has a 0.0001% savings as a result of the 
> > patch, but I'd be worried about the extra temp variable it allocates on 
> > the stack that is evident in the mm/slab.c disassembly unless all cases 
> > can be audited to show that we're not potentially deep.
> 
> A 0.0001% change means it's not worth changing, and we may be able to
> mark this up as a fluke in Michal's results.
> 
> I'll give it a try on my 4.6.3 compiler.
> 
> -- Steve
> 
> > 
> >textdata bss dec hex filename
> > 108573045   2348801651580928183641989   af22785 
> > vmlinux.before
> > 108572908   2348801651580928183641852   af226fc 
> > vmlinux.after
> 

Here's my results:

   textdata bss dec hex filename
108662851   2347025651580928183714035   af340f3 
/tmp/vmlinux-orig
108662714   2347022451580928183713866   af3404a 
/tmp/vmlinux-patched

The patched version saved a total of 169 bytes.

Doing a diff on the vmlinux objdumps of do_fault_around, I get this:

  mov-0x68(%rbp),%rdi
  mov-0x70(%rbp),%r8d
- jae81302bf5 
- cmp%r15,%rax
- mov%r15,%r14
- cmovbe %rax,%r14
- jmp81302c03 
- cmp%r14,%rax
- cmovbe %rax,%r14
- incq   0x8d384b5(%rip)# 8a03b0b8 
- mov0x8d384be(%rip),%rsi# 8a03b0c8 
- mov0x8d384bf(%rip),%rdx# 8a03b0d0 
- mov0x8d384a8(%rip),%rax# 8a03b0c0 
+ cmp%rax,%r15
+ cmova  %rax,%r15
+ mov0x8d384c0(%rip),%rax# 8a03b0b8 
+ cmp%r14,%r15
+ cmovbe %r15,%r14
  sub%r12,%rsi


So for gcc 4.6.3 it does seem to produce nicer assembly. I haven't
tried it with other versions though (or with clang).

But I'll still give it a:

Acked-by: Steven Rostedt 

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/2] Add devicetree support for extcon-gpio

[George Cherian]

This serires adds devicetree support for extcon-gpio driver.

Patch 1 - Addreses minor cleanups
Patch 2 - Adds devicetree support for esxtcon-gpio driver.
 
George Cherian (2):
  extcon: gpio: Minor cleanups
  extcon: gpio: Add dt support for the driver.

 .../devicetree/bindings/extcon/extcon-gpio.txt | 34 +++
 drivers/extcon/extcon-gpio.c   | 39 +++---
 include/linux/extcon/extcon-gpio.h |  4 ++-
 3 files changed, 71 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt

-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] extcon: gpio: Minor cleanups

[George Cherian]

Minor Cleanups
 - Order the include files in alphabetical order.
 - Fix description of state_off in extcon_gpio.h
 - Add a descrition for check_on_resume in extcon_gpio.h

Signed-off-by: George Cherian 
---
 drivers/extcon/extcon-gpio.c   | 10 +-
 include/linux/extcon/extcon-gpio.h |  4 +++-
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 645b283..6c268b4 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -20,16 +20,16 @@
  *
 */
 
-#include 
-#include 
+#include 
+#include 
+#include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
 
 struct gpio_extcon_data {
struct extcon_dev *edev;
diff --git a/include/linux/extcon/extcon-gpio.h 
b/include/linux/extcon/extcon-gpio.h
index 8900fdf..0b17ad4 100644
--- a/include/linux/extcon/extcon-gpio.h
+++ b/include/linux/extcon/extcon-gpio.h
@@ -34,8 +34,10 @@
  * @irq_flags: IRQ Flags (e.g., IRQF_TRIGGER_LOW).
  * @state_on:  print_state is overriden with state_on if attached.
  * If NULL, default method of extcon class is used.
- * @state_off: print_state is overriden with state_on if detached.
+ * @state_off: print_state is overriden with state_off if detached.
  * If NUll, default method of extcon class is used.
+ * @check_on_resume:   Boolean describing whether to check the state of gpio
+ * while resuming from sleep.
  *
  * Note that in order for state_on or state_off to be valid, both state_on
  * and state_off should be not NULL. If at least one of them is NULL,
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] extcon: gpio: Add dt support for the driver.

[George Cherian]

Add device tree support to extcon-gpio driver.
Add devicetree binding documentation

Signed-off-by: George Cherian 
---
 .../devicetree/bindings/extcon/extcon-gpio.txt | 34 ++
 drivers/extcon/extcon-gpio.c   | 29 ++
 2 files changed, 63 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt

diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt 
b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
new file mode 100644
index 000..80b791b
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
@@ -0,0 +1,34 @@
+GPIO based EXTCON
+
+EXTCON GPIO
+---
+
+Required Properties:
+ - compatible: should be:
+   * "ti,extcon-gpio"
+ - gpios: specifies the gpio pin used.
+ - debounce: Debounce time for GPIO IRQ in ms
+ - irq-flags: IRQ flag to be used ( eg: IRQ_TYPE_EDGE_FALLING)
+
+Optional Properties:
+ - gpio-active-low: Property describing whether gpio active state is 1 or 0
+   If defined , low state of gpio means active.
+ - check-on-resume: Property describing whether to check the gpio state
+   while resuming from SLEEP.
+ - state-on: print_state is overriden with state_on string if provided.
+If NULL, default method of extcon class is used.
+ - state_off: print_state is overriden with state_off string  if provided.
+ If NUll, default method of extcon class is used.
+
+Eg:
+
+extcon1: am43_usbid_extcon1 {
+compatible = "ti,extcon-gpio";
+gpios = < 12 GPIO_ACTIVE_HIGH>;
+gpio-active-low;
+debounce = <20>;
+irq-flags = ;
+state-on = "USB ID FLOAT";
+state-off = "USB ID GND";
+
+};
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 6c268b4..14d999d 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -83,12 +84,34 @@ static ssize_t extcon_gpio_print_state(struct extcon_dev 
*edev, char *buf)
 
 static int gpio_extcon_probe(struct platform_device *pdev)
 {
+   struct device_node *np = pdev->dev.of_node;
struct gpio_extcon_platform_data *pdata = dev_get_platdata(>dev);
struct gpio_extcon_data *extcon_data;
int ret;
 
+   if (np) {
+   pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return -ENOMEM;
+
+   pdata->gpio = of_get_gpio(np, 0);
+   if (!gpio_is_valid(pdata->gpio))
+   return -EPROBE_DEFER;
+
+   pdata->name = np->name;
+   pdata->gpio_active_low = of_property_read_bool(np,
+   "gpio-active-low");
+   pdata->check_on_resume = of_property_read_bool(np,
+   "check-on-resume");
+   of_property_read_u32(np, "debounce", (u32 *)>debounce);
+   of_property_read_u32(np, "irq-flags", (u32 *)>irq_flags);
+   of_property_read_string(np, "state-on", >state_on);
+   of_property_read_string(np, "state-off", >state_off);
+   }
+
if (!pdata)
return -EBUSY;
+
if (!pdata->irq_flags) {
dev_err(>dev, "IRQ flag is not specified.\n");
return -EINVAL;
@@ -177,6 +200,11 @@ static int gpio_extcon_resume(struct device *dev)
 
 static SIMPLE_DEV_PM_OPS(gpio_extcon_pm_ops, NULL, gpio_extcon_resume);
 
+static struct of_device_id of_extcon_gpio_match_tbl[] = {
+   { .compatible = "ti,extcon-gpio", },
+   { /* end */ }
+};
+
 static struct platform_driver gpio_extcon_driver = {
.probe  = gpio_extcon_probe,
.remove = gpio_extcon_remove,
@@ -184,6 +212,7 @@ static struct platform_driver gpio_extcon_driver = {
.name   = "extcon-gpio",
.owner  = THIS_MODULE,
.pm = _extcon_pm_ops,
+   .of_match_table = of_extcon_gpio_match_tbl,
},
 };
 
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix comments in rbtree.c

[Guenter Roeck]

On 06/14/2014 11:34 AM, Nick wrote:

Signed-off-by: Nick 
---
  lib/rbtree.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/lib/rbtree.c b/lib/rbtree.c
index 65f4eff..c66370c 100644
--- a/lib/rbtree.c
+++ b/lib/rbtree.c
@@ -101,11 +101,10 @@ __rb_insert(struct rb_node *node, struct rb_root *root,
 *  / \  / \
 * p   u  -->   P   U
 *//
-*   nN
+*   nn


You'll need a lengthy explanation here. What makes you think that the comment
is wrong ?

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v3 4/6] ARM: EXYNOS: Remove unused header inclusion from hotplug.c

[Pankaj Dubey]

Hi Tomasz,


> -Original Message-
> 
> Hi Pankaj,
> 
> On 10.05.2014 09:20, Pankaj Dubey wrote:
> > This patch removed "plat/cpu.h" inclusion from hotplug.c as it is not
> > required.
> >
> > Signed-off-by: Pankaj Dubey 
> > ---
> >  arch/arm/mach-exynos/hotplug.c |2 --
> >  1 file changed, 2 deletions(-)
> >
> > diff --git a/arch/arm/mach-exynos/hotplug.c
> > b/arch/arm/mach-exynos/hotplug.c index 0243ef3..5e19601 100644
> > --- a/arch/arm/mach-exynos/hotplug.c
> > +++ b/arch/arm/mach-exynos/hotplug.c
> > @@ -19,8 +19,6 @@
> >  #include 
> >  #include 
> >
> > -#include 
> > -
> >  #include "common.h"
> >  #include "regs-pmu.h"
> >
> >
> 
> I don't see this header being included in current linux-next.
> 

OK, if it's already taken care, I will drop this change in next version.

> Best regards,
> Tomasz

Thanks,
Pankaj Dubey

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net/cadence/macb: clear interrupts simply and correctly

[Sören Brinkmann]

On Tue, 2014-06-17 at 11:38AM +0900, Jongsung Kim wrote:
> On 06/16/2014 11:56 PM, Sören Brinkmann wrote:
> > On Mon, 2014-06-16 at 02:00PM +0900, Jongsung Kim wrote:
> >> On 06/13/2014 12:44 AM, Sören Brinkmann wrote:
> >>> This is now clearing all IRQ flags which is probably not what we want
> >>> here. This is handling RX only. We still want the non-RX interrupts to go 
> >>> to
> >>> the actual interrupt service routing.
> >>
> >> The ISR(Interrupt Status Register) is read only in the interrupt service
> >> routine, macb_interrupt. But is partially cleared here and there. Further
> >> handler-functions decide jobs to be done by reading/checking other status
> >> registers. (e.g., TSR, RSR) So, clearing the ISR after reading looks not
> >> a bad idea.
> >
> > But you are clearing _all_ interrupt flags in the RX NAPI handler.
> > Doesn't that mean we might miss certain events?
> 
> Please inspect my patch again. What I did in the macb_poll is removing
> statements clearing the Rx-complete interrupt, not clearing all the
> interrupts.

Oh, you're right. I misread the patch, sorry. The call to macb_read_isr was
already a different hunk.
Why is clearing those bits removed? It's probably not a big hit, but it might
result in a pointless interrupt which could be avoided. But it should
probably clear all RX interrupts - MACB_RX_INT_FLAGS - instead of just RCOMP.
For clear-on-read implementations it shouldn't make a difference.

And in the if-condition in that new helper, I'd add '&& status' to
avoid writing back zeros.

Thanks,
Sören
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: stats (Re: Linux 3.16-rc1 - merge window closed)

[Stephen Rothwell]

As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)

(No merge commits counted, next-20140602 was the first linux-next after
the merge window opened.)

Commits in v3.16-rc1 (relative to v3.15): 11364 (v3.15-rc1: 12034)
Commits in next-20140602: 10283 (next-20140331: 11411)
Commits with the same SHA1:9204 (   10432)
Commits with the same patch_id: 559 (1) ( 581)
Commits with the same subject line:  60 (1) (  74)

(1) not counting those in the lines above.

So commits in -rc1 that were in next-20140602:   9823   86.4%   (11087  92.1%)
That is a big drop - presumably caused by the suprise opening of the
merge window a week early.

Some breakdown of the list of extra commits (relative to next-20140602)
in -rc1:

Top eleven first word of commit summary:

243 drm
 91 btrfs
 87 net
 59 mmc
 57 i40e
 46 perf
 45 powerpc
 34 mips
 32 reiserfs
 24 xfs
 24 alsa

Top eleven authors:

 48 bske...@redhat.com
 41 rmk+ker...@arm.linux.org.uk
 32 je...@suse.com
 28 namhy...@kernel.org
 26 f...@skynet.be
 25 fdman...@gmail.com
 23 james.ho...@imgtec.com
 21 tred...@nvidia.com
 21 geert+rene...@glider.be
 21 dchin...@redhat.com
 21 chuck.le...@oracle.com

Top ten commiters:

218 da...@davemloft.net
 93 c...@fb.com
 76 jeffrey.t.kirs...@intel.com
 72 torva...@linux-foundation.org
 68 bske...@redhat.com
 62 daei...@gmail.com
 52 ch...@printf.net
 50 b...@kernel.crashing.org
 44 alexander.deuc...@amd.com
 39 h...@lst.de

There are also 460 commits in next-20140602 that didn't make it into
v3.16-rc1.

Top ten first word of commit summary:

 43 arm
 39 sparc32
 22 drm
 21 sparc64
 21 mm
 18 arch
 15 vfs
 12 drivers
 12 arm-soc
 10 sparc

Top nine authors:

 67 s...@ravnborg.org
 49 a...@linux-foundation.org
 23 shawn@freescale.com
 18 n-horigu...@ah.jp.nec.com
 17 gang.chen.5...@gmail.com
 13 ebied...@xmission.com
 12 o...@lixom.net
  9 mho...@suse.cz
  9 epa...@redhat.com

Some of Andrew's patches are fixes for other patches in his tree (and
have been merged into those).

Top ten commiters:

166 s...@canb.auug.org.au
 70 da...@davemloft.net
 34 shawn@freescale.com
 28 matthew.garr...@nebula.com
 21 daniel.vet...@ffwll.ch
 19 g...@mprc.pku.edu.cn
 16 ebied...@xmission.com
 14 epa...@redhat.com
 12 o...@lixom.net
 10 jason.wes...@windriver.com

Those commits by me are from the quilt series (mainly Andrew's mmotm
tree).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

RE: [PATCH v4 02/11] ARM: EXYNOS: Move cpufreq and cpuidle device registration to init_machine

[Pankaj Dubey]

Hi Tomasz,

> -Original Message-
> 
> Hi Pankaj,
> 
> On 10.05.2014 08:56, Pankaj Dubey wrote:
> > As exynos_cpuidle_init and exynos_cpufreq_init function have just one
> > lines of code for registering platform devices. We can move these
> > lines to exynos_dt_machine_init and delete exynos_cpuidle_init and
> > exynos_cpufreq_init function. This will help in reducing lines of code
> > in exynos.c, making it more cleaner.
> >
> > Suggested-by: Tomasz Figa 
> > Signed-off-by: Pankaj Dubey 
> > ---
> >  arch/arm/mach-exynos/exynos.c |   19 ---
> >  1 file changed, 4 insertions(+), 15 deletions(-)
> >
> 
> Reviewed-by: Tomasz Figa 
> 

Thanks for review.

> Btw. This and other simple clean-up patches from this series could be
applied
> separately, without re-spinning them every time with this series.
> 

OK, I will separate cleanup patches.

> Best regards,
> Tomasz

Thanks,
Pankaj Dubey


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm, thp: move invariant bug check out of loop in __split_huge_page_map

[Waiman Long]

On 06/16/2014 04:59 PM, Kirill A. Shutemov wrote:

On Mon, Jun 16, 2014 at 11:49:34PM +0300, Kirill A. Shutemov wrote:

On Mon, Jun 16, 2014 at 03:35:48PM -0400, Waiman Long wrote:

In the __split_huge_page_map() function, the check for
page_mapcount(page) is invariant within the for loop. Because of the
fact that the macro is implemented using atomic_read(), the redundant
check cannot be optimized away by the compiler leading to unnecessary
read to the page structure.

And atomic_read() is *not* atomic operation. It's implemented as
dereferencing though cast to volatile, which suppress compiler
optimization, but doesn't affect what CPU can do with the variable.

So I doubt difference will be measurable anywhere.



Because it is treated as an volatile object, the compiler will have to 
reread the value of the relevant page structure field in every iteration 
of the loop (512 for x86) when pmd_write(*pmd) is true. I saw some 
slight improvement (about 2%) of a microbench that I wrote to break up 
1000 THPs with 1000 forked processes.


-Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.16-rc1 kernel BUG triggered at mutex.c:586

[Mike Galbraith]

On Mon, 2014-06-16 at 14:28 -0400, Vlad Yasevich wrote: 
> Trying to boot 3.16.0-rc1+ (the + is a small vlan related patch) on a
> tests system triggers the following BUG:

It's easier for developers to read if you dump dmesg, or at least tell
your mail client to please not make a line-wrapped mess of your report.

 

BUG: sleeping function called from invalid context at kernel/locking/mutex.c:586
in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/3
1 lock held by swapper/3/0:
#0: (&(>counts.lock)->rlock){..-...}, at: [] 
bitmap_endwrite+0x58/0x230 211959
hardirqs last  enabled at (211958): [] 
_raw_spin_unlock_irqrestore+0x36/0x70
hardirqs last disabled at (211959): [] 
_raw_spin_lock_irqsave+0x29/0x70
softirqs last  enabled at (211952): [] 
_local_bh_enable+0x22/0x50
softirqs last disabled at (211953): [] irq_exit+0xc5/0xd0
swapper/3 Not tainted 3.16.0-rc1+ #35 Hewlett-Packard HP xw8400 
Workstation/0A08h, BIOS 786D5 v02.38 10/25/2010
 88047fcc3bd0
81706ef2 81c857e0
88047fcc3be0 810b4dba
88047fcc3c50 8170c79c
 81c85938
0046 0092
Call Trace:

[] dump_stack+0x4d/0x66
[] __might_sleep+0xfa/0x130
[] mutex_lock_nested+0x3c/0x3a0
[] kernfs_notify+0x8a/0x140
[] bitmap_endwrite+0xb9/0x230
[] close_write+0x93/0xb0 [raid1]
[] r1_bio_write_done+0x29/0x50 [raid1]
[] raid1_end_write_request+0xcf/0x220 [raid1]
[] bio_endio+0x5b/0xa0
[] blk_update_request+0x90/0x330
[] blk_update_bidi_request+0x1c/0x80
[] blk_end_bidi_request+0x1f/0x60
[] blk_end_request+0x10/0x20
[] scsi_io_completion+0xf4/0x6e0
[] scsi_finish_command+0xb3/0x110
[] scsi_softirq_done+0x137/0x160
[] blk_done_softirq+0x90/0xb0
[] __do_softirq+0x125/0x300
[] irq_exit+0xc5/0xd0
[] smp_call_function_single_interrupt+0x35/0x40
[] call_function_single_interrupt+0x72/0x80

[] ?  native_safe_halt+0x6/0x10
[] ?  trace_hardirqs_on+0xd/0x10
[] default_idle+0x24/0xe0
[] arch_cpu_idle+0xf/0x20
[] cpu_startup_entry+0x2cb/0x450
[] ?  clockevents_register_device+0xbc/0x120
[] start_secondary+0x1de/0x290
=

inconsistent lock state ]
3.16.0-rc1+ #35 Not tainted
-
inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
swapper/3/0 [HC0[0]:SC1[1]:HE0:SE0] takes: (kernfs_mutex){+.?.+.}, at: 
[] kernfs_notify+0x8a/0x140
{SOFTIRQ-ON-W} state was registered at:
 [] __lock_acquire+0x316/0x1a60
 [] lock_acquire+0xa2/0x130
 [] mutex_lock_nested+0x6a/0x3a0
 [] kernfs_activate+0x1f/0xf0
 [] kernfs_create_root+0xe8/0x110
 [] sysfs_init+0x13/0x51
 [] mnt_init+0x118/0x225
 [] vfs_caches_init+0x99/0x115
 [] start_kernel+0x3ec/0x443
 [] x86_64_start_reservations+0x2a/0x2c
 [] x86_64_start_kernel+0x13e/0x14d
211959 hardirqs last  enabled at (211958): [] 
_raw_spin_unlock_irqrestore+0x36/0x70
hardirqs last disabled at (211959): [] 
_raw_spin_lock_irqsave+0x29/0x70
softirqs last  enabled at (211952): [] 
_local_bh_enable+0x22/0x50
softirqs last disabled at (211953): [] irq_exit+0xc5/0xd0

other info that might help us debug this:
Possible unsafe locking scenario:

  CPU0
  
 lock(kernfs_mutex);
 
 lock(kernfs_mutex);

 *** DEADLOCK ***

1 lock held by swapper/3/0:
#0: (&(>counts.lock)->rlock){..-...}, at: [] 
bitmap_endwrite+0x58/0x230
stack backtrace: swapper/3 Not tainted 3.16.0-rc1+ #35 Hewlett-Packard HP 
xw8400 Workstation/0A08h, BIOS 786D5 v02.38 10/25/2010
82638c50 88047fcc3a20
81706ef2 8804695edb40
88047fcc3a70 81702a16
0001 8804
8804 0006
8804695edb40 810d7c20
Call Trace:

[] dump_stack+0x4d/0x66
[] print_usage_bug+0x1f3/0x204
[] ?  check_usage_backwards+0x140/0x140
[] mark_lock+0x222/0x2b0
[] __lock_acquire+0x2b8/0x1a60
[] ?  show_trace_log_lvl+0x4d/0x60
[] ?  show_stack_log_lvl+0xa4/0x190
[] lock_acquire+0xa2/0x130
[] ?  kernfs_notify+0x8a/0x140
[] mutex_lock_nested+0x6a/0x3a0
[] ?  kernfs_notify+0x8a/0x140
[] kernfs_notify+0x8a/0x140
[] bitmap_endwrite+0xb9/0x230
[] close_write+0x93/0xb0 [raid1]
[] r1_bio_write_done+0x29/0x50 [raid1]
[] raid1_end_write_request+0xcf/0x220 [raid1]
[] bio_endio+0x5b/0xa0
[] blk_update_request+0x90/0x330
[] blk_update_bidi_request+0x1c/0x80
[] blk_end_bidi_request+0x1f/0x60
[] blk_end_request+0x10/0x20
[] scsi_io_completion+0xf4/0x6e0
[] scsi_finish_command+0xb3/0x110
[] scsi_softirq_done+0x137/0x160
[] blk_done_softirq+0x90/0xb0
[] __do_softirq+0x125/0x300
[] irq_exit+0xc5/0xd0
[] smp_call_function_single_interrupt+0x35/0x40
[] call_function_single_interrupt+0x72/0x80

[] ?  native_safe_halt+0x6/0x10
[] ?  trace_hardirqs_on+0xd/0x10
[] default_idle+0x24/0xe0
[] arch_cpu_idle+0xf/0x20
[] cpu_startup_entry+0x2cb/0x450
[] ?  clockevents_register_device+0xbc/0x120
[] start_secondary+0x1de/0x290


> Is this a known issue?  Are there any patches I can help
> test?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to 

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Tushar Behera]

On Mon, Jun 16, 2014 at 10:32 PM, Doug Anderson  wrote:
> Mark,
>
> On Mon, Jun 16, 2014 at 9:51 AM, Mark Brown  wrote:
>> On Mon, Jun 16, 2014 at 09:49:26AM -0700, Doug Anderson wrote:
>>
>>> Yes please.  I think there's supposed to be some official ordering of
>>> things.  If anyone reading this has a pointer to the official sort
>>> order of things in the device tree I'd love to see it!  ;)
>>
>> Most exact first I believe?
>
> More specifically I'm looking for the ordering between nodes and
> between properties in a node.  For instance:
>
> 1. It appears to be convention to sort children of the "pinctrl" nodes
> by the first pin number in that group.  That is:
>
> ec_spi_cs: ec-spi-cs {
>   samsung,pins = "gpb1-2";
>   ...
> };
>
> ...comes before:
> usb300_vbus_en: usb300-vbus-en {
>   samsung,pins = "gph0-0";
>   ...
> };
>
> ...that's one really good and well-defined ordering.
>
>
> 2. I have no idea how general properties should be sorted.  I tend to
> see "compatible" first but that's above the only rule I've seen.
> Sometimes I've seen "status" first, sometimes last, sometimes
> alphabetically sorted, and sometimes in a random place.  Examples:
>
> usb301_vbus_reg: regulator-usb301 {
>   compatible = "regulator-fixed";
>   regulator-name = "P5.0V_USB3CON1";
>   regulator-min-microvolt = <500>;
>   regulator-max-microvolt = <500>;
>   gpio = < 1 0>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_vbus_en>;
>   enable-active-high;
> };
>
>  {
>   status = "okay";
>   hpd-gpio = < 7 GPIO_ACTIVE_HIGH>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_hpd_irq>;
>   ddc = <_2>;
> };
>
>
> 3. I have no idea how to sort nodes.  In theory you could say that
> they should be sorted by base address:
>
> i2s0: i2s@0383 {
>   ...
> };
>
> hsi2c_7: i2c@12CD {
>   ...
> };
>
> i2s1: i2s@12D6 {
>   ...
> };
>
> ...that works until someone argues that all of the "i2s" nodes should
> be together.  It also doesn't work so well with the board convention
> of using aliases to refer to things in the SoC, like:
>
>  {
>   status = "okay";
> };
>
> _7 {
>   status = "okay";
> };
>
> ...it's not at all obvious in the board file what the base address in
> the SoC was.
>

In case where we are using only aliases in board file, sorting them
alphabetically would be reasonable. This rule would be easy to
reinforce.

> ---
>
> Anyway, none of this is earth shattering and it doesn't matter all
> that much.  It's just nice to have an official order to make diffing
> easier and also to avoid merge conflicts (unlikely someone changing
> different properties will both add them in the same place in the
> ordering).
>
>
> -Doug



-- 
Tushar Behera
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net/cadence/macb: clear interrupts simply and correctly

[Jongsung Kim]

On 06/17/2014 06:28 AM, Sören Brinkmann wrote:
> Shouldn't it be sufficient to replace 'MACB_BIT(RCOMP) with 
> 'MACB_RX_INT_FLAGS'
> to clear all the RX IRQ flags.

I'm afraid not.

You know, this driver initially targeted only GEMs configured with 
"gem_irq_clear_read."
For this implementation of GEM, the ISR is automatically cleared by reading. 
The driver
was designed to operate with the value read from ISR, not with the ISR itself.

However, there are other GEMs configured without "gem_irq_clear_read," people 
like you
and I working with. To support them, they insert similar codes conditionally 
clearing
the ISR here and there. Now they are found at 6 places. Not enough yet. Do you 
want to
insert another at the end of macb_reset_hw..? Maybe not.

Jongsung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] ARM: dts: Enable audio support for Peach-pi board

[Tushar Behera]

On Mon, Jun 16, 2014 at 10:19 PM, Doug Anderson  wrote:
> Tushar,
>
> On Mon, Jun 16, 2014 at 4:19 AM, Tushar Behera  wrote:
>> On 06/13/2014 10:33 PM, Doug Anderson wrote:
>>> Tushar,
>>>
>>> On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera  
>>> wrote:
 Peach-pi board has MAX98090 audio codec connected on HSI2C-7 bus.
>>>
>>> If you want to be a stickler about it, peach-pi actually has a
>>> max98091.  That requires code changes to the i2c driver, though.
>>> ...and unfortunately listing two compatible strings for i2c devices is
>>> broken.  :(
>>>
>> Hi Doug,
>>
>> You are right. I checked the boot logs, the detected codec type is
>> MAX98091. Since both these CODECs are supported through a single driver
>> and the detection of chip is done during runtime, I would suggest we go
>> ahead with "max98090" compatible string. I will update the commit
>> message accordingly.
>>
>> Does that sound okay to you?
>
> As per my understanding you shouldn't do this.  You should have two patches:
>
> 1. Add "max98091".  You could simply post Wonjoon's patch from
> 
>
> 2. Change the device tree to refer to "max98091"
>
> The argument that the "current kernel driver has a single driver" is
> an argument that you're not supposed to make for device tree.  The
> same device tree is supposed to work for U-Boot, BSD, or any other
> platform.  On those platforms it might not be a shared driver.
>

My argument is that the device type is getting detected during
runtime, hence there is no need to differentiate between these two.

But if you prefer that way, I will repost.

>
>> If you so desire, I will submit a patch to sort peach-pi device-tree
>> nodes (w.r.t. peach-pit dts file).
>
> Yes please.  I think there's supposed to be some official ordering of
> things.  If anyone reading this has a pointer to the official sort
> order of things in the device tree I'd love to see it!  ;)
>
> -Doug

-- 
Tushar Behera
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] checkpatch: Warn on unnecessary void function return statements

[Sachin Kamat]

On Tue, Jun 17, 2014 at 8:55 AM, Joe Perches  wrote:
> On Tue, 2014-06-17 at 08:46 +0530, Sachin Kamat wrote:
>> On Tue, Jun 17, 2014 at 7:30 AM, Joe Perches  wrote:
>> > On Mon, 2014-06-16 at 17:44 -0700, Anish Bhatt wrote:
>> >> My code has multiple exit lables:
>> >> void function(void)
>> >> {
>> >>   ...
>> >>
>> >>   if (err1)
>> >>   goto exit1;
>> >>   ...
>> >>   if (err2)
>> >>   goto exit2;
>> >>
>> >>   ...
>> >>   return; /* Good return, no errors */
>> >> exit1:
>> >>   printk(err1);
>> >>   return;
>> >> exit2:
>> >>   printk(err2);
>> >> }
>> >>
>> >> The single tabbed return was required to prevent the good return & err1
>> >> messages cascading down. The extra exit label with a noop looks weird,
>> >> but is passing checkpatch.pl --strict, so I will go with that, thanks.
>> >> -Anish
>> >>
>> >
>> > Hmm, those return uses seem reasonable
>> > to me.
>> >
>> > Perhaps the test should warn only on
>> > this specific 3 line sequence:
>> >
>> > [any line but a label]
>> > return;
>> > }
>> >
>> > Andrew?  Anyone else?  Opinions?
>>
>> It should warn only if the return is followed by a value like
>> return 0; or return -EERROR_CODE; etc. and not just 'return;'
>
> No.  The compiler gets to warn on those.
> checkpatch isn't a compiler.

Right. I misunderstood the context of the discussion.
Sorry for the noise.

-- 
Regards,
Sachin.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] checkpatch: Warn on unnecessary void function return statements

[Joe Perches]

On Tue, 2014-06-17 at 08:46 +0530, Sachin Kamat wrote:
> On Tue, Jun 17, 2014 at 7:30 AM, Joe Perches  wrote:
> > On Mon, 2014-06-16 at 17:44 -0700, Anish Bhatt wrote:
> >> My code has multiple exit lables:
> >> void function(void)
> >> {
> >>   ...
> >>
> >>   if (err1)
> >>   goto exit1;
> >>   ...
> >>   if (err2)
> >>   goto exit2;
> >>
> >>   ...
> >>   return; /* Good return, no errors */
> >> exit1:
> >>   printk(err1);
> >>   return;
> >> exit2:
> >>   printk(err2);
> >> }
> >>
> >> The single tabbed return was required to prevent the good return & err1
> >> messages cascading down. The extra exit label with a noop looks weird,
> >> but is passing checkpatch.pl --strict, so I will go with that, thanks.
> >> -Anish
> >>
> >
> > Hmm, those return uses seem reasonable
> > to me.
> >
> > Perhaps the test should warn only on
> > this specific 3 line sequence:
> >
> > [any line but a label]
> > return;
> > }
> >
> > Andrew?  Anyone else?  Opinions?
> 
> It should warn only if the return is followed by a value like
> return 0; or return -EERROR_CODE; etc. and not just 'return;'

No.  The compiler gets to warn on those.
checkpatch isn't a compiler.

It's a code style verifying and sometimes an
API misuse checking tool.

In this case, using return at the bottom of a
void function like

void function(void)
{
[code...]

return;
}

is undesired and would generally be written as

void function(void)
{
[code...]
}


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[f2fs-dev][PATCH v2] f2fs: refactor flush_nat_entries codes for reducing NAT writes

[Chao Yu]

Although building NAT journal in cursum reduce the read/write work for NAT
block, but previous design leave us lower performance when write checkpoint
frequently for these cases:
1. if journal in cursum has already full, it's a bit of waste that we flush all
   nat entries to page for persistence, but not to cache any entries.
2. if journal in cursum is not full, we fill nat entries to journal util
   journal is full, then flush the left dirty entries to disk without merge
   journaled entries, so these journaled entries may be flushed to disk at next
   checkpoint but lost chance to flushed last time.

In this patch we merge dirty entries located in same NAT block to nat entry set,
and linked all set to list, sorted ascending order by entries' count of set.
Later we flush entries in sparse set into journal as many as we can, and then
flush merged entries to disk.

In my testing environment, it shows this patch can help to reduce NAT block
writes.

1. virtual machine + hard disk:
fsstress -p 20 -n 200 -l 5
node numcp countnodes/cp
based   4599.6  1803.0  2.551
patched 2714.6  1829.6  1.483

2. virtual machine + 32g micro SD card:
fsstress -p 20 -n 200 -l 1 -w -f chown=0 -f creat=4 -f dwrite=0
-f fdatasync=4 -f fsync=4 -f link=0 -f mkdir=4 -f mknod=4 -f rename=5
-f rmdir=5 -f symlink=0 -f truncate=4 -f unlink=5 -f write=0 -S

node numcp countnodes/cp
based   84.543.71.933
patched 49.240.01.23

change log from v1:
 o use list_for_each_entry_safe in add_nat_entry() to avoid potential deadloop.

Signed-off-by: Chao Yu 
---
 fs/f2fs/f2fs.h  |4 +
 fs/f2fs/node.c  |  254 +--
 fs/f2fs/node.h  |7 ++
 fs/f2fs/super.c |8 +-
 4 files changed, 192 insertions(+), 81 deletions(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 58df97e..4d717dc 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -256,6 +256,8 @@ struct f2fs_nm_info {
unsigned int nat_cnt;   /* the # of cached nat entries */
struct list_head nat_entries;   /* cached nat entry list (clean) */
struct list_head dirty_nat_entries; /* cached nat entry list (dirty) */
+   struct list_head nat_entry_set; /* nat entry set list */
+   unsigned int dirty_nat_cnt; /* total num of nat entries in set */
 
/* free node ids management */
struct radix_tree_root free_nid_root;/* root of the free_nid cache */
@@ -1194,6 +1196,8 @@ int build_node_manager(struct f2fs_sb_info *);
 void destroy_node_manager(struct f2fs_sb_info *);
 int __init create_node_manager_caches(void);
 void destroy_node_manager_caches(void);
+int __init create_nat_set_caches(void);
+void destroy_nat_set_caches(void);
 
 /*
  * segment.c
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 9dfb9a0..347c0c1 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -25,6 +25,7 @@
 
 static struct kmem_cache *nat_entry_slab;
 static struct kmem_cache *free_nid_slab;
+static struct kmem_cache *nat_entry_set_slab;
 
 bool available_free_memory(struct f2fs_sb_info *sbi, int type)
 {
@@ -88,12 +89,8 @@ static struct page *get_next_nat_page(struct f2fs_sb_info 
*sbi, nid_t nid)
 
/* get current nat block page with lock */
src_page = get_meta_page(sbi, src_off);
-
-   /* Dirty src_page means that it is already the new target NAT page. */
-   if (PageDirty(src_page))
-   return src_page;
-
dst_page = grab_meta_page(sbi, dst_off);
+   f2fs_bug_on(PageDirty(src_page));
 
src_addr = page_address(src_page);
dst_addr = page_address(dst_page);
@@ -1742,7 +1739,90 @@ skip:
return err;
 }
 
-static bool flush_nats_in_journal(struct f2fs_sb_info *sbi)
+static struct nat_entry_set *grab_nat_entry_set(void)
+{
+   struct nat_entry_set *nes =
+   f2fs_kmem_cache_alloc(nat_entry_set_slab, GFP_NOFS);
+
+   nes->entry_cnt = 0;
+   INIT_LIST_HEAD(>set_list);
+   INIT_LIST_HEAD(>entry_list);
+   return nes;
+}
+
+static void release_nat_entry_set(struct nat_entry_set *nes,
+   struct f2fs_nm_info *nm_i)
+{
+   f2fs_bug_on(!list_empty(nes->entry_list));
+
+   nm_i->dirty_nat_cnt -= nes->entry_cnt;
+   list_del(>set_list);
+   kmem_cache_free(nat_entry_set_slab, nes);
+}
+
+static void adjust_nat_entry_set(struct nat_entry_set *nes,
+   struct list_head *head)
+{
+   struct nat_entry_set *next = nes;
+
+   if (list_is_last(>set_list, head))
+   return;
+
+   list_for_each_entry_continue(next, head, set_list)
+   if (nes->entry_cnt <= next->entry_cnt)
+   break;
+
+   list_move_tail(>set_list, >set_list);
+}
+
+static void add_nat_entry(struct nat_entry *ne, struct 

[PATCH] Check if skb_alloc returns Null in function fw_download_code

[Nicholas Krause]

Signed-off-by: Nicholas Krause 
---
 drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c 
b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
index 1a95d1f..11e915e 100644
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
@@ -61,11 +61,13 @@ static bool fw_download_code(struct net_device *dev, u8 
*code_virtual_address,
}
 
skb  = dev_alloc_skb(frag_length + 4);
+   if (!skb) {
memcpy((unsigned char *)(skb->cb), , sizeof(dev));
tcb_desc = (struct cb_desc *)(skb->cb + MAX_DEV_ADDR_SIZE);
tcb_desc->queue_index = TXCMD_QUEUE;
tcb_desc->bCmdOrInit = DESC_PACKET_TYPE_INIT;
tcb_desc->bLastIniPkt = bLastIniPkt;
+   }
 
seg_ptr = skb->data;
for (i = 0; i < frag_length; i += 4) {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mm/sched/net: BUG when running simple code

[Sasha Levin]

On 06/13/2014 12:13 AM, Dave Jones wrote:
> On Fri, Jun 13, 2014 at 12:01:37AM -0400, Sasha Levin wrote:
>  > On 06/12/2014 11:27 PM, Dan Aloni wrote:
>  > > On Thu, Jun 12, 2014 at 10:56:16PM -0400, Sasha Levin wrote:
>  > >> > Hi all,
>  > >> > 
>  > >> > Okay, I'm really lost. I got the following when fuzzing, and can't 
> really explain what's
>  > >> > going on. It seems that we get a "unable to handle kernel paging 
> request" when running
>  > >> > rather simple code, and I can't figure out how it would cause it.
>  > > [..]
>  > >> > Which agrees with the trace I got:
>  > >> > 
>  > >> > [  516.309720] BUG: unable to handle kernel paging request at 
> a0f12560
>  > >> > [  516.309720] IP: netlink_getsockopt (net/netlink/af_netlink.c:2271)
>  > > [..]
>  > >> > [  516.309720] RIP netlink_getsockopt (net/netlink/af_netlink.c:2271)
>  > >> > [  516.309720]  RSP 
>  > >> > [  516.309720] CR2: a0f12560
>  > >> > 
>  > >> > They only theory I had so far is that netlink is a module, and has 
> gone away while the code
>  > >> > was executing, but netlink isn't a module on my kernel.
>  > > The RIP - 0xa0f12560 is in the range (from 
> Documentation/x86/x86_64/mm.txt):
>  > > 
>  > > a000 - ff5f (=1525 MB) module mapping space
>  > > 
>  > > So seems it was in a module.
>  > 
>  > Yup, that's why that theory came up, but when I checked my config:
>  > ... 
>  > that theory went away. (also confirmed by not finding a netlink module.)
>  > 
>  > What about the kernel .text overflowing into the modules space? The loader
>  > checks for that, but can something like that happen after everything is
>  > up and running? I'll look into that tomorrow.
> 
> another theory: Trinity can sometimes generate plausible looking module
> addresses and pass those in structs etc.
> 
> I wonder if there's somewhere in that path that isn't checking that the 
> address
> in the optval it got is actually a userspace address before it tries to write 
> to it.

It happened again, and this time I've left the kernel addresses in, and it's 
quite
interesting:

[   88.837926] Call Trace:
[   88.837926]  [] __sock_create+0x292/0x3c0
[   88.837926]  [] ? __sock_create+0x110/0x3c0
[   88.837926]  [] sock_create+0x30/0x40
[   88.837926]  [] SyS_socket+0x2c/0x70
[   88.837926]  [] ? tracesys+0x7e/0xe6
[   88.837926]  [] tracesys+0xe1/0xe6

tracesys() seems to live inside a module space here?


Thanks,
Sasha

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] checkpatch: Warn on unnecessary void function return statements

[Sachin Kamat]

On Tue, Jun 17, 2014 at 7:30 AM, Joe Perches  wrote:
> On Mon, 2014-06-16 at 17:44 -0700, Anish Bhatt wrote:
>> My code has multiple exit lables:
>> void function(void)
>> {
>>   ...
>>
>>   if (err1)
>>   goto exit1;
>>   ...
>>   if (err2)
>>   goto exit2;
>>
>>   ...
>>   return; /* Good return, no errors */
>> exit1:
>>   printk(err1);
>>   return;
>> exit2:
>>   printk(err2);
>> }
>>
>> The single tabbed return was required to prevent the good return & err1
>> messages cascading down. The extra exit label with a noop looks weird,
>> but is passing checkpatch.pl --strict, so I will go with that, thanks.
>> -Anish
>>
>
> Hmm, those return uses seem reasonable
> to me.
>
> Perhaps the test should warn only on
> this specific 3 line sequence:
>
> [any line but a label]
> return;
> }
>
> Andrew?  Anyone else?  Opinions?

It should warn only if the return is followed by a value like
return 0; or return -EERROR_CODE; etc. and not just 'return;'


-- 
Regards,
Sachin.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ALSA: compress: Fix the mismatch size of struc between share lib(32bit) and kernel(64bit)

[Vinod Koul]

On Fri, Jun 13, 2014 at 04:19:32PM +0200, Arnd Bergmann wrote:
> On Monday 09 June 2014, Vinod Koul wrote:
> > On Mon, Jun 09, 2014 at 09:24:53AM +0200, Takashi Iwai wrote:
> > > At Mon, 09 Jun 2014 16:46:32 -0400,
> > > Wang, Xiaoming wrote:
> > > > 
> > > > 
> > > > The size of struct snd_compr_avail is 0x1c in 32bit kernel,
> > > > while it is 0x20 in 64bit kernel 0x4 bytes added because of
> > > > alignment. It is OK when 32bit kernel met 32bit user space.
> > > > There exist stack corruption if 64bit kernel met 32bit user
> > > > space, because the size of struct snd_compr_avail is 0x1c
> > > > in 32bit user space which is smaller than it will get from
> > > > kernel. The extra 4 bytes can corrupt the stack, and
> > > > introduce unpredictable error.
> > > > 
> > > > Signed-off-by: Zhang Dongxing 
> > > > Signed-off-by: xiaoming wang 
> > > 
> > > This would break the existing 32bit systems, so I don't think we can
> > > take this approach.
> > > 
> > > Either break the 64bit systems (which aren't deployed yet much, so
> > > far) by adding packed attribute, or implement 32/64 bit conversion in
> > > compat_ioctl fop.
> > I think former should be safe for now. Anyway we have only 1 driver using 
> > this
> > in mainline so fallout shouldn't be widespread!
> 
> I guess since the driver was only merged for 3.16, we don't
> really have to worry about the ABI breakage anyway, but you can
> still use that approach if you have reason to stay compatible with
> existing used space built against out-of-tree drivers.
The qcom has on out of tree driver, but not sure if they have used on 64bit so
they might not be impacted.

> Anyway, if you use the __packed attribute, best apply it only to
> the individual __u64 member(s), not the entire struct, otherwise
> you might change user space programs in a subtle way when the alignment
> changes from 4 to 1 byte. 
then wouldn't it make sense to call out the aligned as well to ensure that it is
aligning to what we want. Then we should add aligned (4) everywhere as mostly we
need 4 byte aligned here

-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] epoll: fix use-after-free in eventpoll_release_file

[Konstantin Khlebnikov]

On Tue, Jun 17, 2014 at 6:58 AM, Konstantin Khlebnikov  wrote:
> This fixes use-after-free of epi->fllink.next inside list loop macro.
> This loop actually releases elements in the body. List is rcu-protected
> but here we cannot hold rcu_read_lock because we need to lock mutex inside.
>
> Obvious solution is to use list_for_each_entry_safe(). RCU-ness isn't 
> essential
> because nobody can change this list under us, it's final fput for this file.
>
> Bug is here since ae10b2b4eb01bedc91d29d5c5bb9e416fd806c40
> ("epoll: optimize EPOLL_CTL_DEL using rcu")
>
> Signed-off-by: Konstantin Khlebnikov 
> Reported-by: Cyrill Gorcunov 
> Cc: Stable  # 3.13+
> Cc: Sasha Levin 
> Cc: Jason Baron 
> ---

oops from Cyrill's report
https://plus.google.com/+CyrillGorcunov/posts/RPGi1ECc3Tk

[   14.448483] general protection fault:  [#1] [   14.448483]
general protection fault:  [#1] PREEMPT PREEMPT SMP SMP

[   14.448533] Modules linked in:[   14.448533] Modules linked in:

[   14.448533] CPU: 0 PID: 1153 Comm: plymouthd Not tainted 3.16.0-rc1 #463
[   14.448533] CPU: 0 PID: 1153 Comm: plymouthd Not tainted 3.16.0-rc1 #463
[   14.448533] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   14.448533] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   14.448533] task: 880037a28f50 ti: 880037a2c000 task.ti:
880037a2c000
[   14.448533] task: 880037a28f50 ti: 880037a2c000 task.ti:
880037a2c000
[   14.448533] RIP: 0010:[] [   14.448533] RIP:
0010:[]  []
__lock_acquire+0xeb/0xf07
 [] __lock_acquire+0xeb/0xf07
[   14.448533] RSP: 0018:880037a2fcf0  EFLAGS: 00010002
[   14.448533] RSP: 0018:880037a2fcf0  EFLAGS: 00010002
[   14.448533] RAX: 6b6b6b6b6b6b6b6b RBX: 880037a28f50 RCX: 
[   14.448533] RAX: 6b6b6b6b6b6b6b6b RBX: 880037a28f50 RCX: 
[   14.448533] RDX:  RSI:  RDI: 88003b960200
[   14.448533] RDX:  RSI:  RDI: 88003b960200
[   14.448533] RBP: 880037a2fd88 R08: 0001 R09: 
[   14.448533] RBP: 880037a2fd88 R08: 0001 R09: 
[   14.448533] R10:  R11:  R12: 880037a28f50
[   14.448533] R10:  R11:  R12: 880037a28f50
[   14.448533] R13:  R14: 0001 R15: 88003b960200
[   14.448533] R13:  R14: 0001 R15: 88003b960200
[   14.448533] FS:  7fafb700d740() GS:88003fc0()
knlGS:
[   14.448533] FS:  7fafb700d740() GS:88003fc0()
knlGS:
[   14.448533] CS:  0010 DS:  ES:  CR0: 80050033
[   14.448533] CS:  0010 DS:  ES:  CR0: 80050033
[   14.448533] CR2: 7fd6cc054414 CR3: 378ee000 CR4: 06f0
[   14.448533] CR2: 7fd6cc054414 CR3: 378ee000 CR4: 06f0
[   14.448533] Stack:
[   14.448533] Stack:
[   14.448533]  8800[   14.448533]  8800
8801 8801  
8800 8800

[   14.448533]  [   14.448533]  
88003fdcd2b0 88003fdcd2b0 81c41d80 81c41d80
880037a2fe30 880037a2fe30

[   14.448533]  81303a7e[   14.448533]  81303a7e
   
009c0496 009c0496

[   14.448533] Call Trace:
[   14.448533] Call Trace:
[   14.448533]  [] ? trace_hardirqs_on_thunk+0x3a/0x3f
[   14.448533]  [] ? trace_hardirqs_on_thunk+0x3a/0x3f
[   14.448533]  [] lock_acquire+0xfe/0x146
[   14.448533]  [] lock_acquire+0xfe/0x146
[   14.448533]  [] ? eventpoll_release_file+0x68/0xc1
[   14.448533]  [] ? eventpoll_release_file+0x68/0xc1
[   14.448533]  [] ? eventpoll_release_file+0x68/0xc1
[   14.448533]  [] ? eventpoll_release_file+0x68/0xc1
[   14.448533]  [] mutex_lock_nested+0x77/0x3f0
[   14.448533]  [] mutex_lock_nested+0x77/0x3f0
[   14.448533]  [] ? eventpoll_release_file+0x68/0xc1
[   14.448533]  [] ? eventpoll_release_file+0x68/0xc1
[   14.448533]  [] ? eventpoll_release_file+0x68/0xc1
[   14.448533]  [] ? eventpoll_release_file+0x68/0xc1
[   14.448533]  [] eventpoll_release_file+0x68/0xc1
[   14.448533]  [] eventpoll_release_file+0x68/0xc1
[   14.448533]  [] __fput+0xc5/0x1b6
[   14.448533]  [] __fput+0xc5/0x1b6
[   14.448533]  [] fput+0xe/0x10
[   14.448533]  [] fput+0xe/0x10
[   14.448533]  [] task_work_run+0x7d/0xa6
[   14.448533]  [] task_work_run+0x7d/0xa6
[   14.448533]  [] do_notify_resume+0x63/0x68
[   14.448533]  [] do_notify_resume+0x63/0x68
[   14.448533]  [] int_signal+0x12/0x17
[   14.448533]  [] int_signal+0x12/0x17
[   14.448533] Code: [   14.448533] Code: 85 85 c0 c0 75 75 27 27 31
31 d2 d2 4c 4c 89 89 ff ff 44 44 89 89 4c 4c 24 24 08 08 44 44 89 89
44 44 24 24 10 10 e8 e8 10 10 f7 f7 ff ff ff ff 48 48 85 85 c0 c0 

linux-next: Tree for Jun 17

[Stephen Rothwell]

Hi all,

The powerpc allyesconfig is again broken more than usual.

Changes since 20140616:

Non-merge commits (relative to Linus' tree): 713
 923 files changed, 20546 insertions(+), 12891 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 219 trees (counting Linus' and 29 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (7171511eaec5 Linux 3.16-rc1)
Merging fixes/master (4b660a7f5c80 Linux 3.15-rc6)
Merging kbuild-current/rc-fixes (7171511eaec5 Linux 3.16-rc1)
Merging arc-current/for-curr (89ca3b881987 Linux 3.15-rc4)
Merging arm-current/fixes (3f8517e7937d ARM: 8063/1: bL_switcher: fix 
individual online status reporting of removed CPUs)
Merging m68k-current/for-linus (e8d6dc5ad26e m68k/hp300: Convert printk to 
pr_foo())
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging powerpc-merge/merge (68986c9f0f45 Revert "offb: Add palette hack for 
little endian")
Merging sparc/master (8ecc1bad4c9b sparc64: fix format string mismatch in 
arch/sparc/kernel/sysfs.c)
Merging net/master (7171511eaec5 Linux 3.16-rc1)
Merging ipsec/master (7171511eaec5 Linux 3.16-rc1)
Merging sound-current/for-linus (74b0c2d75fb4 drm/i915, HD-audio: Don't 
continue probing when nomodeset is given)
Merging pci-current/for-linus (d0b4cc4e3270 PCI: Wrong register used to check 
pending traffic)
Merging wireless/master (740bb82b7655 b43: fix typo in Kconfig (make 
B43_BUSES_BCMA_AND_SSB the default for real))
Merging driver-core.current/driver-core-linus (4b660a7f5c80 Linux 3.15-rc6)
Merging tty.current/tty-linus (d6d211db37e7 Linux 3.15-rc5)
Merging usb.current/usb-linus (5dc2808c4729 xhci: delete endpoints from 
bandwidth list before freeing whole device)
Merging usb-gadget-fixes/fixes (886c7c426d46 usb: gadget: at91-udc: fix irq and 
iomem resource retrieval)
Merging staging.current/staging-linus (9326c5ca0982 staging: r8192e_pci: fix 
htons error)
Merging char-misc.current/char-misc-linus (d1db0eea8524 Linux 3.15-rc3)
Merging input-current/for-linus (31972f6e517d Input: ti_am335x_tsc - warn about 
incorrect spelling)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (3901c1124ec5 crypto: s390 - fix aes,des ctr mode 
concurrency finding.)
Merging ide/master (5b40dd30bbfa ide: Fix SC1200 dependencies)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (4b660a7f5c80 Linux 3.15-rc6)
Merging rr-fixes/fixes (79465d2fd48e module: remove warning about waiting 
module removal.)
Merging mfd-fixes/master (73beb63d290f mfd: rtsx_pcr: Disable interrupts before 
cancelling delayed works)
Merging vfio-fixes/for-linus (239a87020b26 Merge branch 
'for-joerg/arm-smmu/fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into for-linus)
Merging drm-intel-fixes/for-linux-next-fixes (15d24aa5602f drm/i915: BDW: 
Adding missing cursor offsets.)
Merging asm-generic/master (fb9de7ebc3a2 xtensa: Use generic asm/mmu.h for 
nommu)
Merging arc/for-next (230a15f171ba ARC: remove checks for CONFIG_ARC_MMU_V4)
Merging arm/for-next (bd63ce27d9d6 Merge branch 'devel-stable' into for-next)
Merging arm-perf/for-next/perf (7171511eaec5 Linux 3.16-rc1)
Merging arm-soc/for-next (f2592714cddc ARM: use menuconfig for sub-arch menus)
Merging bcm2835/for-next (fa389e220254 Linux 3.14-rc6)
Merging berlin/berlin/for-next (8a26730ea69

[PATCH] epoll: fix use-after-free in eventpoll_release_file

[Konstantin Khlebnikov]

This fixes use-after-free of epi->fllink.next inside list loop macro.
This loop actually releases elements in the body. List is rcu-protected
but here we cannot hold rcu_read_lock because we need to lock mutex inside.

Obvious solution is to use list_for_each_entry_safe(). RCU-ness isn't essential
because nobody can change this list under us, it's final fput for this file.

Bug is here since ae10b2b4eb01bedc91d29d5c5bb9e416fd806c40
("epoll: optimize EPOLL_CTL_DEL using rcu")

Signed-off-by: Konstantin Khlebnikov 
Reported-by: Cyrill Gorcunov 
Cc: Stable  # 3.13+
Cc: Sasha Levin 
Cc: Jason Baron 
---
 fs/eventpoll.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index b73e062..b10b48c 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -910,7 +910,7 @@ static const struct file_operations eventpoll_fops = {
 void eventpoll_release_file(struct file *file)
 {
struct eventpoll *ep;
-   struct epitem *epi;
+   struct epitem *epi, *next;
 
/*
 * We don't want to get "file->f_lock" because it is not
@@ -926,7 +926,7 @@ void eventpoll_release_file(struct file *file)
 * Besides, ep_remove() acquires the lock, so we can't hold it here.
 */
mutex_lock();
-   list_for_each_entry_rcu(epi, >f_ep_links, fllink) {
+   list_for_each_entry_safe(epi, next, >f_ep_links, fllink) {
ep = epi->ep;
mutex_lock_nested(>mtx, 0);
ep_remove(ep, epi);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH 1/1] kernel/rcu/tree.c: simplify force_quiescent_state()

[Pranith Kumar]

This might sound really naive, but please bear with me.

force_quiescent_state() used to do a lot of things in the past in addition to
forcing a quiescent state. (In my reading of the mailing list I found state
transitions for one). 

Now according to the code, what is being done is multiple callers try to go up
the hierarchy of nodes to see who reaches the root node. The caller reaching the
root node wins and it acquires root node lock and it gets to set rsp->gp_flags!

At each level of the hierarchy we try to acquire fqslock. This is the only place
which actually uses fqslock. 

I guess this was being done to avoid the contention on fqslock, but all we are
doing here is setting one flag. This way of acquiring locks might reduce
contention if every update is trying to do some independent work, but here all
we are doing is setting the same flag with same value.

We can also remove fqslock completely if we do not need this. Also using
cmpxchg() to set the value of the flag looks like a good idea to avoid taking
the root node lock. Thoughts?

Signed-off-by: Pranith Kumar 
---
 kernel/rcu/tree.c | 35 +--
 1 file changed, 13 insertions(+), 22 deletions(-)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index f1ba773..9a46f32 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2399,36 +2399,27 @@ static void force_qs_rnp(struct rcu_state *rsp,
 static void force_quiescent_state(struct rcu_state *rsp)
 {
unsigned long flags;
-   bool ret;
-   struct rcu_node *rnp;
-   struct rcu_node *rnp_old = NULL;
-
-   /* Funnel through hierarchy to reduce memory contention. */
-   rnp = per_cpu_ptr(rsp->rda, raw_smp_processor_id())->mynode;
-   for (; rnp != NULL; rnp = rnp->parent) {
-   ret = (ACCESS_ONCE(rsp->gp_flags) & RCU_GP_FLAG_FQS) ||
- !raw_spin_trylock(>fqslock);
-   if (rnp_old != NULL)
-   raw_spin_unlock(_old->fqslock);
-   if (ret) {
-   ACCESS_ONCE(rsp->n_force_qs_lh)++;
-   return;
-   }
-   rnp_old = rnp;
+   struct rcu_node *rnp_root = rcu_get_root(rsp);
+
+   /* early test to see if someone already forced a quiescent state
+*/
+   if (ACCESS_ONCE(rsp->gp_flags) & RCU_GP_FLAG_FQS) {
+   ACCESS_ONCE(rsp->n_force_qs_lh)++;
+   return;  /* Someone beat us to it. */
}
-   /* rnp_old == rcu_get_root(rsp), rnp == NULL. */
 
/* Reached the root of the rcu_node tree, acquire lock. */
-   raw_spin_lock_irqsave(_old->lock, flags);
+   raw_spin_lock_irqsave(_root->lock, flags);
smp_mb__after_unlock_lock();
-   raw_spin_unlock(_old->fqslock);
if (ACCESS_ONCE(rsp->gp_flags) & RCU_GP_FLAG_FQS) {
ACCESS_ONCE(rsp->n_force_qs_lh)++;
-   raw_spin_unlock_irqrestore(_old->lock, flags);
-   return;  /* Someone beat us to it. */
+   raw_spin_unlock_irqrestore(_root->lock, flags);
+   return;  /* Someone actually beat us to it. */
}
+
+   /* can we use cmpxchg instead of the above lock? */
ACCESS_ONCE(rsp->gp_flags) |= RCU_GP_FLAG_FQS;
-   raw_spin_unlock_irqrestore(_old->lock, flags);
+   raw_spin_unlock_irqrestore(_root->lock, flags);
wake_up(>gp_wq);  /* Memory barrier implied by wake_up() path. */
 }
 
-- 
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] deb-pkg: Fix for relative paths

[Alexei Starovoitov]

On Mon, Jun 16, 2014 at 7:18 AM, Michal Marek  wrote:
> When $srctree or $objtree are relative paths, we cannot change directory
> and refer to them in the same subshell. Do the redirection outside of
> the subshell to fix this.
>
> Reported-by: Ilya Dryomov 
> Signed-off-by: Michal Marek 
> ---
>  scripts/package/builddeb | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

this patch didn't help to fix the broken deb-pkg for me:

../scripts/Makefile.build:44: ../../scripts/package/Makefile: No such
file or directory
make[2]: *** No rule to make target `../../scripts/package/Makefile'.  Stop.
make[1]: *** [deb-pkg] Error 2

steps to reproduce:
$ export KBUILD_OUTPUT=/make it out of src tree
$ make deb-pkg

> diff --git a/scripts/package/builddeb b/scripts/package/builddeb
> index b5f08f7..9a38e85 100644
> --- a/scripts/package/builddeb
> +++ b/scripts/package/builddeb
> @@ -290,13 +290,13 @@ EOF
>  fi
>
>  # Build header package
> -(cd $srctree; find . -name Makefile\* -o -name Kconfig\* -o -name \*.pl > 
> "$objtree/debian/hdrsrcfiles")
> -(cd $srctree; find arch/$SRCARCH/include include scripts -type f >> 
> "$objtree/debian/hdrsrcfiles")
> -(cd $objtree; find arch/$SRCARCH/include Module.symvers include scripts 
> -type f >> "$objtree/debian/hdrobjfiles")
> +(cd $srctree; find . -name Makefile\* -o -name Kconfig\* -o -name \*.pl) > 
> "$objtree/debian/hdrsrcfiles"
> +(cd $srctree; find arch/$SRCARCH/include include scripts -type f) >> 
> "$objtree/debian/hdrsrcfiles"
> +(cd $objtree; find arch/$SRCARCH/include Module.symvers include scripts 
> -type f) >> "$objtree/debian/hdrobjfiles"
>  destdir=$kernel_headers_dir/usr/src/linux-headers-$version
>  mkdir -p "$destdir"
> -(cd $srctree; tar -c -f - -T "$objtree/debian/hdrsrcfiles") | (cd $destdir; 
> tar -xf -)
> -(cd $objtree; tar -c -f - -T "$objtree/debian/hdrobjfiles") | (cd $destdir; 
> tar -xf -)
> +(cd $srctree; tar -c -f - -T -) < "$objtree/debian/hdrsrcfiles" | (cd 
> $destdir; tar -xf -)
> +(cd $objtree; tar -c -f - -T -) < "$objtree/debian/hdrobjfiles" | (cd 
> $destdir; tar -xf -)
>  (cd $objtree; cp $KCONFIG_CONFIG $destdir/.config) # copy .config manually 
> to be where it's expected to be
>  ln -sf "/usr/src/linux-headers-$version" 
> "$kernel_headers_dir/lib/modules/$version/build"
>  rm -f "$objtree/debian/hdrsrcfiles" "$objtree/debian/hdrobjfiles"
> --
> 1.9.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFD] sched/deadline: EDF dynamic quota design

[xiaofeng.yan]

On 2014/5/21 20:45, Luca Abeni wrote:

Hi,

first of all, sorry for the ultra-delayed reply: I've been busy,
and I did not notice this email... Anyway, some comments are below

On 05/16/2014 09:11 AM, Henrik Austad wrote:
[...]

This can also be implemented in user-space (without modifying the
scheduler)
by having a daemon that monitors the SCHED_DEADLINE tasks and changes
their
runtimes based on some kind of feedback (for example, difference
between the
scheduling deadline of a task and its actual deadline - if this
information
is made available by the scheduler). I developed a similar
implementation in
the past (not based on SCHED_DEADLINE, but on some previous
implementation
of the CBS algorithm).


This sounds like a very slow approach. What if the extra BW given by 
T2 was
for one period only? There's no way you could create a userspace 
daemon to

handle that kind of budget-tweaking.
Right. With "This can also be implemented in user-space..." I was 
referring
to the feedback scheduling (adaptive reservation) approach, which is 
designed
to "auto-tune" the reservation budget following slower variations (it 
is like
a low-pass filter, which can set the budget to something between the 
average
used budget and the largest one). Basically, it works on a larger time 
scale.
If you want a "per-period" runtime donation, you need a reclaiming 
mechanism

like GRUB, CASH, or similar, which needs to be implemented in the kernel.



Also, it sounds like a *really* dangerous idea to let some random (tm)
userspace daemon adjust the deadline-budget for other tasks in the 
system

based on an observation of spent budget for the last X seconds. It's not
military funding we're concerned with here.

When you state your WCET, it is not because you need -exactly- that 
budget,

it is because you should *never* exceed that kind of rquired
computational time.
Exact. But the idea of feedback scheduling was that sometimes you do 
not know
the WCET... You can guess it, or measure it over a large number of 
runs (but

the Murphy law ensures that you will miss the worst case anyway ;-).
And there are situations in which you do not need to respect all of the
deadlines... The daemon I was talking about just monitors the 
difference between
the scheduling deadline and the "real job deadline" for some tasks, in 
order to
understand if the runtime they have been assigned is enough or not... 
If some
task is not receiving enough runtime (that is, if the difference 
between its
scheduling deadline and the "real deadline" becomes too large), the 
daemon
tries to increase its runtime. When the system is overloaded (that is, 
everyone
of the monitored tasks wants too much runtime, and the admission 
control fails),

the daemon decreases the runtimes according to the weight of the tasks...
Of course, the daemon does not have to monitor all of the 
SCHED_DEADLINE tasks
in the system, but only the ones for which adaptive reservations are 
useful
(tasks for which the WCET is not known for sure, and that can 
tollerate some
missed deadlines). The other SCHED_DEADLINE tasks can stay with their 
fixed

runtimes unchanged.



Blindly reducing allocated runtime is defeating that whole purpose.

Of course, there could be a minimum guaranteed runtime per task.


Granted, if you use EDF for BW-control only, it could be done - but then
the thread itself should do that. Real-time is not about being fair. 
Heck,

it's not even about being optimal, it's about being predictable and
"dynamically adjusting" is not!
Well, this could lead to a long discussion, in which everyone is right 
and
everyone is wrong... Let's say that it depends on the applications 
requirements

and constraints.

[...]

Will EDF has dynamic quota in future?


Well, as Luca said, you can already use SCHED_DEADLINE as the backend
for feedback scheduling (that pertain mostly to user-space).

And yes, there are already thoughts to modify it a bit to go towards
Lipari's et al. GRUB algorithm. That would be probably helpful in
situations like yours. But I can't give you any timing for it.


Need to read up on GRUB before involving myself in this part of the
discussion, but I'm not sure how much I enjoy the idea of some part of
userspace (more or less) blindly adjusting deadline-params for other 
tasks.
No, GRUB does not involve the user-space adjusting any scheduling 
parameter.

GRUB is a reclaiming algorithm, which works in a different way respect to
the feedback scheduling approach I described, and requires 
modifications in

the scheduler.
The basic ideas are (warning! This is an over-simplification of the 
algorithm! :)

- You assign runtime and period to each SCHED_DEADLINE task as usual
- Each task is guaranteed to receive its runtime every period
- You can also define a maximum fraction Umax of the CPU time that the
  SCHED_DEADLINE tasks can use. Note that Umax _must_ be larger or equal
  than sum_i runtime_i / period_i
  (note: in the original GRUB paper, only one CPU is 

Re: [RFC PATCH 2/2] block: virtio-blk: support multi virt queues per virtio-blk device

[Stefan Hajnoczi]

On Sat, Jun 14, 2014 at 1:29 AM, Ming Lei  wrote:
> Firstly this patch supports more than one virtual queues for virtio-blk
> device.
>
> Secondly this patch maps the virtual queue to blk-mq's hardware queue.
>
> With this approach, both scalability and performance problem can be improved.
>
> Signed-off-by: Ming Lei 
> ---
>  drivers/block/virtio_blk.c |   75 
> 
>  1 file changed, 55 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index f63d358..e0d077d 100644
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -16,6 +16,8 @@
>
>  #define PART_BITS 4
>
> +#define MAX_NUM_VQ 16

It would be nice to allocate virtqueues dynamically instead of
hardcoding the limit.  virtio-scsi also allocates virtqueues
dynamically.

Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net/cadence/macb: clear interrupts simply and correctly

[Jongsung Kim]

On 06/16/2014 11:56 PM, Sören Brinkmann wrote:
> On Mon, 2014-06-16 at 02:00PM +0900, Jongsung Kim wrote:
>> On 06/13/2014 12:44 AM, Sören Brinkmann wrote:
>>> This is now clearing all IRQ flags which is probably not what we want
>>> here. This is handling RX only. We still want the non-RX interrupts to go to
>>> the actual interrupt service routing.
>>
>> The ISR(Interrupt Status Register) is read only in the interrupt service
>> routine, macb_interrupt. But is partially cleared here and there. Further
>> handler-functions decide jobs to be done by reading/checking other status
>> registers. (e.g., TSR, RSR) So, clearing the ISR after reading looks not
>> a bad idea.
>
> But you are clearing _all_ interrupt flags in the RX NAPI handler.
> Doesn't that mean we might miss certain events?

Please inspect my patch again. What I did in the macb_poll is removing
statements clearing the Rx-complete interrupt, not clearing all the
interrupts.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] lib.c: skip --param parameters

[Josh Triplett]

On Mon, Jun 16, 2014 at 04:48:51PM -0700, David Rientjes wrote:
> On Mon, 16 Jun 2014, Josh Triplett wrote:
> 
> > On Mon, Jun 16, 2014 at 01:43:06PM +0300, Andy Shevchenko wrote:
> > > Very dumb patch to just skip --param allow-store-data-races=0 introduced 
> > > in
> > > newest Linux kernel buildsystem.
> > > 
> > > Actually the option is present in few GCC versions and probably should be
> > > handled properly.
> > > 
> > > Signed-off-by: Andy Shevchenko 
> > 
> > As far as I can tell, this seems to only handle "--param arg"; however,
> > according to the thread on LKML, GCC handles --param=arg as well.  Could
> > you please handle that variant too?
> > 
> 
> This is only from linux-next and not Linus's tree, correct?
> 
> Is this still necessary since the "./Makefile: tell gcc optimizer to never 
> introduce new data races" patch has been removed from -mm due to failures?
> 
> See http://marc.info/?l=linux-mm-commits=140295825623471

I'd still like to see Sparse not choke on the option, in either form,
whether the kernel ends up using it or not.

- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [f2fs-dev] [PATCH] f2fs: refactor flush_nat_entries codes for reducing NAT writes

[Chao Yu]

Hi all,

There are problem in this patch, please ignore this patch, sorry for the noise.
I will resend later.

> -Original Message-
> From: Chao Yu [mailto:chao2...@samsung.com]
> Sent: Saturday, June 14, 2014 7:48 PM
> To: Jaegeuk Kim
> Cc: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Subject: [f2fs-dev] [PATCH] f2fs: refactor flush_nat_entries codes for 
> reducing NAT writes
> 
> Although building NAT journal in cursum reduce the read/write work for NAT
> block, but previous design leave us lower performance when write checkpoint
> frequently for these cases:
> 1. if journal in cursum has already full, it's a bit of waste that we flush 
> all
>nat entries to page for persistence, but not to cache any entries.
> 2. if journal in cursum is not full, we fill nat entries to journal util
>journal is full, then flush the left dirty entries to disk without merge
>journaled entries, so these journaled entries may be flushed to disk at 
> next
>checkpoint but lost chance to flushed last time.
> 
> In this patch we merge dirty entries located in same NAT block to nat entry 
> set,
> and linked all set to list, sorted ascending order by entries' count of set.
> Later we flush entries in sparse set into journal as many as we can, and then
> flush merged entries to disk.
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 7/8] x86_64,vsyscall: Rewrite comment and clean up headers in vsyscall code

[Andy Lutomirski]

vsyscall_64.c is just vsyscall emulation.  Tidy it up accordingly.

If my comment editing offends anyone, let me know and I can fix it.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/kernel/vsyscall_64.c | 51 +++
 1 file changed, 18 insertions(+), 33 deletions(-)

diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
index 5029be3..1ea34e7 100644
--- a/arch/x86/kernel/vsyscall_64.c
+++ b/arch/x86/kernel/vsyscall_64.c
@@ -1,52 +1,37 @@
 /*
- *  Copyright (C) 2001 Andrea Arcangeli  SuSE
- *  Copyright 2003 Andi Kleen, SuSE Labs.
+ * Mostly copyright (c) 2012-2014 Andy Lutomirski 
  *
- *  [ NOTE: this mechanism is now deprecated in favor of the vDSO. ]
+ * This file implements vsyscall emulation.  vsyscalls are a legacy ABI:
+ * userspace can request certain kernel services by calling fixed
+ * addresses.  This concept is problematic:
  *
- *  Thanks to h...@transmeta.com for some useful hint.
- *  Special thanks to Ingo Molnar for his early experience with
- *  a different vsyscall implementation for Linux/IA32 and for the name.
+ * - It interferes with ASLR.
+ * - It's awkward to write code that lives in kernel addresses but is
+ *   callable by userspace at fixed addresses.
+ * - The whole concept is impossible for 32-bit compat userspace.
+ * - UML cannot easily virtualize a vsyscall.
  *
- *  vsyscall 1 is located at -10Mbyte, vsyscall 2 is located
- *  at virtual address -10Mbyte+1024bytes etc... There are at max 4
- *  vsyscalls. One vsyscall can reserve more than 1 slot to avoid
- *  jumping out of line if necessary. We cannot add more with this
- *  mechanism because older kernels won't return -ENOSYS.
+ * As of mid-2014, I believe that there is no new userspace code that
+ * will use a vsyscall if the vDSO is present.  I hope that there will
+ * soon be no new userspace code that will ever use a vsyscall.
  *
- *  Note: the concept clashes with user mode linux.  UML users should
- *  use the vDSO.
+ * The code in this file emulates vsyscalls when notified of a page
+ * fault to a vsyscall address.
+ *
+ * The original version of this code is:
+ * Copyright (C) 2001 Andrea Arcangeli  SuSE
+ * Copyright 2003 Andi Kleen, SuSE Labs.
  */
 
-#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
-#include 
-#include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
 
 #include 
-#include 
-#include 
-#include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
 
 #define CREATE_TRACE_POINTS
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/8] x86_64,vsyscall: Move all of the gate_area code to vsyscall_64.c

[Andy Lutomirski]

This code exists for the sole purpose of making the vsyscall page
look sort of like real userspace memory.  Move it so that it lives
with the rest of the vsyscall code.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/kernel/vsyscall_64.c | 49 +++
 arch/x86/mm/init_64.c | 49 ---
 2 files changed, 49 insertions(+), 49 deletions(-)

diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
index e1e1e80..420c468 100644
--- a/arch/x86/kernel/vsyscall_64.c
+++ b/arch/x86/kernel/vsyscall_64.c
@@ -284,6 +284,55 @@ sigsegv:
 }
 
 /*
+ * A pseudo VMA to allow ptrace access for the vsyscall page.  This only
+ * covers the 64bit vsyscall page now. 32bit has a real VMA now and does
+ * not need special handling anymore:
+ */
+static const char *gate_vma_name(struct vm_area_struct *vma)
+{
+   return "[vsyscall]";
+}
+static struct vm_operations_struct gate_vma_ops = {
+   .name = gate_vma_name,
+};
+static struct vm_area_struct gate_vma = {
+   .vm_start   = VSYSCALL_ADDR,
+   .vm_end = VSYSCALL_ADDR + PAGE_SIZE,
+   .vm_page_prot   = PAGE_READONLY_EXEC,
+   .vm_flags   = VM_READ | VM_EXEC,
+   .vm_ops = _vma_ops,
+};
+
+struct vm_area_struct *get_gate_vma(struct mm_struct *mm)
+{
+#ifdef CONFIG_IA32_EMULATION
+   if (!mm || mm->context.ia32_compat)
+   return NULL;
+#endif
+   return _vma;
+}
+
+int in_gate_area(struct mm_struct *mm, unsigned long addr)
+{
+   struct vm_area_struct *vma = get_gate_vma(mm);
+
+   if (!vma)
+   return 0;
+
+   return (addr >= vma->vm_start) && (addr < vma->vm_end);
+}
+
+/*
+ * Use this when you have no reliable mm, typically from interrupt
+ * context. It is less reliable than using a task's mm and may give
+ * false positives.
+ */
+int in_gate_area_no_mm(unsigned long addr)
+{
+   return (addr & PAGE_MASK) == VSYSCALL_ADDR;
+}
+
+/*
  * Assume __initcall executes before all user space. Hopefully kmod
  * doesn't violate that. We'll find out if it does.
  */
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index df1a992..417ea05 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -1180,55 +1180,6 @@ int kern_addr_valid(unsigned long addr)
return pfn_valid(pte_pfn(*pte));
 }
 
-/*
- * A pseudo VMA to allow ptrace access for the vsyscall page.  This only
- * covers the 64bit vsyscall page now. 32bit has a real VMA now and does
- * not need special handling anymore:
- */
-static const char *gate_vma_name(struct vm_area_struct *vma)
-{
-   return "[vsyscall]";
-}
-static struct vm_operations_struct gate_vma_ops = {
-   .name = gate_vma_name,
-};
-static struct vm_area_struct gate_vma = {
-   .vm_start   = VSYSCALL_ADDR,
-   .vm_end = VSYSCALL_ADDR + PAGE_SIZE,
-   .vm_page_prot   = PAGE_READONLY_EXEC,
-   .vm_flags   = VM_READ | VM_EXEC,
-   .vm_ops = _vma_ops,
-};
-
-struct vm_area_struct *get_gate_vma(struct mm_struct *mm)
-{
-#ifdef CONFIG_IA32_EMULATION
-   if (!mm || mm->context.ia32_compat)
-   return NULL;
-#endif
-   return _vma;
-}
-
-int in_gate_area(struct mm_struct *mm, unsigned long addr)
-{
-   struct vm_area_struct *vma = get_gate_vma(mm);
-
-   if (!vma)
-   return 0;
-
-   return (addr >= vma->vm_start) && (addr < vma->vm_end);
-}
-
-/*
- * Use this when you have no reliable mm, typically from interrupt
- * context. It is less reliable than using a task's mm and may give
- * false positives.
- */
-int in_gate_area_no_mm(unsigned long addr)
-{
-   return (addr & PAGE_MASK) == VSYSCALL_ADDR;
-}
-
 static unsigned long probe_memory_block_size(void)
 {
/* start from 2g */
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/8] x86_64,vsyscall: Fix warn_bad_vsyscall log output

[Andy Lutomirski]

This commit in Linux 3.6:

commit c767a54ba0657e52e6edaa97cbe0b0a8bf1c1655
Author: Joe Perches 
Date:   Mon May 21 19:50:07 2012 -0700

x86/debug: Add KERN_ to bare printks, convert printks to 
pr_

caused warn_bad_vsyscall to output garbage in the middle of the
line.  Revert the bad part of it.

The printk in question isn't actually bare; the level is "%s".

The bug this fixes is purely cosmetic; backports are optional.

Cc: sta...@vger.kernel.org
Signed-off-by: Andy Lutomirski 
---
 arch/x86/kernel/vsyscall_64.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
index ea5b570..e1e1e80 100644
--- a/arch/x86/kernel/vsyscall_64.c
+++ b/arch/x86/kernel/vsyscall_64.c
@@ -81,10 +81,10 @@ static void warn_bad_vsyscall(const char *level, struct 
pt_regs *regs,
if (!show_unhandled_signals)
return;
 
-   pr_notice_ratelimited("%s%s[%d] %s ip:%lx cs:%lx sp:%lx ax:%lx si:%lx 
di:%lx\n",
- level, current->comm, task_pid_nr(current),
- message, regs->ip, regs->cs,
- regs->sp, regs->ax, regs->si, regs->di);
+   printk_ratelimited("%s%s[%d] %s ip:%lx cs:%lx sp:%lx ax:%lx si:%lx 
di:%lx\n",
+  level, current->comm, task_pid_nr(current),
+  message, regs->ip, regs->cs,
+  regs->sp, regs->ax, regs->si, regs->di);
 }
 
 static int addr_to_vsyscall_nr(unsigned long addr)
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/8] x86_64,vdso: Remove jiffies from the vvar page

[Andy Lutomirski]

I think that the jiffies vvar was once used for the vgetcpu cache.
That code is long gone, so let's just make jiffies be a normal
variable.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/include/asm/vvar.h | 1 -
 arch/x86/kernel/time.c  | 2 +-
 arch/x86/vdso/vgetcpu.c | 1 -
 3 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/vvar.h b/arch/x86/include/asm/vvar.h
index 5d2b9ad..5f6d407 100644
--- a/arch/x86/include/asm/vvar.h
+++ b/arch/x86/include/asm/vvar.h
@@ -44,7 +44,6 @@ extern char __vvar_page;
 
 /* DECLARE_VVAR(offset, type, name) */
 
-DECLARE_VVAR(0, volatile unsigned long, jiffies)
 DECLARE_VVAR(16, int, vgetcpu_mode)
 DECLARE_VVAR(128, struct vsyscall_gtod_data, vsyscall_gtod_data)
 
diff --git a/arch/x86/kernel/time.c b/arch/x86/kernel/time.c
index bf7ef5c..822773b 100644
--- a/arch/x86/kernel/time.c
+++ b/arch/x86/kernel/time.c
@@ -23,7 +23,7 @@
 #include 
 
 #ifdef CONFIG_X86_64
-__visible DEFINE_VVAR(volatile unsigned long, jiffies) = INITIAL_JIFFIES;
+__visible volatile unsigned long jiffies __cacheline_aligned = INITIAL_JIFFIES;
 #endif
 
 unsigned long profile_pc(struct pt_regs *regs)
diff --git a/arch/x86/vdso/vgetcpu.c b/arch/x86/vdso/vgetcpu.c
index 2f94b03..add1d98 100644
--- a/arch/x86/vdso/vgetcpu.c
+++ b/arch/x86/vdso/vgetcpu.c
@@ -7,7 +7,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/8] x86_64,vsyscall: Turn vsyscalls all the way off when vsyscall=none

[Andy Lutomirski]

I see no point in having an unusable read-only page sitting at
0xff60 when vsyscall=none.  Instead, skip mapping it and
remove it from /proc/PID/maps.

I kept the ratelimited warning when programs try to use a vsyscall
in this mode, since it may help admins avoid confusion.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/kernel/vsyscall_64.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
index 420c468..6463f9e 100644
--- a/arch/x86/kernel/vsyscall_64.c
+++ b/arch/x86/kernel/vsyscall_64.c
@@ -309,6 +309,8 @@ struct vm_area_struct *get_gate_vma(struct mm_struct *mm)
if (!mm || mm->context.ia32_compat)
return NULL;
 #endif
+   if (vsyscall_mode == NONE)
+   return NULL;
return _vma;
 }
 
@@ -329,7 +331,7 @@ int in_gate_area(struct mm_struct *mm, unsigned long addr)
  */
 int in_gate_area_no_mm(unsigned long addr)
 {
-   return (addr & PAGE_MASK) == VSYSCALL_ADDR;
+   return vsyscall_mode != NONE && (addr & PAGE_MASK) == VSYSCALL_ADDR;
 }
 
 /*
@@ -380,10 +382,12 @@ void __init map_vsyscall(void)
extern char __vsyscall_page;
unsigned long physaddr_vsyscall = __pa_symbol(&__vsyscall_page);
 
-   __set_fixmap(VSYSCALL_PAGE, physaddr_vsyscall,
-vsyscall_mode == NATIVE
-? PAGE_KERNEL_VSYSCALL
-: PAGE_KERNEL_VVAR);
+   if (vsyscall_mode != NONE)
+   __set_fixmap(VSYSCALL_PAGE, physaddr_vsyscall,
+vsyscall_mode == NATIVE
+? PAGE_KERNEL_VSYSCALL
+: PAGE_KERNEL_VVAR);
+
BUILD_BUG_ON((unsigned long)__fix_to_virt(VSYSCALL_PAGE) !=
 (unsigned long)VSYSCALL_ADDR);
 }
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 8/8] x86_64,vdso: Clean up vgetcpu init and merge the vdso initcalls

[Andy Lutomirski]

Now vdso/vma.c has a single initcall and no references to
"vsyscall".

Signed-off-by: Andy Lutomirski 
---
 arch/x86/vdso/vma.c | 61 +++--
 1 file changed, 22 insertions(+), 39 deletions(-)

diff --git a/arch/x86/vdso/vma.c b/arch/x86/vdso/vma.c
index 8973b4e..84df79b 100644
--- a/arch/x86/vdso/vma.c
+++ b/arch/x86/vdso/vma.c
@@ -1,7 +1,8 @@
 /*
- * Set up the VMAs to tell the VM about the vDSO.
  * Copyright 2007 Andi Kleen, SUSE Labs.
  * Subject to the GPL, v.2
+ *
+ * This contains most of the x86 vDSO kernel-side code.
  */
 #include 
 #include 
@@ -11,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -22,8 +22,6 @@
 
 #if defined(CONFIG_X86_64)
 unsigned int __read_mostly vdso64_enabled = 1;
-
-extern unsigned short vdso_sync_cpuid;
 #endif
 
 void __init init_vdso_image(const struct vdso_image *image)
@@ -41,20 +39,6 @@ void __init init_vdso_image(const struct vdso_image *image)
image->alt_len));
 }
 
-#if defined(CONFIG_X86_64)
-static int __init init_vdso(void)
-{
-   init_vdso_image(_image_64);
-
-#ifdef CONFIG_X86_X32_ABI
-   init_vdso_image(_image_x32);
-#endif
-
-   return 0;
-}
-subsys_initcall(init_vdso);
-#endif
-
 struct linux_binprm;
 
 /* Put the vdso above the (randomized) stack with another randomized offset.
@@ -237,12 +221,9 @@ __setup("vdso=", vdso_setup);
 #endif
 
 #ifdef CONFIG_X86_64
-/*
- * Assume __initcall executes before all user space. Hopefully kmod
- * doesn't violate that. We'll find out if it does.
- */
-static void vsyscall_set_cpu(int cpu)
+static void vgetcpu_cpu_init(void *arg)
 {
+   int cpu = smp_processor_id();
unsigned long d;
unsigned long node = 0;
 #ifdef CONFIG_NUMA
@@ -252,45 +233,47 @@ static void vsyscall_set_cpu(int cpu)
write_rdtscp_aux((node << 12) | cpu);
 
/*
-* Store cpu number in limit so that it can be loaded quickly
-* in user space in vgetcpu. (12 bits for the CPU and 8 bits for the 
node)
+* Store cpu number in limit so that it can be loaded quickly in
+* user space in vgetcpu. (12 bits for the CPU and 8 bits for
+* the node)
 */
d = 0x0f400ULL;
d |= cpu;
d |= (node & 0xf) << 12;
d |= (node >> 4) << 48;
 
-   write_gdt_entry(get_cpu_gdt_table(cpu), GDT_ENTRY_PER_CPU, , 
DESCTYPE_S);
-}
-
-static void cpu_vsyscall_init(void *arg)
-{
-   /* preemption should be already off */
-   vsyscall_set_cpu(raw_smp_processor_id());
+   write_gdt_entry(get_cpu_gdt_table(cpu),
+   GDT_ENTRY_PER_CPU, , DESCTYPE_S);
 }
 
 static int
-cpu_vsyscall_notifier(struct notifier_block *n, unsigned long action, void 
*arg)
+vgetcpu_cpu_notifier(struct notifier_block *n, unsigned long action, void *arg)
 {
long cpu = (long)arg;
 
if (action == CPU_ONLINE || action == CPU_ONLINE_FROZEN)
-   smp_call_function_single(cpu, cpu_vsyscall_init, NULL, 1);
+   smp_call_function_single(cpu, vgetcpu_cpu_init, NULL, 1);
 
return NOTIFY_DONE;
 }
 
-static int __init vsyscall_init(void)
+static int __init init_vdso(void)
 {
+   init_vdso_image(_image_64);
+
+#ifdef CONFIG_X86_X32_ABI
+   init_vdso_image(_image_x32);
+#endif
+
cpu_notifier_register_begin();
 
-   on_each_cpu(cpu_vsyscall_init, NULL, 1);
+   on_each_cpu(vgetcpu_cpu_init, NULL, 1);
/* notifier priority > KVM */
-   __hotcpu_notifier(cpu_vsyscall_notifier, 30);
+   __hotcpu_notifier(vgetcpu_cpu_notifier, 30);
 
cpu_notifier_register_done();
 
return 0;
 }
-__initcall(vsyscall_init);
-#endif
+subsys_initcall(init_vdso);
+#endif /* CONFIG_X86_64 */
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/8] x86,vdso: Replace vgetcpu_mode with static_cpu_has

[Andy Lutomirski]

The vdso has supported alternatives for a while; use them instead of
a vvar to select the vgetcpu mode.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/include/asm/vgtod.h| 21 +
 arch/x86/include/asm/vsyscall.h | 29 -
 arch/x86/include/asm/vvar.h |  1 -
 arch/x86/kernel/cpu/common.c| 10 --
 arch/x86/kernel/vsyscall_64.c   |  2 --
 arch/x86/vdso/vclock_gettime.c  |  3 +++
 arch/x86/vdso/vgetcpu.c |  4 +++-
 arch/x86/vdso/vma.c |  1 +
 8 files changed, 28 insertions(+), 43 deletions(-)

diff --git a/arch/x86/include/asm/vgtod.h b/arch/x86/include/asm/vgtod.h
index 3c3366c..44e0037 100644
--- a/arch/x86/include/asm/vgtod.h
+++ b/arch/x86/include/asm/vgtod.h
@@ -70,4 +70,25 @@ static inline void gtod_write_end(struct vsyscall_gtod_data 
*s)
++s->seq;
 }
 
+#ifdef CONFIG_X86_64
+
+#define VGETCPU_CPU_MASK 0xfff
+
+static inline unsigned int __getcpu(void)
+{
+   unsigned int p;
+
+   if (static_cpu_has(X86_FEATURE_RDTSCP)) {
+   /* Load per CPU data from RDTSCP */
+   native_read_tscp();
+   } else {
+   /* Load per CPU data from GDT */
+   asm("lsl %1,%0" : "=r" (p) : "r" (__PER_CPU_SEG));
+   }
+
+   return p;
+}
+
+#endif /* CONFIG_X86_64 */
+
 #endif /* _ASM_X86_VGTOD_H */
diff --git a/arch/x86/include/asm/vsyscall.h b/arch/x86/include/asm/vsyscall.h
index 2a46ca7..34f7d88 100644
--- a/arch/x86/include/asm/vsyscall.h
+++ b/arch/x86/include/asm/vsyscall.h
@@ -4,15 +4,6 @@
 #include 
 #include 
 
-#define VGETCPU_RDTSCP 1
-#define VGETCPU_LSL2
-
-/* kernel space (writeable) */
-extern int vgetcpu_mode;
-extern struct timezone sys_tz;
-
-#include 
-
 extern void map_vsyscall(void);
 
 /*
@@ -21,24 +12,4 @@ extern void map_vsyscall(void);
  */
 extern bool emulate_vsyscall(struct pt_regs *regs, unsigned long address);
 
-#ifdef CONFIG_X86_64
-
-#define VGETCPU_CPU_MASK 0xfff
-
-static inline unsigned int __getcpu(void)
-{
-   unsigned int p;
-
-   if (VVAR(vgetcpu_mode) == VGETCPU_RDTSCP) {
-   /* Load per CPU data from RDTSCP */
-   native_read_tscp();
-   } else {
-   /* Load per CPU data from GDT */
-   asm("lsl %1,%0" : "=r" (p) : "r" (__PER_CPU_SEG));
-   }
-
-   return p;
-}
-#endif /* CONFIG_X86_64 */
-
 #endif /* _ASM_X86_VSYSCALL_H */
diff --git a/arch/x86/include/asm/vvar.h b/arch/x86/include/asm/vvar.h
index 5f6d407..3f32dfc 100644
--- a/arch/x86/include/asm/vvar.h
+++ b/arch/x86/include/asm/vvar.h
@@ -44,7 +44,6 @@ extern char __vvar_page;
 
 /* DECLARE_VVAR(offset, type, name) */
 
-DECLARE_VVAR(16, int, vgetcpu_mode)
 DECLARE_VVAR(128, struct vsyscall_gtod_data, vsyscall_gtod_data)
 
 #undef DECLARE_VVAR
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 2cbbf88..cc41df0 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -947,14 +947,6 @@ static void identify_cpu(struct cpuinfo_x86 *c)
 }
 
 #ifdef CONFIG_X86_64
-static void vgetcpu_set_mode(void)
-{
-   if (cpu_has(_cpu_data, X86_FEATURE_RDTSCP))
-   vgetcpu_mode = VGETCPU_RDTSCP;
-   else
-   vgetcpu_mode = VGETCPU_LSL;
-}
-
 /* May not be __init: called during resume */
 static void syscall32_cpu_init(void)
 {
@@ -995,8 +987,6 @@ void __init identify_boot_cpu(void)
 #ifdef CONFIG_X86_32
sysenter_setup();
enable_sep_cpu();
-#else
-   vgetcpu_set_mode();
 #endif
cpu_detect_tlb(_cpu_data);
 }
diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
index 6463f9e..dd1b322 100644
--- a/arch/x86/kernel/vsyscall_64.c
+++ b/arch/x86/kernel/vsyscall_64.c
@@ -52,8 +52,6 @@
 #define CREATE_TRACE_POINTS
 #include "vsyscall_trace.h"
 
-DEFINE_VVAR(int, vgetcpu_mode);
-
 static enum { EMULATE, NATIVE, NONE } vsyscall_mode = EMULATE;
 
 static int __init vsyscall_setup(char *str)
diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
index b2e4f49..87df0af 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -14,6 +14,9 @@
 /* Disable profiling for userspace code: */
 #define DISABLE_BRANCH_PROFILING
 
+/* Disable static_cpu_has debugging; it doesn't work in the vDSO */
+#undef CONFIG_X86_DEBUG_STATIC_CPU_HAS
+
 #include 
 #include 
 #include 
diff --git a/arch/x86/vdso/vgetcpu.c b/arch/x86/vdso/vgetcpu.c
index add1d98..fd8470c 100644
--- a/arch/x86/vdso/vgetcpu.c
+++ b/arch/x86/vdso/vgetcpu.c
@@ -5,10 +5,12 @@
  * Fast user context implementation of getcpu()
  */
 
+/* Disable static_cpu_has debugging; it doesn't work in the vDSO */
+#undef CONFIG_X86_DEBUG_STATIC_CPU_HAS
+
 #include 
 #include 
 #include 
-#include 
 #include 
 
 notrace long
diff --git a/arch/x86/vdso/vma.c b/arch/x86/vdso/vma.c
index e1513c4..67a8b6c 100644
--- a/arch/x86/vdso/vma.c
+++ b/arch/x86/vdso/vma.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 

mips:allmodconfig build failure in 3.16-rc1 due to bpf_jit code

[Guenter Roeck]

mips:allmodconfig fails in 3.16-rc1 with lots of undefined symbols.

arch/mips/net/bpf_jit.c: In function 'is_load_to_a':
arch/mips/net/bpf_jit.c:559:7: error: 'BPF_S_LD_W_LEN' undeclared (first use in 
this function)
arch/mips/net/bpf_jit.c:559:7: note: each undeclared identifier is reported 
only once for each function it appears in
arch/mips/net/bpf_jit.c:560:7: error: 'BPF_S_LD_W_ABS' undeclared (first use in 
this function)
arch/mips/net/bpf_jit.c:561:7: error: 'BPF_S_LD_H_ABS' undeclared (first use in 
this function)
arch/mips/net/bpf_jit.c:562:7: error: 'BPF_S_LD_B_ABS' undeclared (first use in 
this function)
arch/mips/net/bpf_jit.c:563:7: error: 'BPF_S_ANC_CPU' undeclared (first use in 
this function)
arch/mips/net/bpf_jit.c:564:7: error: 'BPF_S_ANC_IFINDEX' undeclared (first use 
in this function)
arch/mips/net/bpf_jit.c:565:7: error: 'BPF_S_ANC_MARK' undeclared (first use in 
this function)

and so on.

Those symbols are not defined anywhere.

The problem is due to a conflict with commit 348059313 (net: filter: get rid of 
BPF_S_*
enum), which removed those definitions.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/8] x86_64: Move getcpu code from vsyscall_64.c to vdso/vma.c

[Andy Lutomirski]

This is pure cut-and-paste.  At this point, vsyscall_64.c contains
only code needed for vsyscall emulation, but some of the comments
and function names are still confused.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/kernel/vsyscall_64.c | 57 
 arch/x86/vdso/vma.c   | 61 +++
 2 files changed, 61 insertions(+), 57 deletions(-)

diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
index dd1b322..5029be3 100644
--- a/arch/x86/kernel/vsyscall_64.c
+++ b/arch/x86/kernel/vsyscall_64.c
@@ -332,49 +332,6 @@ int in_gate_area_no_mm(unsigned long addr)
return vsyscall_mode != NONE && (addr & PAGE_MASK) == VSYSCALL_ADDR;
 }
 
-/*
- * Assume __initcall executes before all user space. Hopefully kmod
- * doesn't violate that. We'll find out if it does.
- */
-static void vsyscall_set_cpu(int cpu)
-{
-   unsigned long d;
-   unsigned long node = 0;
-#ifdef CONFIG_NUMA
-   node = cpu_to_node(cpu);
-#endif
-   if (cpu_has(_data(cpu), X86_FEATURE_RDTSCP))
-   write_rdtscp_aux((node << 12) | cpu);
-
-   /*
-* Store cpu number in limit so that it can be loaded quickly
-* in user space in vgetcpu. (12 bits for the CPU and 8 bits for the 
node)
-*/
-   d = 0x0f400ULL;
-   d |= cpu;
-   d |= (node & 0xf) << 12;
-   d |= (node >> 4) << 48;
-
-   write_gdt_entry(get_cpu_gdt_table(cpu), GDT_ENTRY_PER_CPU, , 
DESCTYPE_S);
-}
-
-static void cpu_vsyscall_init(void *arg)
-{
-   /* preemption should be already off */
-   vsyscall_set_cpu(raw_smp_processor_id());
-}
-
-static int
-cpu_vsyscall_notifier(struct notifier_block *n, unsigned long action, void 
*arg)
-{
-   long cpu = (long)arg;
-
-   if (action == CPU_ONLINE || action == CPU_ONLINE_FROZEN)
-   smp_call_function_single(cpu, cpu_vsyscall_init, NULL, 1);
-
-   return NOTIFY_DONE;
-}
-
 void __init map_vsyscall(void)
 {
extern char __vsyscall_page;
@@ -389,17 +346,3 @@ void __init map_vsyscall(void)
BUILD_BUG_ON((unsigned long)__fix_to_virt(VSYSCALL_PAGE) !=
 (unsigned long)VSYSCALL_ADDR);
 }
-
-static int __init vsyscall_init(void)
-{
-   cpu_notifier_register_begin();
-
-   on_each_cpu(cpu_vsyscall_init, NULL, 1);
-   /* notifier priority > KVM */
-   __hotcpu_notifier(cpu_vsyscall_notifier, 30);
-
-   cpu_notifier_register_done();
-
-   return 0;
-}
-__initcall(vsyscall_init);
diff --git a/arch/x86/vdso/vma.c b/arch/x86/vdso/vma.c
index 67a8b6c..8973b4e 100644
--- a/arch/x86/vdso/vma.c
+++ b/arch/x86/vdso/vma.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -17,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #if defined(CONFIG_X86_64)
 unsigned int __read_mostly vdso64_enabled = 1;
@@ -233,3 +235,62 @@ static __init int vdso_setup(char *s)
 }
 __setup("vdso=", vdso_setup);
 #endif
+
+#ifdef CONFIG_X86_64
+/*
+ * Assume __initcall executes before all user space. Hopefully kmod
+ * doesn't violate that. We'll find out if it does.
+ */
+static void vsyscall_set_cpu(int cpu)
+{
+   unsigned long d;
+   unsigned long node = 0;
+#ifdef CONFIG_NUMA
+   node = cpu_to_node(cpu);
+#endif
+   if (cpu_has(_data(cpu), X86_FEATURE_RDTSCP))
+   write_rdtscp_aux((node << 12) | cpu);
+
+   /*
+* Store cpu number in limit so that it can be loaded quickly
+* in user space in vgetcpu. (12 bits for the CPU and 8 bits for the 
node)
+*/
+   d = 0x0f400ULL;
+   d |= cpu;
+   d |= (node & 0xf) << 12;
+   d |= (node >> 4) << 48;
+
+   write_gdt_entry(get_cpu_gdt_table(cpu), GDT_ENTRY_PER_CPU, , 
DESCTYPE_S);
+}
+
+static void cpu_vsyscall_init(void *arg)
+{
+   /* preemption should be already off */
+   vsyscall_set_cpu(raw_smp_processor_id());
+}
+
+static int
+cpu_vsyscall_notifier(struct notifier_block *n, unsigned long action, void 
*arg)
+{
+   long cpu = (long)arg;
+
+   if (action == CPU_ONLINE || action == CPU_ONLINE_FROZEN)
+   smp_call_function_single(cpu, cpu_vsyscall_init, NULL, 1);
+
+   return NOTIFY_DONE;
+}
+
+static int __init vsyscall_init(void)
+{
+   cpu_notifier_register_begin();
+
+   on_each_cpu(cpu_vsyscall_init, NULL, 1);
+   /* notifier priority > KVM */
+   __hotcpu_notifier(cpu_vsyscall_notifier, 30);
+
+   cpu_notifier_register_done();
+
+   return 0;
+}
+__initcall(vsyscall_init);
+#endif
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/8] x86: vdso and vsyscall round 1 for 3.17

[Andy Lutomirski]

This is mostly cleanups.  Patch 1 fixes a minor bug; it might make sense
to backport it.

Patch 3 removes the vsyscall mapping when vsyscall=none.

Patches 4 and 5 remove everything except gtod from the vvar page; the
other vvars weren't really necessary.

Patch 2, 6, 7, and 8 are pure cleanups.

This is based on tip/x86/vdso.

Andy Lutomirski (8):
  x86_64,vsyscall: Fix warn_bad_vsyscall log output
  x86_64,vsyscall: Move all of the gate_area code to vsyscall_64.c
  x86_64,vsyscall: Turn vsyscalls all the way off when vsyscall=none
  x86_64,vdso: Remove jiffies from the vvar page
  x86,vdso: Replace vgetcpu_mode with static_cpu_has
  x86_64: Move getcpu code from vsyscall_64.c to vdso/vma.c
  x86_64,vsyscall: Rewrite comment and clean up headers in vsyscall code
  x86_64,vdso: Clean up vgetcpu init and merge the vdso initcalls

 arch/x86/include/asm/vgtod.h|  21 ++
 arch/x86/include/asm/vsyscall.h |  29 
 arch/x86/include/asm/vvar.h |   2 -
 arch/x86/kernel/cpu/common.c|  10 ---
 arch/x86/kernel/time.c  |   2 +-
 arch/x86/kernel/vsyscall_64.c   | 155 +---
 arch/x86/mm/init_64.c   |  49 -
 arch/x86/vdso/vclock_gettime.c  |   3 +
 arch/x86/vdso/vgetcpu.c |   5 +-
 arch/x86/vdso/vma.c |  81 -
 10 files changed, 158 insertions(+), 199 deletions(-)

-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv2] x86: new Intel Atom SoC power management controller driver

[Li, Aubrey]

The Power Management Controller (PMC) controls many of the power
management features present in the SoC. This driver provides
interface to configure the Power Management Controller (PMC).

This driver exposes PMC device state and sleep state residency
via debugfs:
/sys/kernel/debugfs/pmc_atom/dev_state
/sys/kernel/debugfs/pmc_atom/sleep_state

This driver also provides a native power off function via PMC PCI
IO port.

v2:
- Allow pmc_atom and lpc_ich to work at the same time.

Signed-off-by: Aubrey Li 
Signed-off-by: Lejun Zhu 
Signed-off-by: Kasagar, Srinidhi 
Reviewed-by: Rudramuni, Vishwesh M 
Reviewed-by: Joe Perches 
---
 arch/x86/Kconfig|4 +
 arch/x86/include/asm/pmc_atom.h |  107 +
 arch/x86/kernel/Makefile|1 +
 arch/x86/kernel/pmc_atom.c  |  323 +++
 4 files changed, 435 insertions(+)
 create mode 100644 arch/x86/include/asm/pmc_atom.h
 create mode 100644 arch/x86/kernel/pmc_atom.c

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index fcefdda..fa9c4b7 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2404,6 +2404,10 @@ config IOSF_MBI
default m
depends on PCI
 
+config PMC_ATOM
+   def_bool y
+depends on PCI
+
 source "net/Kconfig"
 
 source "drivers/Kconfig"
diff --git a/arch/x86/include/asm/pmc_atom.h b/arch/x86/include/asm/pmc_atom.h
new file mode 100644
index 000..c5c5d62
--- /dev/null
+++ b/arch/x86/include/asm/pmc_atom.h
@@ -0,0 +1,107 @@
+/*
+ * Intel Atom SOC Power Management Controller Header File
+ * Copyright (c) 2014, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#ifndef PMC_ATOM_H
+#define PMC_ATOM_H
+
+/* ValleyView Power Control Unit PCI Device ID */
+#definePCI_DEVICE_ID_VLV_PMC   0x0F1C
+
+/* PMC Memory mapped IO registers */
+#definePMC_BASE_ADDR_OFFSET0x44
+#definePMC_BASE_ADDR_MASK  0xFE00
+#definePMC_MMIO_REG_LEN0x100
+#definePMC_REG_BIT_WIDTH   32
+
+/* BIOS uses FUNC_DIS to disable specific function */
+#definePMC_FUNC_DIS0x34
+#definePMC_FUNC_DIS_2  0x38
+
+/* S0ix wake event control */
+#define PMC_S0IX_WAKE_EN   0x3C
+
+#define BIT_LPC_CLOCK_RUN  BIT(4)
+#defineBIT_SHARED_IRQ_GPSC BIT(5)
+#defineBIT_ORED_DEDICATED_IRQ_GPSS BIT(18)
+#defineBIT_ORED_DEDICATED_IRQ_GPSC BIT(19)
+#defineBIT_SHARED_IRQ_GPSS BIT(20)
+
+#define PMC_WAKE_EN_SETTING~(BIT_LPC_CLOCK_RUN | \
+   BIT_SHARED_IRQ_GPSC | \
+   BIT_ORED_DEDICATED_IRQ_GPSS | \
+   BIT_ORED_DEDICATED_IRQ_GPSC | \
+   BIT_SHARED_IRQ_GPSS)
+
+/* The timers acumulate time spent in sleep state */
+#definePMC_S0IR_TMR0x80
+#definePMC_S0I1_TMR0x84
+#definePMC_S0I2_TMR0x88
+#definePMC_S0I3_TMR0x8C
+#definePMC_S0_TMR  0x90
+/* Sleep state counter is in units of of 32us */
+#definePMC_TMR_SHIFT   5
+
+/* These registers reflect D3 status of functions */
+#definePMC_D3_STS_00xA0
+
+#defineBIT_LPSS1_F0_DMABIT(0)
+#defineBIT_LPSS1_F1_PWM1   BIT(1)
+#defineBIT_LPSS1_F2_PWM2   BIT(2)
+#defineBIT_LPSS1_F3_HSUART1BIT(3)
+#defineBIT_LPSS1_F4_HSUART2BIT(4)
+#defineBIT_LPSS1_F5_SPIBIT(5)
+#defineBIT_LPSS1_F6_XXXBIT(6)
+#defineBIT_LPSS1_F7_XXXBIT(7)
+#defineBIT_SCC_EMMCBIT(8)
+#defineBIT_SCC_SDIOBIT(9)
+#defineBIT_SCC_SDCARD  BIT(10)
+#defineBIT_SCC_MIPIBIT(11)
+#defineBIT_HDA BIT(12)
+#defineBIT_LPE BIT(13)
+#defineBIT_OTG BIT(14)
+#defineBIT_USH BIT(15)
+#defineBIT_GBE BIT(16)
+#defineBIT_SATABIT(17)
+#defineBIT_USB_EHCIBIT(18)
+#defineBIT_SEC BIT(19)
+#defineBIT_PCIE_PORT0  BIT(20)
+#defineBIT_PCIE_PORT1  BIT(21)
+#defineBIT_PCIE_PORT2  BIT(22)
+#defineBIT_PCIE_PORT3  BIT(23)
+#defineBIT_LPSS2_F0_DMABIT(24)
+#defineBIT_LPSS2_F1_I2C1   BIT(25)
+#defineBIT_LPSS2_F2_I2C2   

Re: [PATCH v5 7/8] staging: lustre: lclient: lcommon_cl.c fixing coding style issues

[Drokin, Oleg]

On Jun 16, 2014, at 12:22 PM, Anil Belur wrote:

> From: Anil Belur 
> 
> fixed: WARNING: line over 80 characters, used a new variable 'size_index' to
> store the offset. Replace "unsigned long" with  "u64" type for

Apparently you forgot to update the comment.

> 'cur_index'
> 
> Signed-off-by: Anil Belur 
> ---
> drivers/staging/lustre/lustre/lclient/lcommon_cl.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/lclient/lcommon_cl.c 
> b/drivers/staging/lustre/lustre/lclient/lcommon_cl.c
> index c180a20..6c5b828 100644
> --- a/drivers/staging/lustre/lustre/lclient/lcommon_cl.c
> +++ b/drivers/staging/lustre/lustre/lclient/lcommon_cl.c
> @@ -864,10 +864,11 @@ int ccc_prep_size(const struct lu_env *env, struct 
> cl_object *obj,
>* linux-2.6.18-128.1.1 miss to do that.
>* --bug 17336 */
>   loff_t size = cl_isize_read(inode);
> - unsigned long cur_index = start >> 
> PAGE_CACHE_SHIFT;
> + loff_t cur_index = start >> PAGE_CACHE_SHIFT;
> + loff_t size_index = ((size - 1) >> 
> PAGE_CACHE_SHIFT);
> 
>   if ((size == 0 && cur_index != 0) ||
> - (((size - 1) >> PAGE_CACHE_SHIFT) < 
> cur_index))
> + (size_index < cur_index))
>   *exceed = 1;
>   }
>   return result;
> -- 
> 1.9.0
> 

Bye,
Oleg--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Disable bus's drivers_autoprobe before rootfs has mounted

[Peter Chen]

 
> > Yes, otherwise, the device which the udc is probed deferral and the
> > gadget driver is build-in will never work. If we skip fixing it, this
> > problem will exist for more than 2 years, it is too long.
> >
> > I have a support request from android team that usb peripheral
> > function never works from 3.10.x kernel at one device, I think it is a
> > common problem, no only I meet it.
> >
> > Below are links which this problem reports:
> >
> > http://marc.info/?l=linux-usb=139380872501745=2
> > http://marc.info/?l=linux-usb=137706435611447=2
> >
> > > If you do want to fix the problem, there's a much easier way than
> > > what you posted.  See below.
> > >
> > Robert Baldyga posts the similar solution, but seems Felipe doesn't
> > agree it.
> > http://www.spinics.net/lists/linux-usb/msg102795.html
> >
> > Then, you and Felipe has a discussion for this problem:
> > http://www.spinics.net/lists/linux-usb/msg106760.html
> 
> Okay, I get it.  Felipe didn't want to do this because you might end up
> loading a gadget driver that never gets bound.  There might not even be
> any UDC devices at all.
> 
> Felipe, I think the problem of having unbound gadget drivers isn't so bad.
> It's just like having unbound drivers of any sort.  For example, the
> Fedora kernels have ohci-hcd and uhci-hcd built-in.  Relatively few
> systems have both OHCI and UHCI controllers (lots of current machines
> have neither); everybody else ends up with at least one unused driver and
> no way to remove it.  If Fedora can do this, I think we can allow users
> to have unnecessary gadget drivers.
> 
> In fact, I don't know of any other kind of driver module whose init
> routine will fail if there's no hardware to bind to.
> 
> I suggest you go ahead and accept Robert Baldyga's original patch --
> except for one little problem: The patch forgets to add driver->list to
> the global driver_list if the driver gets bound immediately.  The
> 
>   list_add_tail(>list, _list);
> 
> call needs to be moved up near the start of usb_gadget_probe_driver().
> 

Thanks, Alan.

The another improvement is: set driver->attached as true at udc_bind_to_driver.

Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] powerpc: Fix build warning

[Guenter Roeck]

On 06/16/2014 06:25 PM, David Rientjes wrote:

On Fri, 13 Jun 2014, Guenter Roeck wrote:


If compiled with W=1, the following warning is seen in powerpc builds.

arch/powerpc/kernel/smp.c:750:18: warning:
type qualifiers ignored on function return type
static const int powerpc_smt_flags(void)
  ^

This is caused by a function returning 'const int', which doesn't
make sense to gcc. Drop 'const' to fix the problem.

Reported-by: Vincent Guittot 
Signed-off-by: Guenter Roeck 


Acked-by: David Rientjes 

Although it's strange you report this happening on line 750 in the
changelog but the patch shows it differently.



In the latest kernel (v3.16-rc1) the function is at line 750.
It appears that I ran the build test on a later version than
the one I used to write the patch. Hope that is not a problem.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] checkpatch: Warn on unnecessary void function return statements

[Joe Perches]

On Mon, 2014-06-16 at 17:44 -0700, Anish Bhatt wrote:
> My code has multiple exit lables:
> void function(void)
> {
>   ...
> 
>   if (err1)
>   goto exit1;
>   ...
>   if (err2)
>   goto exit2;
> 
>   ...
>   return; /* Good return, no errors */
> exit1:
>   printk(err1);
>   return;
> exit2:
>   printk(err2);
> }
> 
> The single tabbed return was required to prevent the good return & err1 
> messages cascading down. The extra exit label with a noop looks weird, 
> but is passing checkpatch.pl --strict, so I will go with that, thanks.
> -Anish
> 

Hmm, those return uses seem reasonable
to me.

Perhaps the test should warn only on
this specific 3 line sequence:

[any line but a label]
return;
}

Andrew?  Anyone else?  Opinions?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv3 3/5] common: dma-mapping: Introduce common remapping functions

[Laura Abbott]

For architectures without coherent DMA, memory for DMA may
need to be remapped with coherent attributes. Factor out
the the remapping code from arm and put it in a
common location to reduced code duplication.

Signed-off-by: Laura Abbott 
---
 arch/arm/mm/dma-mapping.c| 57 +--
 drivers/base/dma-mapping.c   | 67 
 include/asm-generic/dma-mapping-common.h |  9 +
 3 files changed, 85 insertions(+), 48 deletions(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 4c88935..f5190ac 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -297,37 +297,19 @@ static void *
 __dma_alloc_remap(struct page *page, size_t size, gfp_t gfp, pgprot_t prot,
const void *caller)
 {
-   struct vm_struct *area;
-   unsigned long addr;
-
/*
 * DMA allocation can be mapped to user space, so lets
 * set VM_USERMAP flags too.
 */
-   area = get_vm_area_caller(size, VM_ARM_DMA_CONSISTENT | VM_USERMAP,
- caller);
-   if (!area)
-   return NULL;
-   addr = (unsigned long)area->addr;
-   area->phys_addr = __pfn_to_phys(page_to_pfn(page));
-
-   if (ioremap_page_range(addr, addr + size, area->phys_addr, prot)) {
-   vunmap((void *)addr);
-   return NULL;
-   }
-   return (void *)addr;
+   return dma_common_contiguous_remap(page, size,
+   VM_ARM_DMA_CONSISTENT | VM_USERMAP,
+   prot, caller);
 }
 
 static void __dma_free_remap(void *cpu_addr, size_t size)
 {
-   unsigned int flags = VM_ARM_DMA_CONSISTENT | VM_USERMAP;
-   struct vm_struct *area = find_vm_area(cpu_addr);
-   if (!area || (area->flags & flags) != flags) {
-   WARN(1, "trying to free invalid coherent area: %p\n", cpu_addr);
-   return;
-   }
-   unmap_kernel_range((unsigned long)cpu_addr, size);
-   vunmap(cpu_addr);
+   dma_common_free_remap(cpu_addr, size,
+   VM_ARM_DMA_CONSISTENT | VM_USERMAP);
 }
 
 #define DEFAULT_DMA_COHERENT_POOL_SIZE SZ_256K
@@ -1261,29 +1243,8 @@ static void *
 __iommu_alloc_remap(struct page **pages, size_t size, gfp_t gfp, pgprot_t prot,
const void *caller)
 {
-   unsigned int i, nr_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
-   struct vm_struct *area;
-   unsigned long p;
-
-   area = get_vm_area_caller(size, VM_ARM_DMA_CONSISTENT | VM_USERMAP,
- caller);
-   if (!area)
-   return NULL;
-
-   area->pages = pages;
-   area->nr_pages = nr_pages;
-   p = (unsigned long)area->addr;
-
-   for (i = 0; i < nr_pages; i++) {
-   phys_addr_t phys = __pfn_to_phys(page_to_pfn(pages[i]));
-   if (ioremap_page_range(p, p + PAGE_SIZE, phys, prot))
-   goto err;
-   p += PAGE_SIZE;
-   }
-   return area->addr;
-err:
-   unmap_kernel_range((unsigned long)area->addr, size);
-   vunmap(area->addr);
+   return dma_common_pages_remap(pages, size,
+   VM_ARM_DMA_CONSISTENT | VM_USERMAP, prot, caller);
return NULL;
 }
 
@@ -1491,8 +1452,8 @@ void arm_iommu_free_attrs(struct device *dev, size_t 
size, void *cpu_addr,
}
 
if (!dma_get_attr(DMA_ATTR_NO_KERNEL_MAPPING, attrs)) {
-   unmap_kernel_range((unsigned long)cpu_addr, size);
-   vunmap(cpu_addr);
+   dma_common_free_remap(cpu_addr, size,
+   VM_ARM_DMA_CONSISTENT | VM_USERMAP);
}
 
__iommu_remove_mapping(dev, handle, size);
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 6cd08e1..34265b5 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -10,6 +10,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 /*
@@ -267,3 +269,68 @@ int dma_common_mmap(struct device *dev, struct 
vm_area_struct *vma,
return ret;
 }
 EXPORT_SYMBOL(dma_common_mmap);
+
+/*
+ * remaps an allocated contiguous region into another vm_area.
+ * Cannot be used in non-sleeping contexts
+ */
+
+void *dma_common_contiguous_remap(struct page *page, size_t size,
+   unsigned long vm_flags,
+   pgprot_t prot, const void *caller)
+{
+   int i;
+   struct page **pages;
+   void *ptr;
+
+   pages = kmalloc(sizeof(struct page *) << get_order(size), GFP_KERNEL);
+   if (!pages)
+   return NULL;
+
+   for (i = 0; i < (size >> PAGE_SHIFT); i++)
+   pages[i] = page + i;
+
+   ptr = dma_common_pages_remap(pages, size, vm_flags, prot, caller);
+
+   kfree(pages);
+
+   return ptr;
+}
+
+/*
+ * remaps an array of PAGE_SIZE pages into another vm_area
+ * Cannot be used in non-sleeping contexts
+ */
+void 

[PATCHv3 4/5] arm: use genalloc for the atomic pool

[Laura Abbott]

ARM currently uses a bitmap for tracking atomic allocations.
genalloc already handles this type of memory pool allocation
so switch to using that instead.

Signed-off-by: Laura Abbott 
---
 arch/arm/Kconfig  |   1 +
 arch/arm/mm/dma-mapping.c | 144 ++
 2 files changed, 45 insertions(+), 100 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 87b63fd..71899da 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -13,6 +13,7 @@ config ARM
select CLONE_BACKWARDS
select CPU_PM if (SUSPEND || CPU_IDLE)
select DCACHE_WORD_ACCESS if HAVE_EFFICIENT_UNALIGNED_ACCESS
+   select GENERIC_ALLOCATOR
select GENERIC_ATOMIC64 if (CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI)
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
select GENERIC_IDLE_POLL_SETUP
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index f5190ac..30edbd4 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -313,40 +314,31 @@ static void __dma_free_remap(void *cpu_addr, size_t size)
 }
 
 #define DEFAULT_DMA_COHERENT_POOL_SIZE SZ_256K
+static struct gen_pool *atomic_pool;
 
-struct dma_pool {
-   size_t size;
-   spinlock_t lock;
-   unsigned long *bitmap;
-   unsigned long nr_pages;
-   void *vaddr;
-   struct page **pages;
-};
-
-static struct dma_pool atomic_pool = {
-   .size = DEFAULT_DMA_COHERENT_POOL_SIZE,
-};
+static size_t atomic_pool_size = DEFAULT_DMA_COHERENT_POOL_SIZE;
 
 static int __init early_coherent_pool(char *p)
 {
-   atomic_pool.size = memparse(p, );
+   atomic_pool_size = memparse(p, );
return 0;
 }
 early_param("coherent_pool", early_coherent_pool);
 
+
 void __init init_dma_coherent_pool_size(unsigned long size)
 {
/*
 * Catch any attempt to set the pool size too late.
 */
-   BUG_ON(atomic_pool.vaddr);
+   BUG_ON(atomic_pool);
 
/*
 * Set architecture specific coherent pool size only if
 * it has not been changed by kernel command line parameter.
 */
-   if (atomic_pool.size == DEFAULT_DMA_COHERENT_POOL_SIZE)
-   atomic_pool.size = size;
+   if (atomic_pool_size == DEFAULT_DMA_COHERENT_POOL_SIZE)
+   atomic_pool_size = size;
 }
 
 /*
@@ -354,52 +346,44 @@ void __init init_dma_coherent_pool_size(unsigned long 
size)
  */
 static int __init atomic_pool_init(void)
 {
-   struct dma_pool *pool = _pool;
pgprot_t prot = pgprot_dmacoherent(PAGE_KERNEL);
gfp_t gfp = GFP_KERNEL | GFP_DMA;
-   unsigned long nr_pages = pool->size >> PAGE_SHIFT;
-   unsigned long *bitmap;
struct page *page;
-   struct page **pages;
void *ptr;
-   int bitmap_size = BITS_TO_LONGS(nr_pages) * sizeof(long);
 
-   bitmap = kzalloc(bitmap_size, GFP_KERNEL);
-   if (!bitmap)
-   goto no_bitmap;
-
-   pages = kzalloc(nr_pages * sizeof(struct page *), GFP_KERNEL);
-   if (!pages)
-   goto no_pages;
+   atomic_pool = gen_pool_create(PAGE_SHIFT, -1);
+   if (!atomic_pool)
+   goto out;
 
if (dev_get_cma_area(NULL))
-   ptr = __alloc_from_contiguous(NULL, pool->size, prot, ,
- atomic_pool_init);
+   ptr = __alloc_from_contiguous(NULL, atomic_pool_size, prot,
+ , atomic_pool_init);
else
-   ptr = __alloc_remap_buffer(NULL, pool->size, gfp, prot, ,
-  atomic_pool_init);
+   ptr = __alloc_remap_buffer(NULL, atomic_pool_size, gfp, prot,
+  , atomic_pool_init);
if (ptr) {
-   int i;
-
-   for (i = 0; i < nr_pages; i++)
-   pages[i] = page + i;
-
-   spin_lock_init(>lock);
-   pool->vaddr = ptr;
-   pool->pages = pages;
-   pool->bitmap = bitmap;
-   pool->nr_pages = nr_pages;
-   pr_info("DMA: preallocated %u KiB pool for atomic coherent 
allocations\n",
-  (unsigned)pool->size / 1024);
+   int ret;
+
+   ret = gen_pool_add_virt(atomic_pool, (unsigned long)ptr,
+   page_to_phys(page),
+   atomic_pool_size, -1);
+   if (ret)
+   goto destroy_genpool;
+
+   gen_pool_set_algo(atomic_pool,
+   gen_pool_first_fit_order_align,
+   (void *)PAGE_SHIFT);
+   pr_info("DMA: preallocated %zd KiB pool for atomic coherent 
allocations\n",
+  atomic_pool_size / 1024);
return 0;
}
 
-   

[PATCHv3 1/5] lib/genalloc.c: Add power aligned algorithm

[Laura Abbott]

One of the more common algorithms used for allocation
is to align the start address of the allocation to
the order of size requested. Add this as an algorithm
option for genalloc.

Signed-off-by: Laura Abbott 
---
 include/linux/genalloc.h |  4 
 lib/genalloc.c   | 21 +
 2 files changed, 25 insertions(+)

diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index 1c2fdaa..3cd0934 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -110,6 +110,10 @@ extern void gen_pool_set_algo(struct gen_pool *pool, 
genpool_algo_t algo,
 extern unsigned long gen_pool_first_fit(unsigned long *map, unsigned long size,
unsigned long start, unsigned int nr, void *data);
 
+extern unsigned long gen_pool_first_fit_order_align(unsigned long *map,
+   unsigned long size, unsigned long start, unsigned int nr,
+   void *data);
+
 extern unsigned long gen_pool_best_fit(unsigned long *map, unsigned long size,
unsigned long start, unsigned int nr, void *data);
 
diff --git a/lib/genalloc.c b/lib/genalloc.c
index bdb9a45..9758529 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -481,6 +481,27 @@ unsigned long gen_pool_first_fit(unsigned long *map, 
unsigned long size,
 EXPORT_SYMBOL(gen_pool_first_fit);
 
 /**
+ * gen_pool_first_fit_order_align - find the first available region
+ * of memory matching the size requirement. The region will be aligned
+ * to the order of the size specified.
+ * @map: The address to base the search on
+ * @size: The bitmap size in bits
+ * @start: The bitnumber to start searching at
+ * @nr: The number of zeroed bits we're looking for
+ * @data: additional data - unused
+ */
+unsigned long gen_pool_first_fit_order_align(unsigned long *map,
+   unsigned long size, unsigned long start,
+   unsigned int nr, void *data)
+{
+   unsigned long order = (unsigned long) data;
+   unsigned long align_mask = (1 << get_order(nr << order)) - 1;
+
+   return bitmap_find_next_zero_area(map, size, start, nr, align_mask);
+}
+EXPORT_SYMBOL(gen_pool_first_fit_order_align);
+
+/**
  * gen_pool_best_fit - find the best fitting region of memory
  * macthing the size requirement (no alignment constraint)
  * @map: The address to base the search on
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv3 0/5] Atomic pool for arm64

[Laura Abbott]

Hi,

This is a series to add a pool for atomic allocations for arm64. It was
previously suggested to try and share more code with arm. I did some
refactoring to have arm use genalloc and pull out some of the remapping
code. The end result is a negative diffstat overall for arm dma-mapping.c.

There still might be some room for more refactoring of atomic functions into
common dma-mapping.c and integration with dma-coherent.c but there should
be less overlap now.

Reviews and testing welcome.

Thanks,
Laura

v3: Now a patch series due to refactoring of arm code. arm and arm64 now both
use genalloc for atomic pool management. genalloc extensions added.
DMA remapping code factored out as well.

v2: Various bug fixes pointed out by David and Ritesh (CMA dependency, swapping
coherent, noncoherent). I'm still not sure how to address the devicetree
suggestion by Will [1][2]. I added the devicetree mailing list this time around
to get more input on this.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/249180.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/249528.html


Laura Abbott (5):
  lib/genalloc.c: Add power aligned algorithm
  lib/genalloc.c: Add genpool range check function
  common: dma-mapping: Introduce common remapping functions
  arm: use genalloc for the atomic pool
  arm64: Add atomic pool for non-coherent and CMA allocaitons.

 arch/arm/Kconfig |   1 +
 arch/arm/mm/dma-mapping.c| 200 ---
 arch/arm64/Kconfig   |   1 +
 arch/arm64/mm/dma-mapping.c  | 154 +---
 drivers/base/dma-mapping.c   |  66 ++
 include/asm-generic/dma-mapping-common.h |   9 ++
 include/linux/genalloc.h |   7 ++
 lib/genalloc.c   |  50 
 8 files changed, 323 insertions(+), 165 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv3 2/5] lib/genalloc.c: Add genpool range check function

[Laura Abbott]

After allocating an address from a particular genpool,
there is no good way to verify if that address actually
belongs to a genpool. Introduce addr_in_gen_pool which
will return if an address plus size falls completely
within the genpool range.

Signed-off-by: Laura Abbott 
---
 include/linux/genalloc.h |  3 +++
 lib/genalloc.c   | 29 +
 2 files changed, 32 insertions(+)

diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index 3cd0934..1ccaab4 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -121,6 +121,9 @@ extern struct gen_pool *devm_gen_pool_create(struct device 
*dev,
int min_alloc_order, int nid);
 extern struct gen_pool *dev_get_gen_pool(struct device *dev);
 
+bool addr_in_gen_pool(struct gen_pool *pool, unsigned long start,
+   size_t size);
+
 #ifdef CONFIG_OF
 extern struct gen_pool *of_get_named_gen_pool(struct device_node *np,
const char *propname, int index);
diff --git a/lib/genalloc.c b/lib/genalloc.c
index 9758529..66edf93 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -403,6 +403,35 @@ void gen_pool_for_each_chunk(struct gen_pool *pool,
 EXPORT_SYMBOL(gen_pool_for_each_chunk);
 
 /**
+ * addr_in_gen_pool - checks if an address falls within the range of a pool
+ * @pool:  the generic memory pool
+ * @start: start address
+ * @size:  size of the region
+ *
+ * Check if the range of addresses falls within the specified pool. Takes
+ * the rcu_read_lock for the duration of the check.
+ */
+bool addr_in_gen_pool(struct gen_pool *pool, unsigned long start,
+   size_t size)
+{
+   bool found = false;
+   unsigned long end = start + size;
+   struct gen_pool_chunk *chunk;
+
+   rcu_read_lock();
+   list_for_each_entry_rcu(chunk, &(pool)->chunks, next_chunk) {
+   if (start >= chunk->start_addr && start <= chunk->end_addr) {
+   if (end <= chunk->end_addr) {
+   found = true;
+   break;
+   }
+   }
+   }
+   rcu_read_unlock();
+   return found;
+}
+
+/**
  * gen_pool_avail - get available free space of the pool
  * @pool: pool to get available free space
  *
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv3 5/5] arm64: Add atomic pool for non-coherent and CMA allocations.

[Laura Abbott]

Neither CMA nor noncoherent allocations support atomic allocations.
Add a dedicated atomic pool to support this.

Signed-off-by: Laura Abbott 
---
 arch/arm64/Kconfig  |   1 +
 arch/arm64/mm/dma-mapping.c | 155 +++-
 2 files changed, 139 insertions(+), 17 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7295419..9de71a26 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -14,6 +14,7 @@ config ARM64
select COMMON_CLK
select CPU_PM if (SUSPEND || CPU_IDLE)
select DCACHE_WORD_ACCESS
+   select GENERIC_ALLOCATOR
select GENERIC_CLOCKEVENTS
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
select GENERIC_CPU_AUTOPROBE
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 4164c5a..8e8049b 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -41,6 +42,55 @@ static pgprot_t __get_dma_pgprot(struct dma_attrs *attrs, 
pgprot_t prot,
return prot;
 }
 
+static struct gen_pool *atomic_pool;
+
+#define DEFAULT_DMA_COHERENT_POOL_SIZE  SZ_256K
+static size_t atomic_pool_size = DEFAULT_DMA_COHERENT_POOL_SIZE;
+
+static int __init early_coherent_pool(char *p)
+{
+   atomic_pool_size = memparse(p, );
+   return 0;
+}
+early_param("coherent_pool", early_coherent_pool);
+
+static void *__alloc_from_pool(size_t size, struct page **ret_page)
+{
+   unsigned long val;
+   void *ptr = NULL;
+
+   if (!atomic_pool) {
+   WARN(1, "coherent pool not initialised!\n");
+   return NULL;
+   }
+
+   val = gen_pool_alloc(atomic_pool, size);
+   if (val) {
+   phys_addr_t phys = gen_pool_virt_to_phys(atomic_pool, val);
+
+   *ret_page = phys_to_page(phys);
+   ptr = (void *)val;
+   }
+
+   return ptr;
+}
+
+static bool __in_atomic_pool(void *start, size_t size)
+{
+   return addr_in_gen_pool(atomic_pool, (unsigned long)start, size);
+}
+
+static int __free_from_pool(void *start, size_t size)
+{
+   if (!__in_atomic_pool(start, size))
+   return 0;
+
+   gen_pool_free(atomic_pool, (unsigned long)start, size);
+
+   return 1;
+}
+
+
 static void *__dma_alloc_coherent(struct device *dev, size_t size,
  dma_addr_t *dma_handle, gfp_t flags,
  struct dma_attrs *attrs)
@@ -53,7 +103,8 @@ static void *__dma_alloc_coherent(struct device *dev, size_t 
size,
if (IS_ENABLED(CONFIG_ZONE_DMA) &&
dev->coherent_dma_mask <= DMA_BIT_MASK(32))
flags |= GFP_DMA;
-   if (IS_ENABLED(CONFIG_DMA_CMA)) {
+
+   if (!(flags & __GFP_WAIT) && IS_ENABLED(CONFIG_DMA_CMA)) {
struct page *page;
 
size = PAGE_ALIGN(size);
@@ -73,50 +124,56 @@ static void __dma_free_coherent(struct device *dev, size_t 
size,
void *vaddr, dma_addr_t dma_handle,
struct dma_attrs *attrs)
 {
+   bool freed;
+   phys_addr_t paddr = dma_to_phys(dev, dma_handle);
+
if (dev == NULL) {
WARN_ONCE(1, "Use an actual device structure for DMA 
allocation\n");
return;
}
 
-   if (IS_ENABLED(CONFIG_DMA_CMA)) {
-   phys_addr_t paddr = dma_to_phys(dev, dma_handle);
 
-   dma_release_from_contiguous(dev,
+   freed = dma_release_from_contiguous(dev,
phys_to_page(paddr),
size >> PAGE_SHIFT);
-   } else {
+   if (!freed)
swiotlb_free_coherent(dev, size, vaddr, dma_handle);
-   }
 }
 
 static void *__dma_alloc_noncoherent(struct device *dev, size_t size,
 dma_addr_t *dma_handle, gfp_t flags,
 struct dma_attrs *attrs)
 {
-   struct page *page, **map;
+   struct page *page;
void *ptr, *coherent_ptr;
-   int order, i;
 
size = PAGE_ALIGN(size);
-   order = get_order(size);
+
+   if (!(flags & __GFP_WAIT)) {
+   struct page *page = NULL;
+   void *addr = __alloc_from_pool(size, );
+
+   if (addr)
+   *dma_handle = phys_to_dma(dev, page_to_phys(page));
+
+   return addr;
+
+   }
 
ptr = __dma_alloc_coherent(dev, size, dma_handle, flags, attrs);
if (!ptr)
goto no_mem;
-   map = kmalloc(sizeof(struct page *) << order, flags & ~GFP_DMA);
-   if (!map)
-   goto no_map;
 
/* remove any dirty cache lines on the kernel alias */
__dma_flush_range(ptr, ptr + size);
 
+
/* create a coherent mapping */
page = virt_to_page(ptr);
-   for (i = 0; i < (size >> PAGE_SHIFT); i++)
-