Re: [PATCH] staging: unisys: Convert direct LOGERR uses to pr_err

[Greg Kroah-Hartman]

On Sat, Jan 10, 2015 at 09:32:33PM -0800, Joe Perches wrote:
> On Sat, 2015-01-10 at 21:24 -0800, Greg Kroah-Hartman wrote:
> > On Sat, Jan 10, 2015 at 08:55:21PM -0800, Joe Perches wrote:
> > > On Sat, 2015-01-10 at 20:13 -0800, Greg Kroah-Hartman wrote:
> > > > On Sat, Jan 10, 2015 at 07:09:02PM -0800, Joe Perches wrote:
> > > > > Use the normal logging facility instead of a new macro.
> > > > > 
> > > > > Miscellanea:
> > > > > 
> > > > > o Realign arguments
> > > > > o Remove unnecessary alloc error messages as alloc failures
> > > > >   already emits a generic OOM message with a dump_stack
> > > > > o Add missing newlines to these messages to avoid interleaving
> > > > > o Spelling/typo fixes in those messages
> > > []
> > > > I rejected the other patch that did much this same thing, almost all of
> > > > these should be converted to use dev_* calls instead of pr_* calls, as
> > > > this is a driver, and drivers should always have access to a struct
> > > > device.  If not, they need to be fixed.
> > > 
> > > Baby steps.
> > > 
> > > This one prevents interleaving
> > > and fixes typos.
> > 
> > Yes, but converting it to dev_* at the same time saves a step, and gets
> > it done properly.  Leaving messages at pr_* levels takes away the
> > checkpatch warning, which makes the code "seem" to be acceptable.
> 
> I think you've not looked at the code very much.
> 
> Many of these things can not be converted to dev_
> as there is not a single device there.

Then that needs to be fixed.

> Many of these are error messages referring to busses that
> support many devices.

The device that caused the error should emit the message, or the host
controller for that bus.  "general" messages shouldn't ever be happening
as they are useless.  If they are, something is wrong with the code.

> Converting them to dev_ piecemeal or wholesale
> isn't possible.

I beg to differ, no driver should be using pr_* except in init/exit
functions when there is no hardware yet found.  Everywhere else a struct
device is there to be used.  If the code isn't passing it around, that
is usually an indication that something is really wrong and should be
fixed.

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 5/6] HMM: add per mirror page table.

[Haggai Eran]

On 10/01/2015 08:48, Jerome Glisse wrote:
> On Thu, Jan 08, 2015 at 01:05:41PM +0200, Haggai Eran wrote:
>> On 06/01/2015 00:44, j.gli...@gmail.com wrote:
>>> +   /* fence_wait() - to wait on device driver fence.
>>> +*
>>> +* @fence: The device driver fence struct.
>>> +* Returns: 0 on success,-EIO on error, -EAGAIN to wait again.
>>> +*
>>> +* Called when hmm want to wait for all operations associated with a
>>> +* fence to complete (including device cache flush if the event mandate
>>> +* it).
>>> +*
>>> +* Device driver must free fence and associated resources if it returns
>>> +* something else thant -EAGAIN. On -EAGAIN the fence must not be free
>>> +* as hmm will call back again.
>>> +*
>>> +* Return error if scheduled operation failed or if need to wait again.
>>> +* -EIO Some input/output error with the device.
>>> +* -EAGAIN The fence not yet signaled, hmm reschedule waiting thread.
>>> +*
>>> +* All other return value trigger warning and are transformed to -EIO.
>>> +*/
>>> +   int (*fence_wait)(struct hmm_fence *fence);
>>
>> According to the comment, the device frees the fence struct when the
>> fence_wait callback returns zero or -EIO, but the code below calls
>> fence_unref after fence_wait on the same fence.
> 
> Yes comment is out of date, i wanted to simplify fence before readding
> it once needed (by device memory migration).
> 
>>
>>> +
>>> +   /* fence_ref() - take a reference fence structure.
>>> +*
>>> +* @fence: Fence structure hmm is referencing.
>>> +*/
>>> +   void (*fence_ref)(struct hmm_fence *fence);
>>
>> I don't see fence_ref being called anywhere in the patchset. Is it
>> actually needed?
> 
> Not right now but the page migration to device memory use it. But i
> can remove it now.
> 
> I can respin to make comment match code but i would like to know where
> i stand on everythings else.
> 

Well, I've read patches 1 through 4, and they seemed fine, although I
still want to have a deeper look into patch 4, because the page table
code seems a little tricky. I haven't completed reading patch 5 and 6 yet.

Haggai
--
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: fix wrong memory footprint statistics in debugfs

[Jaegeuk Kim]

On Sat, Jan 10, 2015 at 08:09:52PM +0800, Chao Yu wrote:
> Hi Jaegeuk,
> 
> > -Original Message-
> > From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> > Sent: Wednesday, January 07, 2015 3:49 AM
> > To: Chao Yu
> > Cc: Changman Lee; linux-f2fs-de...@lists.sourceforge.net; 
> > linux-kernel@vger.kernel.org
> > Subject: Re: [f2fs-dev][PATCH] f2fs: fix wrong memory footprint statistics 
> > in debugfs
> > 
> > Hi Chao,
> > 
> > On Tue, Jan 06, 2015 at 04:40:49PM +0800, Chao Yu wrote:
> > > Our value of memory footprint statistics showed in debugfs is not 
> > > calculated
> > > correctly. Fix it in this patch.
> > >
> > > Signed-off-by: Chao Yu 
> > > ---
> > >  fs/f2fs/debug.c | 15 ++-
> > >  1 file changed, 10 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
> > > index dd7835b..6aeaf46 100644
> > > --- a/fs/f2fs/debug.c
> > > +++ b/fs/f2fs/debug.c
> > > @@ -125,7 +125,7 @@ static void update_mem_info(struct f2fs_sb_info *sbi)
> > >   int i;
> > >
> > >   if (si->base_mem)
> > > - goto get_cache;
> > > + goto get_dynamic_cache;
> > >
> > >   si->base_mem = sizeof(struct f2fs_sb_info) + sbi->sb->s_blocksize;
> > >   si->base_mem += 2 * sizeof(struct f2fs_inode_info);
> > > @@ -161,13 +161,18 @@ static void update_mem_info(struct f2fs_sb_info 
> > > *sbi)
> > >   si->base_mem += sizeof(struct f2fs_nm_info);
> > >   si->base_mem += __bitmap_size(sbi, NAT_BITMAP);
> > >
> > > +get_dynamic_cache:
> > >   /* build gc */
> > > - si->base_mem += sizeof(struct f2fs_gc_kthread);
> > > + if (sbi->gc_thread)
> > > + si->base_mem += sizeof(struct f2fs_gc_kthread);
> > > +
> > > + /* build merge flush thread */
> > > + if (SM_I(sbi)->cmd_control_info)
> > > + si->base_mem += sizeof(struct flush_cmd_control);
> > 
> > It seems base_mem increases repeatedly?
> 
> Right, my mistaken. How about counting memory of these two cache into 
> cache_mem
> as following?

Looks good to me. :)
Thanks,

> 
> >From edfa0beaed83ebfec34b07bfcb5e8ce3cdcb0858 Mon Sep 17 00:00:00 2001
> From: Chao Yu 
> Date: Sat, 10 Jan 2015 19:24:24 +0800
> Subject: [PATCH] f2fs: fix wrong memory footprint statistics in debugfs
> 
> Our value of memory footprint statistics showed in debugfs is not calculated
> correctly. Fix it in this patch.
> 
> Signed-off-by: Chao Yu 
> ---
>  fs/f2fs/debug.c | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/fs/f2fs/debug.c b/fs/f2fs/debug.c
> index 1f0fb58..b45daab 100644
> --- a/fs/f2fs/debug.c
> +++ b/fs/f2fs/debug.c
> @@ -163,13 +163,20 @@ static void update_mem_info(struct f2fs_sb_info *sbi)
>   si->base_mem += sizeof(struct f2fs_nm_info);
>   si->base_mem += __bitmap_size(sbi, NAT_BITMAP);
>  
> +get_cache:
> + si->cache_mem = 0;
> +
>   /* build gc */
> - si->base_mem += sizeof(struct f2fs_gc_kthread);
> + if (sbi->gc_thread)
> + si->cache_mem += sizeof(struct f2fs_gc_kthread);
> +
> + /* build merge flush thread */
> + if (SM_I(sbi)->cmd_control_info)
> + si->cache_mem += sizeof(struct flush_cmd_control);
>  
> -get_cache:
>   /* free nids */
> - si->cache_mem = NM_I(sbi)->fcnt;
> - si->cache_mem += NM_I(sbi)->nat_cnt;
> + si->cache_mem += NM_I(sbi)->fcnt * sizeof(struct free_nid);
> + si->cache_mem += NM_I(sbi)->nat_cnt * sizeof(struct nat_entry);
>   npages = NODE_MAPPING(sbi)->nrpages;
>   si->cache_mem += npages << PAGE_CACHE_SHIFT;
>   npages = META_MAPPING(sbi)->nrpages;
> -- 
> 2.2.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 v4] can: Convert to runtime_pm

[Appana Durga Kedareswara Rao]

Hi Marc,

> -Original Message-
> From: Marc Kleine-Budde [mailto:m...@pengutronix.de]
> Sent: Wednesday, January 07, 2015 5:59 PM
> To: Appana Durga Kedareswara Rao; w...@grandegger.com; Michal Simek;
> grant.lik...@linaro.org
> Cc: linux-...@vger.kernel.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Appana Durga Kedareswara Rao; Soren Brinkmann
> Subject: Re: [PATCH v4] can: Convert to runtime_pm
>
> On 12/23/2014 01:25 PM, Kedareswara rao Appana wrote:
> > Instead of enabling/disabling clocks at several locations in the
> > driver, use the runtime_pm framework. This consolidates the actions
> > for runtime PM in the appropriate callbacks and makes the driver more
> > readable and mantainable.
> >
> > Signed-off-by: Soren Brinkmann 
> > Signed-off-by: Kedareswara rao Appana 
> > ---
> > Chnages for v4:
> >  - Updated with the review comments.
> > Changes for v3:
> >   - Converted the driver to use runtime_pm.
> > Changes for v2:
> >   - Removed the struct platform_device* from suspend/resume
> > as suggest by Lothar.
> >
> >  drivers/net/can/xilinx_can.c |  123
> > +-
> >  1 files changed, 74 insertions(+), 49 deletions(-)
> >
> > diff --git a/drivers/net/can/xilinx_can.c
> > b/drivers/net/can/xilinx_can.c index 6c67643..c71f683 100644
> > --- a/drivers/net/can/xilinx_can.c
> > +++ b/drivers/net/can/xilinx_can.c
> > @@ -32,6 +32,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #define DRIVER_NAME"xilinx_can"
> >
> > @@ -138,7 +139,7 @@ struct xcan_priv {
> > u32 (*read_reg)(const struct xcan_priv *priv, enum xcan_reg reg);
> > void (*write_reg)(const struct xcan_priv *priv, enum xcan_reg reg,
> > u32 val);
> > -   struct net_device *dev;
> > +   struct device *dev;
> > void __iomem *reg_base;
> > unsigned long irq_flags;
> > struct clk *bus_clk;
> > @@ -842,6 +843,13 @@ static int xcan_open(struct net_device *ndev)
> > struct xcan_priv *priv = netdev_priv(ndev);
> > int ret;
> >
> > +   ret = pm_runtime_get_sync(priv->dev);
> > +   if (ret < 0) {
> > +   netdev_err(ndev, "%s: pm_runtime_get failed\r(%d)\n\r",
> > +   __func__, ret);
> > +   return ret;
> > +   }
> > +
> > ret = request_irq(ndev->irq, xcan_interrupt, priv->irq_flags,
> > ndev->name, ndev);
> > if (ret < 0) {
> > @@ -849,29 +857,17 @@ static int xcan_open(struct net_device *ndev)
> > goto err;
> > }
> >
> > -   ret = clk_prepare_enable(priv->can_clk);
> > -   if (ret) {
> > -   netdev_err(ndev, "unable to enable device clock\n");
> > -   goto err_irq;
> > -   }
> > -
> > -   ret = clk_prepare_enable(priv->bus_clk);
> > -   if (ret) {
> > -   netdev_err(ndev, "unable to enable bus clock\n");
> > -   goto err_can_clk;
> > -   }
> > -
> > /* Set chip into reset mode */
> > ret = set_reset_mode(ndev);
> > if (ret < 0) {
> > netdev_err(ndev, "mode resetting failed!\n");
> > -   goto err_bus_clk;
> > +   goto err_irq;
> > }
> >
> > /* Common open */
> > ret = open_candev(ndev);
> > if (ret)
> > -   goto err_bus_clk;
> > +   goto err_irq;
> >
> > ret = xcan_chip_start(ndev);
> > if (ret < 0) {
> > @@ -887,13 +883,11 @@ static int xcan_open(struct net_device *ndev)
> >
> >  err_candev:
> > close_candev(ndev);
> > -err_bus_clk:
> > -   clk_disable_unprepare(priv->bus_clk);
> > -err_can_clk:
> > -   clk_disable_unprepare(priv->can_clk);
> >  err_irq:
> > free_irq(ndev->irq, ndev);
> >  err:
> > +   pm_runtime_put(priv->dev);
> > +
> > return ret;
> >  }
> >
> > @@ -910,12 +904,11 @@ static int xcan_close(struct net_device *ndev)
> > netif_stop_queue(ndev);
> > napi_disable(>napi);
> > xcan_chip_stop(ndev);
> > -   clk_disable_unprepare(priv->bus_clk);
> > -   clk_disable_unprepare(priv->can_clk);
> > free_irq(ndev->irq, ndev);
> > close_candev(ndev);
> >
> > can_led_event(ndev, CAN_LED_EVENT_STOP);
> > +   pm_runtime_put(priv->dev);
> >
> > return 0;
> >  }
> > @@ -934,27 +927,20 @@ static int xcan_get_berr_counter(const struct
> net_device *ndev,
> > struct xcan_priv *priv = netdev_priv(ndev);
> > int ret;
> >
> > -   ret = clk_prepare_enable(priv->can_clk);
> > -   if (ret)
> > -   goto err;
> > -
> > -   ret = clk_prepare_enable(priv->bus_clk);
> > -   if (ret)
> > -   goto err_clk;
> > +   ret = pm_runtime_get_sync(priv->dev);
> > +   if (ret < 0) {
> > +   netdev_err(ndev, "%s: pm_runtime_get failed\r(%d)\n\r",
> > +   __func__, ret);
>
> Please remove the \r from the error messages.
>

Ok

> > +   return ret;
> > +   }
> >
> > bec->txerr = priv->read_reg(priv, XCAN_ECR_OFFSET) &
> XCAN_ECR_TEC_MASK;
> > bec->rxerr = ((priv->read_reg(priv, XCAN_ECR_OFFSET) &
> > 

Re: [PATCH] staging: unisys: Convert direct LOGERR uses to pr_err

[Joe Perches]

On Sat, 2015-01-10 at 21:24 -0800, Greg Kroah-Hartman wrote:
> On Sat, Jan 10, 2015 at 08:55:21PM -0800, Joe Perches wrote:
> > On Sat, 2015-01-10 at 20:13 -0800, Greg Kroah-Hartman wrote:
> > > On Sat, Jan 10, 2015 at 07:09:02PM -0800, Joe Perches wrote:
> > > > Use the normal logging facility instead of a new macro.
> > > > 
> > > > Miscellanea:
> > > > 
> > > > o Realign arguments
> > > > o Remove unnecessary alloc error messages as alloc failures
> > > >   already emits a generic OOM message with a dump_stack
> > > > o Add missing newlines to these messages to avoid interleaving
> > > > o Spelling/typo fixes in those messages
> > []
> > > I rejected the other patch that did much this same thing, almost all of
> > > these should be converted to use dev_* calls instead of pr_* calls, as
> > > this is a driver, and drivers should always have access to a struct
> > > device.  If not, they need to be fixed.
> > 
> > Baby steps.
> > 
> > This one prevents interleaving
> > and fixes typos.
> 
> Yes, but converting it to dev_* at the same time saves a step, and gets
> it done properly.  Leaving messages at pr_* levels takes away the
> checkpatch warning, which makes the code "seem" to be acceptable.

I think you've not looked at the code very much.

Many of these things can not be converted to dev_
as there is not a single device there.

Many of these are error messages referring to busses that
support many devices.

Converting them to dev_ piecemeal or wholesale
isn't possible.

--
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 2/2] f2fs: enable recover_xattr_data to avoid cp when fsync after operating xattr

[Jaegeuk Kim]

On Sat, Jan 10, 2015 at 08:08:33PM +0800, Chao Yu wrote:
> Hi Jaegeuk,
> 
> > -Original Message-
> > From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> > Sent: Wednesday, January 07, 2015 3:44 AM
> > To: Chao Yu
> > Cc: Changman Lee; linux-f2fs-de...@lists.sourceforge.net; 
> > linux-kernel@vger.kernel.org
> > Subject: Re: [f2fs-dev][PATCH 2/2] f2fs: enable recover_xattr_data to avoid 
> > cp when fsync after
> > operating xattr
> > 
> > Hi Chao,
> > 
> > On Tue, Jan 06, 2015 at 02:29:40PM +0800, Chao Yu wrote:
> > > Now if we call fsync() after we update the xattr date belongs to the 
> > > file, f2fs
> > > will do checkpoint to keep data.
> > > This can cause low performance because checkpoint block most operation 
> > > and write
> > > lots of blocks. So we'd better to avoid doing checkpoint by writing 
> > > modified
> > > xattr node page to warm node segment, and then it can be recovered when 
> > > we mount
> > > this device later on.
> > 
> > You're trying to change the writing policy as xattr blocks are written into
> > WARM_NODE area instead of COLD_NODE area.
> > I don't think xattrs are frequently changed between each fsync calls.
> > 
> > How do you think?
> 
> I'm not sure whether there is a scenario that setxattr and fsync are invoked
> alternately, but if there is, our performance will decrease obviously.
> 
> If you don't want to change writing policy, how about writing xattr node with
> fsync flag into cold node segment when fsync() is called, then try to recover
> it from cold node chain when recovery after abnormally pow-cut, this way can
> avoid cp frequently in above scenario.

Firt of all, I don't think this scenario is frequent enough that we have to
break the exisiting writing and recovery procedures.
Moreover, if xattr entries are covered by inline_xattr, it doesn't trigger
checkpoint.

Let me know, if I'm missing something.

If you try to change the recovery procedure, it needs to think about the
disk full condition. (i.e., space_for_roll_forward())
And, I don't want to search cold node chain.

Thanks,

> 
> Thanks,
> Yu
--
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] staging: unisys: Convert direct LOGERR uses to pr_err

[Greg Kroah-Hartman]

On Sat, Jan 10, 2015 at 08:55:21PM -0800, Joe Perches wrote:
> On Sat, 2015-01-10 at 20:13 -0800, Greg Kroah-Hartman wrote:
> > On Sat, Jan 10, 2015 at 07:09:02PM -0800, Joe Perches wrote:
> > > Use the normal logging facility instead of a new macro.
> > > 
> > > Miscellanea:
> > > 
> > > o Realign arguments
> > > o Remove unnecessary alloc error messages as alloc failures
> > >   already emits a generic OOM message with a dump_stack
> > > o Add missing newlines to these messages to avoid interleaving
> > > o Spelling/typo fixes in those messages
> []
> > I rejected the other patch that did much this same thing, almost all of
> > these should be converted to use dev_* calls instead of pr_* calls, as
> > this is a driver, and drivers should always have access to a struct
> > device.  If not, they need to be fixed.
> 
> Baby steps.
> 
> This one prevents interleaving
> and fixes typos.

Yes, but converting it to dev_* at the same time saves a step, and gets
it done properly.  Leaving messages at pr_* levels takes away the
checkpatch warning, which makes the code "seem" to be acceptable.

sorry,

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] staging: unisys: Convert direct LOGERR uses to pr_err

[Joe Perches]

On Sat, 2015-01-10 at 20:13 -0800, Greg Kroah-Hartman wrote:
> On Sat, Jan 10, 2015 at 07:09:02PM -0800, Joe Perches wrote:
> > Use the normal logging facility instead of a new macro.
> > 
> > Miscellanea:
> > 
> > o Realign arguments
> > o Remove unnecessary alloc error messages as alloc failures
> >   already emits a generic OOM message with a dump_stack
> > o Add missing newlines to these messages to avoid interleaving
> > o Spelling/typo fixes in those messages
[]
> I rejected the other patch that did much this same thing, almost all of
> these should be converted to use dev_* calls instead of pr_* calls, as
> this is a driver, and drivers should always have access to a struct
> device.  If not, they need to be fixed.

Baby steps.

This one prevents interleaving
and fixes typos.


--
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] staging: unisys: Convert direct LOGERR uses to pr_err

[Greg Kroah-Hartman]

On Sat, Jan 10, 2015 at 07:09:02PM -0800, Joe Perches wrote:
> Use the normal logging facility instead of a new macro.
> 
> Miscellanea:
> 
> o Realign arguments
> o Remove unnecessary alloc error messages as alloc failures
>   already emits a generic OOM message with a dump_stack
> o Add missing newlines to these messages to avoid interleaving
> o Spelling/typo fixes in those messages
> 
> Signed-off-by: Joe Perches 
> ---
>  drivers/staging/unisys/include/uisutils.h  |   4 +-
>  drivers/staging/unisys/uislib/uislib.c | 169 
> ++---
>  drivers/staging/unisys/uislib/uisqueue.c   |   4 +-
>  drivers/staging/unisys/uislib/uisthread.c  |   4 +-
>  drivers/staging/unisys/uislib/uisutils.c   |  34 ++---
>  drivers/staging/unisys/virthba/virthba.c   | 119 +++
>  drivers/staging/unisys/virtpci/virtpci.c   |  71 +
>  drivers/staging/unisys/visorchipset/file.c |   2 +-
>  .../unisys/visorchipset/visorchipset_main.c| 159 ++-
>  9 files changed, 276 insertions(+), 290 deletions(-)
> 
> diff --git a/drivers/staging/unisys/include/uisutils.h 
> b/drivers/staging/unisys/include/uisutils.h
> index 7414220..f937892 100644
> --- a/drivers/staging/unisys/include/uisutils.h
> +++ b/drivers/staging/unisys/include/uisutils.h
> @@ -206,10 +206,10 @@ wait_for_valid_guid(uuid_le __iomem *guid)
> (void __iomem *)guid, sizeof(uuid_le));
>   if (uuid_le_cmp(tmpguid, NULL_UUID_LE) != 0)
>   break;
> - LOGERR("Waiting for non-0 GUID (why???)...\n");
> + pr_err("Waiting for non-0 GUID (why???)...\n");

I rejected the other patch that did much this same thing, almost all of
these should be converted to use dev_* calls instead of pr_* calls, as
this is a driver, and drivers should always have access to a struct
device.  If not, they need to be fixed.

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/

[PATCH v4 2/6] arm64: Add more test functions to insn.c

[David Long]

From: "David A. Long" 

Certain instructions are hard to execute correctly out-of-line (as in
kprobes).  Test functions are added to insn.[hc] to identify these.  The
instructions include any that use PC-relative addressing, change the PC,
or change interrupt masking. For efficiency and simplicity test
functions are also added for small collections of related instructions.

Signed-off-by: David A. Long 
---
 arch/arm64/include/asm/insn.h | 21 +++--
 arch/arm64/kernel/insn.c  | 18 ++
 2 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index e2ff32a..466afd4 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -223,8 +223,13 @@ static __always_inline bool aarch64_insn_is_##abbr(u32 
code) \
 static __always_inline u32 aarch64_insn_get_##abbr##_value(void) \
 { return (val); }
 
+__AARCH64_INSN_FUNCS(adr,  0x9F00, 0x1000)
+__AARCH64_INSN_FUNCS(prfm_lit, 0xFF00, 0xD800)
 __AARCH64_INSN_FUNCS(str_reg,  0x3FE0EC00, 0x38206800)
 __AARCH64_INSN_FUNCS(ldr_reg,  0x3FE0EC00, 0x38606800)
+__AARCH64_INSN_FUNCS(ldr_lit,  0xBF00, 0x1800)
+__AARCH64_INSN_FUNCS(ldrsw_lit,0xFF00, 0x9800)
+__AARCH64_INSN_FUNCS(exclusive,0x3F00, 0x0800)
 __AARCH64_INSN_FUNCS(stp_post, 0x7FC0, 0x2880)
 __AARCH64_INSN_FUNCS(ldp_post, 0x7FC0, 0x28C0)
 __AARCH64_INSN_FUNCS(stp_pre,  0x7FC0, 0x2980)
@@ -264,9 +269,15 @@ __AARCH64_INSN_FUNCS(ands, 0x7F20, 0x6A00)
 __AARCH64_INSN_FUNCS(bics, 0x7F20, 0x6A20)
 __AARCH64_INSN_FUNCS(b,0xFC00, 0x1400)
 __AARCH64_INSN_FUNCS(bl,   0xFC00, 0x9400)
-__AARCH64_INSN_FUNCS(cbz,  0xFE00, 0x3400)
-__AARCH64_INSN_FUNCS(cbnz, 0xFE00, 0x3500)
+__AARCH64_INSN_FUNCS(b_bl, 0x7C00, 0x1400)
+__AARCH64_INSN_FUNCS(cb,   0x7E00, 0x3400)
+__AARCH64_INSN_FUNCS(cbz,  0x7F00, 0x3400)
+__AARCH64_INSN_FUNCS(cbnz, 0x7F00, 0x3500)
 __AARCH64_INSN_FUNCS(bcond,0xFF10, 0x5400)
+__AARCH64_INSN_FUNCS(tb,   0x7E00, 0x3600)
+__AARCH64_INSN_FUNCS(tbz,  0x7F00, 0x3600)
+__AARCH64_INSN_FUNCS(tbnz, 0x7F00, 0x3700)
+__AARCH64_INSN_FUNCS(b_bl_cb_tb, 0x5C00, 0x1400)
 __AARCH64_INSN_FUNCS(svc,  0xFFE0001F, 0xD401)
 __AARCH64_INSN_FUNCS(hvc,  0xFFE0001F, 0xD402)
 __AARCH64_INSN_FUNCS(smc,  0xFFE0001F, 0xD403)
@@ -274,7 +285,11 @@ __AARCH64_INSN_FUNCS(brk,  0xFFE0001F, 0xD420)
 __AARCH64_INSN_FUNCS(hint, 0xF01F, 0xD503201F)
 __AARCH64_INSN_FUNCS(br,   0xFC1F, 0xD61F)
 __AARCH64_INSN_FUNCS(blr,  0xFC1F, 0xD63F)
+__AARCH64_INSN_FUNCS(br_blr,   0xFFDFFC1F, 0xD61F)
 __AARCH64_INSN_FUNCS(ret,  0xFC1F, 0xD65F)
+__AARCH64_INSN_FUNCS(msr_imm,  0xFFF8F000, 0xD5004000)
+__AARCH64_INSN_FUNCS(msr_reg,  0xFFF0, 0xD510)
+__AARCH64_INSN_FUNCS(msr_daif, 0xF0DF, 0xD50340DF)
 
 #undef __AARCH64_INSN_FUNCS
 
@@ -283,6 +298,8 @@ bool aarch64_insn_is_nop(u32 insn);
 int aarch64_insn_read(void *addr, u32 *insnp);
 int aarch64_insn_write(void *addr, u32 insn);
 enum aarch64_insn_encoding_class aarch64_get_insn_class(u32 insn);
+bool aarch64_insn_uses_literal(u32 insn);
+bool aarch64_insn_is_branch(u32 insn);
 u32 aarch64_insn_encode_immediate(enum aarch64_insn_imm_type type,
  u32 insn, u64 imm);
 u32 aarch64_insn_gen_branch_imm(unsigned long pc, unsigned long addr,
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index 7e9327a..8021722 100644
--- a/arch/arm64/kernel/insn.c
+++ b/arch/arm64/kernel/insn.c
@@ -72,6 +72,24 @@ bool __kprobes aarch64_insn_is_nop(u32 insn)
}
 }
 
+bool aarch64_insn_uses_literal(u32 insn)
+{
+   /* ldr/ldrsw (literal), prfm */
+
+   return aarch64_insn_is_ldr_lit(insn) ||
+   aarch64_insn_is_ldrsw_lit(insn) ||
+   aarch64_insn_is_prfm_lit(insn);
+}
+
+bool aarch64_insn_is_branch(u32 insn)
+{
+   /* b, bl, cb*, tb*, b.cond, br, blr */
+
+   return aarch64_insn_is_b_bl_cb_tb(insn) ||
+   aarch64_insn_is_br_blr(insn) ||
+   aarch64_insn_is_bcond(insn);
+}
+
 /*
  * In ARMv8-A, A64 instructions have a fixed length of 32 bits and are always
  * little-endian.
-- 
1.8.1.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/

[PATCH v4 3/6] arm64: Kprobes with single stepping support

[David Long]

From: Sandeepa Prabhu 

Add support for basic kernel probes(kprobes) and jump probes
(jprobes) for ARM64.

Kprobes will utilize software breakpoint and single step debug
exceptions supported on ARM v8.

Software breakpoint is placed at the probe address to trap the
kernel execution into kprobe handler.

ARM v8 supports single stepping to be enabled while exception return
(ERET) with next PC in exception return address (ELR_EL1). The
kprobe handler prepares an executable memory slot for out-of-line
execution with a copy of the original instruction being probed, and
enables single stepping from the instruction slot. With this scheme,
the instruction is executed with the exact same register context
'except PC' that points to instruction slot.

Debug mask(PSTATE.D) is enabled only when single stepping a recursive
kprobe, e.g.: during kprobes reenter so that probed instruction can be
single stepped within the kprobe handler -exception- context.
The recursion depth of kprobe is always 2, i.e. upon probe re-entry,
any further re-entry is prevented by not calling handlers and the case
counted as a missed kprobe).

Single stepping from slot has a drawback on PC-relative accesses
like branching and symbolic literals access as offset from new PC
(slot address) may not be ensured to fit in immediate value of
opcode. Such instructions needs simulation, so reject
probing such instructions.

Instructions generating exceptions or cpu mode change are rejected,
and not allowed to insert probe for these instructions.

Instructions using Exclusive Monitor are rejected too.

System instructions are mostly enabled for stepping, except MSR
immediate that updates "daif" flags in PSTATE, which are not safe
for probing.

Changes since v3:
from David Long:
1) Removed unnecessary addtion of NOP after out-of-line instruction.
2) Replaced table-driven instruction parsing with calls to external
   test functions.
from Steve Capper:
3) Disable local irq while executing out of line instruction.

Signed-off-by: Sandeepa Prabhu 
Signed-off-by: Steve Capper 
Signed-off-by: David A. Long 
---
 arch/arm64/Kconfig|   1 +
 arch/arm64/include/asm/kprobes.h  |  60 +
 arch/arm64/include/asm/probes.h   |  50 
 arch/arm64/include/asm/ptrace.h   |   3 +-
 arch/arm64/kernel/Makefile|   1 +
 arch/arm64/kernel/kprobes-arm64.c |  65 +
 arch/arm64/kernel/kprobes-arm64.h |  28 ++
 arch/arm64/kernel/kprobes.c   | 551 ++
 arch/arm64/kernel/kprobes.h   |  30 +++
 arch/arm64/kernel/vmlinux.lds.S   |   1 +
 10 files changed, 789 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/include/asm/kprobes.h
 create mode 100644 arch/arm64/include/asm/probes.h
 create mode 100644 arch/arm64/kernel/kprobes-arm64.c
 create mode 100644 arch/arm64/kernel/kprobes-arm64.h
 create mode 100644 arch/arm64/kernel/kprobes.c
 create mode 100644 arch/arm64/kernel/kprobes.h

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 12b3fd6..b3f61ba 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -67,6 +67,7 @@ config ARM64
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_RCU_TABLE_FREE
select HAVE_SYSCALL_TRACEPOINTS
+   select HAVE_KPROBES if !XIP_KERNEL
select IRQ_DOMAIN
select MODULES_USE_ELF_RELA
select NO_BOOTMEM
diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
new file mode 100644
index 000..b35d3b9
--- /dev/null
+++ b/arch/arm64/include/asm/kprobes.h
@@ -0,0 +1,60 @@
+/*
+ * arch/arm64/include/asm/kprobes.h
+ *
+ * Copyright (C) 2013 Linaro Limited
+ *
+ * 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 program is distributed in the hope that 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 _ARM_KPROBES_H
+#define _ARM_KPROBES_H
+
+#include 
+#include 
+#include 
+
+#define __ARCH_WANT_KPROBES_INSN_SLOT
+#define MAX_INSN_SIZE  1
+#define MAX_STACK_SIZE 128
+
+#define flush_insn_slot(p) do { } while (0)
+#define kretprobe_blacklist_size   0
+
+#include 
+
+struct prev_kprobe {
+   struct kprobe *kp;
+   unsigned int status;
+};
+
+/* Single step context for kprobe */
+struct kprobe_step_ctx {
+#define KPROBES_STEP_NONE  0x0
+#define KPROBES_STEP_PENDING   0x1
+   unsigned long ss_status;
+   unsigned long match_addr;
+};
+
+/* per-cpu kprobe control block */
+struct kprobe_ctlblk {
+   unsigned int kprobe_status;
+   unsigned long saved_irqflag;
+   struct prev_kprobe prev_kprobe;
+   struct kprobe_step_ctx ss_ctx;
+   struct pt_regs jprobe_saved_regs;
+   char 

[PATCH v4 4/6] arm64: Kprobes instruction simulation support

[David Long]

From: Sandeepa Prabhu 

Add support for AArch64 instruction simulation in kprobes.

Kprobes needs simulation of instructions that cannot be stepped
from different memory location, e.g.: those instructions
that uses PC-relative addressing. In simulation, the behaviour
of the instruction is implemented using a copy of pt_regs.

Following instruction catagories are simulated:
 - All branching instructions(conditional, register, and immediate)
 - Literal access instructions(load-literal, adr/adrp)

Conditional execution is limited to branching instructions in
ARM v8. If conditions at PSTATE do not match the condition fields
of opcode, the instruction is effectively NOP. Kprobes considers
this case as 'miss'.
changes since v3:
from David A. Long:
1) Fix incorrect simulate_ldrsw_literal() semantics.
2) Use instruction test functions instead of private parse table.
from Will Cohen:
3) Remove PC adjustments when simulating an instruction.
4) Fix displacement calculations.

Signed-off-by: Sandeepa Prabhu 
Signed-off-by: William Cohen 
Signed-off-by: David A. Long 
---
 arch/arm64/kernel/Makefile   |   4 +-
 arch/arm64/kernel/kprobes-arm64.c|  96 +
 arch/arm64/kernel/kprobes-arm64.h|   2 +
 arch/arm64/kernel/kprobes.c  |  35 ++-
 arch/arm64/kernel/probes-condn-check.c   | 122 ++
 arch/arm64/kernel/probes-simulate-insn.c | 174 +++
 arch/arm64/kernel/probes-simulate-insn.h |  33 ++
 7 files changed, 462 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm64/kernel/probes-condn-check.c
 create mode 100644 arch/arm64/kernel/probes-simulate-insn.c
 create mode 100644 arch/arm64/kernel/probes-simulate-insn.h

diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 6ca9fc0..6e4dcde 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -31,7 +31,9 @@ arm64-obj-$(CONFIG_ARM64_CPU_SUSPEND) += sleep.o suspend.o
 arm64-obj-$(CONFIG_CPU_IDLE)   += cpuidle.o
 arm64-obj-$(CONFIG_JUMP_LABEL) += jump_label.o
 arm64-obj-$(CONFIG_KGDB)   += kgdb.o
-arm64-obj-$(CONFIG_KPROBES)+= kprobes.o kprobes-arm64.o
+arm64-obj-$(CONFIG_KPROBES)+= kprobes.o kprobes-arm64.o
\
+  probes-simulate-insn.o   
\
+  probes-condn-check.o
 arm64-obj-$(CONFIG_EFI)+= efi.o efi-stub.o efi-entry.o
 arm64-obj-$(CONFIG_PCI)+= pci.o
 arm64-obj-$(CONFIG_ARMV8_DEPRECATED)   += armv8_deprecated.o
diff --git a/arch/arm64/kernel/kprobes-arm64.c 
b/arch/arm64/kernel/kprobes-arm64.c
index a698bd3..531d14a 100644
--- a/arch/arm64/kernel/kprobes-arm64.c
+++ b/arch/arm64/kernel/kprobes-arm64.c
@@ -20,6 +20,76 @@
 #include 
 
 #include "kprobes-arm64.h"
+#include "probes-simulate-insn.h"
+
+/*
+ * condition check functions for kprobes simulation
+ */
+static unsigned long __kprobes
+__check_pstate(struct kprobe *p, struct pt_regs *regs)
+{
+   struct arch_specific_insn *asi = >ainsn;
+   unsigned long pstate = regs->pstate & 0x;
+
+   return asi->pstate_cc(pstate);
+}
+
+static unsigned long __kprobes
+__check_cbz(struct kprobe *p, struct pt_regs *regs)
+{
+   return check_cbz((u32)p->opcode, regs);
+}
+
+static unsigned long __kprobes
+__check_cbnz(struct kprobe *p, struct pt_regs *regs)
+{
+   return check_cbnz((u32)p->opcode, regs);
+}
+
+static unsigned long __kprobes
+__check_tbz(struct kprobe *p, struct pt_regs *regs)
+{
+   return check_tbz((u32)p->opcode, regs);
+}
+
+static unsigned long __kprobes
+__check_tbnz(struct kprobe *p, struct pt_regs *regs)
+{
+   return check_tbnz((u32)p->opcode, regs);
+}
+
+/*
+ * prepare functions for instruction simulation
+ */
+static void __kprobes
+prepare_none(struct kprobe *p, struct arch_specific_insn *asi)
+{
+}
+
+static void __kprobes
+prepare_bcond(struct kprobe *p, struct arch_specific_insn *asi)
+{
+   kprobe_opcode_t insn = p->opcode;
+
+   asi->check_condn = __check_pstate;
+   asi->pstate_cc = kprobe_condition_checks[insn & 0xf];
+}
+
+static void __kprobes
+prepare_cbz_cbnz(struct kprobe *p, struct arch_specific_insn *asi)
+{
+   kprobe_opcode_t insn = p->opcode;
+
+   asi->check_condn = (insn & (1 << 24)) ? __check_cbnz : __check_cbz;
+}
+
+static void __kprobes
+prepare_tbz_tbnz(struct kprobe *p, struct arch_specific_insn *asi)
+{
+   kprobe_opcode_t insn = p->opcode;
+
+   asi->check_condn = (insn & (1 << 24)) ? __check_tbnz : __check_tbz;
+}
 
 static bool aarch64_insn_is_steppable(u32 insn)
 {
@@ -60,6 +130,32 @@ arm_kprobe_decode_insn(kprobe_opcode_t insn, struct 
arch_specific_insn *asi)
 */
if (aarch64_insn_is_steppable(insn))
return INSN_GOOD;
+
+   asi->prepare = prepare_none;
+
+   if (aarch64_insn_is_bcond(insn)) {
+   asi->prepare = 

[PATCH v4 5/6] arm64: Add kernel return probes support(kretprobes)

[David Long]

From: Sandeepa Prabhu 

AArch64 ISA does not have instructions to pop the PC register
value from the stack(like ARM v7 has ldmia {...,pc}) without using
one of the general purpose registers. This means return probes
cannot return to the actual return address directly without
modifying register context, and without trapping into debug exception.

So, like many other architectures, we prepare a global routine
with NOPs which serve as a trampoline to hack away the
function return address by placing an extra kprobe on the
trampoline entry.

The pre-handler of this special 'trampoline' kprobe executes the return
probe handler functions and restores original return address in ELR_EL1.
This way the saved pt_regs still hold the original register context to be
carried back to the probed kernel function.

Signed-off-by: Sandeepa Prabhu 
Signed-off-by: David A. Long 
---
 arch/arm64/Kconfig   |   1 +
 arch/arm64/include/asm/kprobes.h |   1 +
 arch/arm64/kernel/kprobes.c  | 114 ++-
 3 files changed, 115 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index b3f61ba..de4f056 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -68,6 +68,7 @@ config ARM64
select HAVE_RCU_TABLE_FREE
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_KPROBES if !XIP_KERNEL
+   select HAVE_KRETPROBES if HAVE_KPROBES
select IRQ_DOMAIN
select MODULES_USE_ELF_RELA
select NO_BOOTMEM
diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
index b35d3b9..a2de3b8 100644
--- a/arch/arm64/include/asm/kprobes.h
+++ b/arch/arm64/include/asm/kprobes.h
@@ -56,5 +56,6 @@ void arch_remove_kprobe(struct kprobe *);
 int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
 int kprobe_exceptions_notify(struct notifier_block *self,
 unsigned long val, void *data);
+void kretprobe_trampoline(void);
 
 #endif /* _ARM_KPROBES_H */
diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
index 31a7894e..cd1069c 100644
--- a/arch/arm64/kernel/kprobes.c
+++ b/arch/arm64/kernel/kprobes.c
@@ -559,6 +559,117 @@ int __kprobes longjmp_break_handler(struct kprobe *p, 
struct pt_regs *regs)
return 0;
 }
 
+/*
+ * Kretprobes: kernel return probes handling
+ *
+ * AArch64 mode does not support popping the PC value from the
+ * stack like on ARM 32-bit (ldmia {..,pc}), so atleast one
+ * register need to be used to achieve branching/return.
+ * It means return probes cannot return back to the original
+ * return address directly without modifying the register context.
+ *
+ * So like other architectures, we prepare a global routine
+ * with NOPs, which serve as trampoline address that hack away the
+ * function return, with the exact register context.
+ * Placing a kprobe on trampoline routine entry will trap again to
+ * execute return probe handlers and restore original return address
+ * in ELR_EL1, this way saved pt_regs still hold the original
+ * register values to be carried back to the caller.
+ */
+static void __used kretprobe_trampoline_holder(void)
+{
+   asm volatile (".global kretprobe_trampoline\n"
+   "kretprobe_trampoline:\n"
+   "NOP\n\t"
+   "NOP\n\t");
+}
+
+static int __kprobes
+trampoline_probe_handler(struct kprobe *p, struct pt_regs *regs)
+{
+   struct kretprobe_instance *ri = NULL;
+   struct hlist_head *head, empty_rp;
+   struct hlist_node *tmp;
+   unsigned long flags, orig_ret_addr = 0;
+   unsigned long trampoline_address =
+   (unsigned long)_trampoline;
+
+   INIT_HLIST_HEAD(_rp);
+   kretprobe_hash_lock(current, , );
+
+   /*
+* It is possible to have multiple instances associated with a given
+* task either because multiple functions in the call path have
+* a return probe installed on them, and/or more than one return
+* probe was registered for a target function.
+*
+* We can handle this because:
+* - instances are always inserted at the head of the list
+* - when multiple return probes are registered for the same
+*   function, the first instance's ret_addr will point to the
+*   real return address, and all the rest will point to
+*   kretprobe_trampoline
+*/
+   hlist_for_each_entry_safe(ri, tmp, head, hlist) {
+   if (ri->task != current)
+   /* another task is sharing our hash bucket */
+   continue;
+
+   if (ri->rp && ri->rp->handler) {
+   __this_cpu_write(current_kprobe, >rp->kp);
+   get_kprobe_ctlblk()->kprobe_status = KPROBE_HIT_ACTIVE;
+   ri->rp->handler(ri, regs);
+   __this_cpu_write(current_kprobe, NULL);
+   }
+
+ 

[PATCH v4 0/6] arm64: Add kernel probes (kprobes) support

[David Long]

From: "David A. Long" 

This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches, 
first
seen in October 2013. This version attempts to address concerns raised by
reviewers and also fixes problems discovered during testing, particularly during
SMP testing.

This patchset adds support for kernel probes(kprobes), jump probes(jprobes)
and return probes(kretprobes) support for ARM64.

The kprobes mechanism makes use of software breakpoint and single stepping
support available in the ARM v8 kernel.

Changes since v2 include:

1) Removal of NOP padding in kprobe XOL slots. Slots are now exactly one
instruction long.
2) Disabling of interrupts during execution in single-step mode.
3) Fixing of numerous problems in instruction simulation code (mostly
thanks to Will Cohen).
4) Support for the HAVE_REGS_AND_STACK_ACCESS_API feature is added, to allow
access to kprobes through debugfs.
5) kprobes is *not* enabled in defconfig.
6) Numerous complaints from checkpatch have been cleaned up, although a couple
remain as removing the function pointer typedefs results in ugly code.

Changes since v3 include:

1) Remove table-driven instruction parsing and replace with an if statement
calling out to old and new instruction test functions in insn.c.
2) I removed the addition of orig_x0 to ptrace.h.
3) Reorder the patches.
4) Replace the previous interrupt disabling (from Will Cohen) with
an improved solution (from Steve Capper).

David A. Long (2):
  arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature
  arm64: Add more test functions to insn.c

Sandeepa Prabhu (4):
  arm64: Kprobes with single stepping support
  arm64: Kprobes instruction simulation support
  arm64: Add kernel return probes support(kretprobes)
  kprobes: Add arm64 case in kprobe example module

 arch/arm64/Kconfig   |   3 +
 arch/arm64/include/asm/insn.h|  21 +-
 arch/arm64/include/asm/kprobes.h |  61 +++
 arch/arm64/include/asm/probes.h  |  50 +++
 arch/arm64/include/asm/ptrace.h  |  32 +-
 arch/arm64/include/uapi/asm/ptrace.h |  36 ++
 arch/arm64/kernel/Makefile   |   3 +
 arch/arm64/kernel/insn.c |  18 +
 arch/arm64/kernel/kprobes-arm64.c| 161 +++
 arch/arm64/kernel/kprobes-arm64.h|  30 ++
 arch/arm64/kernel/kprobes.c  | 692 +++
 arch/arm64/kernel/kprobes.h  |  30 ++
 arch/arm64/kernel/probes-condn-check.c   | 122 ++
 arch/arm64/kernel/probes-simulate-insn.c | 174 
 arch/arm64/kernel/probes-simulate-insn.h |  33 ++
 arch/arm64/kernel/ptrace.c   | 119 ++
 arch/arm64/kernel/vmlinux.lds.S  |   1 +
 samples/kprobes/kprobe_example.c |   8 +
 18 files changed, 1591 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm64/include/asm/kprobes.h
 create mode 100644 arch/arm64/include/asm/probes.h
 create mode 100644 arch/arm64/kernel/kprobes-arm64.c
 create mode 100644 arch/arm64/kernel/kprobes-arm64.h
 create mode 100644 arch/arm64/kernel/kprobes.c
 create mode 100644 arch/arm64/kernel/kprobes.h
 create mode 100644 arch/arm64/kernel/probes-condn-check.c
 create mode 100644 arch/arm64/kernel/probes-simulate-insn.c
 create mode 100644 arch/arm64/kernel/probes-simulate-insn.h

-- 
1.8.1.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/

[PATCH v4 6/6] kprobes: Add arm64 case in kprobe example module

[David Long]

From: Sandeepa Prabhu 

Add info prints in sample kprobe handlers for ARM64

Signed-off-by: Sandeepa Prabhu 
---
 samples/kprobes/kprobe_example.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/samples/kprobes/kprobe_example.c b/samples/kprobes/kprobe_example.c
index 366db1a..51d459c 100644
--- a/samples/kprobes/kprobe_example.c
+++ b/samples/kprobes/kprobe_example.c
@@ -42,6 +42,10 @@ static int handler_pre(struct kprobe *p, struct pt_regs 
*regs)
" ex1 = 0x%lx\n",
p->addr, regs->pc, regs->ex1);
 #endif
+#ifdef CONFIG_ARM64
+   pr_info("pre_handler: p->addr = 0x%p, pc = 0x%lx\n",
+   p->addr, (long)regs->pc);
+#endif
 
/* A dump_stack() here will give a stack backtrace */
return 0;
@@ -67,6 +71,10 @@ static void handler_post(struct kprobe *p, struct pt_regs 
*regs,
printk(KERN_INFO "post_handler: p->addr = 0x%p, ex1 = 0x%lx\n",
p->addr, regs->ex1);
 #endif
+#ifdef CONFIG_ARM64
+   pr_info("post_handler: p->addr = 0x%p, pc = 0x%lx\n",
+   p->addr, (long)regs->pc);
+#endif
 }
 
 /*
-- 
1.8.1.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/

[PATCH v4 1/6] arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature

[David Long]

From: "David A. Long" 

Add HAVE_REGS_AND_STACK_ACCESS_API feature for arm64.

Signed-off-by: David A. Long 
---
 arch/arm64/Kconfig   |   1 +
 arch/arm64/include/asm/ptrace.h  |  29 +
 arch/arm64/include/uapi/asm/ptrace.h |  36 +++
 arch/arm64/kernel/ptrace.c   | 119 +++
 4 files changed, 185 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index b1f9a20..12b3fd6 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -64,6 +64,7 @@ config ARM64
select HAVE_PERF_EVENTS
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
+   select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_RCU_TABLE_FREE
select HAVE_SYSCALL_TRACEPOINTS
select IRQ_DOMAIN
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index 41ed9e1..3613e49 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -111,6 +111,8 @@ struct pt_regs {
u64 syscallno;
 };
 
+#define MAX_REG_OFFSET (sizeof(struct user_pt_regs) - sizeof(u64))
+
 #define arch_has_single_step() (1)
 
 #ifdef CONFIG_COMPAT
@@ -139,11 +141,38 @@ struct pt_regs {
 #define user_stack_pointer(regs) \
(!compat_user_mode(regs) ? (regs)->sp : (regs)->compat_sp)
 
+/**
+ * regs_get_register() - get register value from its offset
+ * @regs: pt_regs from which register value is gotten
+ * @offset:offset number of the register.
+ *
+ * regs_get_register returns the value of a register whose offset from @regs.
+ * The @offset is the offset of the register in struct pt_regs.
+ * If @offset is bigger than MAX_REG_OFFSET, this returns 0.
+ */
+static inline u64 regs_get_register(struct pt_regs *regs,
+ unsigned int offset)
+{
+   if (unlikely(offset > MAX_REG_OFFSET))
+   return 0;
+   return *(u64 *)((u64)regs + offset);
+}
+
+/* Valid only for Kernel mode traps. */
+static inline unsigned long kernel_stack_pointer(struct pt_regs *regs)
+{
+   return regs->ARM_sp;
+}
+
 static inline unsigned long regs_return_value(struct pt_regs *regs)
 {
return regs->regs[0];
 }
 
+extern int regs_query_register_offset(const char *name);
+extern unsigned long regs_get_kernel_stack_nth(struct pt_regs *regs,
+  unsigned int n);
+
 /*
  * Are the current registers suitable for user mode? (used to maintain
  * security in signal handlers)
diff --git a/arch/arm64/include/uapi/asm/ptrace.h 
b/arch/arm64/include/uapi/asm/ptrace.h
index 6913643..700d28b 100644
--- a/arch/arm64/include/uapi/asm/ptrace.h
+++ b/arch/arm64/include/uapi/asm/ptrace.h
@@ -61,6 +61,42 @@
 
 #ifndef __ASSEMBLY__
 
+#define ARM_cpsr   pstate
+#define ARM_pc pc
+#define ARM_sp sp
+#define ARM_lr regs[30]
+#define ARM_fp regs[29]
+#define ARM_x28regs[28]
+#define ARM_x27regs[27]
+#define ARM_x26regs[26]
+#define ARM_x25regs[25]
+#define ARM_x24regs[24]
+#define ARM_x23regs[23]
+#define ARM_x22regs[22]
+#define ARM_x21regs[21]
+#define ARM_x20regs[20]
+#define ARM_x19regs[19]
+#define ARM_x18regs[18]
+#define ARM_ip1regs[17]
+#define ARM_ip0regs[16]
+#define ARM_x15regs[15]
+#define ARM_x14regs[14]
+#define ARM_x13regs[13]
+#define ARM_x12regs[12]
+#define ARM_x11regs[11]
+#define ARM_x10regs[10]
+#define ARM_x9 regs[9]
+#define ARM_x8 regs[8]
+#define ARM_x7 regs[7]
+#define ARM_x6 regs[6]
+#define ARM_x5 regs[5]
+#define ARM_x4 regs[4]
+#define ARM_x3 regs[3]
+#define ARM_x2 regs[2]
+#define ARM_x1 regs[1]
+#define ARM_x0 regs[0]
+#define ARM_ORIG_x0orig_x0
+
 /*
  * User structures for general purpose, floating point and debug registers.
  */
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index d882b83..9115b25 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -48,6 +48,125 @@
 #define CREATE_TRACE_POINTS
 #include 
 
+struct pt_regs_offset {
+   const char *name;
+   int offset;
+};
+
+#define REG_OFFSET_NAME(r) \
+   {.name = #r, .offset = offsetof(struct pt_regs, ARM_##r)}
+#define REG_OFFSET_END {.name = NULL, .offset = 0}
+
+static const struct pt_regs_offset regoffset_table[] = {
+   REG_OFFSET_NAME(x0),
+   REG_OFFSET_NAME(x1),
+   REG_OFFSET_NAME(x2),
+   REG_OFFSET_NAME(x3),
+   REG_OFFSET_NAME(x4),
+   REG_OFFSET_NAME(x5),
+   REG_OFFSET_NAME(x6),
+   REG_OFFSET_NAME(x7),
+   REG_OFFSET_NAME(x8),
+   REG_OFFSET_NAME(x9),
+   REG_OFFSET_NAME(x10),
+   

[PATCH v9 0/2] crypto: AF_ALG: add AEAD and RNG support

[Stephan Mueller]

Hi,

This patch set adds AEAD and RNG support to the AF_ALG interface
exported by the kernel crypto API. By extending AF_ALG with AEAD and RNG
support, all cipher types the kernel crypto API allows access to are
now accessible from userspace.

Both, AEAD and RNG implementations are stand-alone and do not depend
other AF_ALG interfaces (like hash or skcipher).

The AEAD implementation uses the same approach as provided with
skcipher by offering the following interfaces:

* sendmsg and recvmsg interfaces allowing multiple
  invocations supporting a threaded user space. To support
  multi-threaded user space, kernel-side buffering
  is implemented similarly to skcipher.

* splice / vmsplice interfaces allowing a zero-copy
  invocation

The RNG interface only implements the recvmsg interface as
zero-copy is not applicable.

The new AEAD and RNG interfaces are fully tested with the test application
provided at [1]. That test application exercises all newly added user space
interfaces. The testing covers:

* use of the sendmsg/recvmsg interface

* use of the splice / vmsplice interface

* invocation of all AF_ALG types (aead, rng, skcipher, hash)

* using all types of operation (encryption, decryption, keyed MD,
  MD, random numbers, AEAD decryption with positive and negative
  authentication verification)

* stress testing by running all tests for 30 minutes in an
  endless loop

* test execution on 64 bit and 32 bit

[1] http://www.chronox.de/libkcapi.html

Changes v2:
* rebase to current cryptodev-2.6 tree
* use memzero_explicit to zeroize AEAD associated data
* use sizeof for determining length of AEAD associated data
* update algif_rng.c covering all suggestions from Daniel Borkmann
  
* addition of patch 9: add digestsize interface for hashes
* addition of patch to update documentation covering the userspace interface
* change numbers of getsockopt options: separate them from sendmsg interface
  definitions

Changes v3:
* remove getsockopt interface
* AEAD: associated data is set prepended to the plain/ciphertext
* AEAD: allowing arbitrary associated data lengths
* remove setkey patch as protection was already in the existing code

Changes v4:
* stand-alone implementation of AEAD
* testing of all interfaces offered by AEAD
* stress testing of AEAD and RNG

Changes v5:
* AEAD: add outer while(size) loop in aead_sendmsg to ensure all data is
  copied into the kernel (reporter Herbert Xu)
* AEAD: aead_sendmsg bug fix: change size -= len; to size -= plen;
* AF_ALG / AEAD: add aead_setauthsize and associated extension to
  struct af_alg_type as well as alg_setsockopt (reporter Herbert Xu)
* RNG: rng_recvmsg: use 128 byte stack variable for output of RNG instead
  of ctx->result (reporter Herbert Xu)
* RNG / AF_ALG: allow user space to seed RNG via setsockopt
* RNG: rng_recvmsg bug fix: use genlen as result variable for
  crypto_rng_get_bytes as previously no negative errors were obtained
* AF_ALG: alg_setop: zeroize buffer before free

Changes v6:
* AEAD/RNG: port to 3.19-rc1 with the iov_iter handling
* RNG: use the setkey interface to obtain the seed and drop the patch adding
  a separate reseeding interface
* extract the zeroization patch for alg_setkey into a stand-alone patch
  submission
* fix bug in aead_sufficient_data (reporter Herbert Xu)
* testing of all interfaces with test application provided with libkcapi version
  0.6.2

Changes v7:
* AEAD: aead_recvmsg: change error code from ENOMEM to EINVAL
* AEAD: drop aead_readable/aead_sufficient_data and only use ctx->more to decide
  whether the read side shall become active. This change requires that the
  patch for crypto_aead_decrypt ensuring that the ciphertext contains the
  authentication tag was added -- see https://lkml.org/lkml/2014/12/30/200.
  Otherwise, user space can trigger a kernel crash.
* RNG: patch dropped as it was applied
* AEAD: port Kconfig/Makefile patch forward to current code base

Changes v8:
* Removed check for aead_assoclen in aead_sendmsg
* Fix endless loop bug in aead_sendmsg (check for sgl->cur > ALG_MAX_PAGES in
  while condition removed -- this condition is checked within the loop already)
* Resurrect aead_sufficient_data and call it in aead_sendmsg, aead_sendpage to
  notify caller about wrong invocation
* Re-add aead_sufficient_data to aead_recvmsg to verify user input data before
  using them to ensure the kernel protects against malicious parameters
* Allow arbitrary size of AD (i.e. up to the maximum buffer size of
  ALG_MAX_PAGES)
* When aead_recvmsg receives an error from decryption, release all pages if the
  error is EBADMSG -- this error implies that a proper decryption was performed
  but the integrity of the message is lost. This error is considered to be a
  valid decryption result.
* Add test cases for sendmsg and splice interface to test large AD sizes (in
  case of sendmsg, use 65504 

[PATCH v9 1/2] crypto: AF_ALG: add AEAD support

[Stephan Mueller]

This patch adds the AEAD support for AF_ALG.

The implementation is based on algif_skcipher, but contains heavy
modifications to streamline the interface for AEAD uses.

To use AEAD, the user space consumer has to use the salg_type named
"aead".

The AEAD implementation includes some overhead to calculate the size of
the ciphertext, because the AEAD implementation of the kernel crypto API
makes implied assumption on the location of the authentication tag. When
performing an encryption, the tag will be added to the created
ciphertext (note, the tag is placed adjacent to the ciphertext). For
decryption, the caller must hand in the ciphertext with the tag appended
to the ciphertext. Therefore, the selection of the used memory
needs to add/subtract the tag size from the source/destination buffers
depending on the encryption type. The code is provided with comments
explaining when and how that operation is performed.

A fully working example using all aspects of AEAD is provided at
http://www.chronox.de/libkcapi.html

Signed-off-by: Stephan Mueller 
---
 crypto/algif_aead.c | 679 
 1 file changed, 679 insertions(+)
 create mode 100644 crypto/algif_aead.c

diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
new file mode 100644
index 000..ed41577
--- /dev/null
+++ b/crypto/algif_aead.c
@@ -0,0 +1,679 @@
+/*
+ * algif_aead: User-space interface for AEAD algorithms
+ *
+ * Copyright (C) 2014, Stephan Mueller 
+ *
+ * This file provides the user-space API for AEAD ciphers.
+ *
+ * This file is derived from algif_skcipher.c.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct aead_sg_list {
+   unsigned int cur;
+   struct scatterlist sg[ALG_MAX_PAGES];
+};
+
+struct aead_ctx {
+   struct aead_sg_list tsgl;
+   struct af_alg_sgl rsgl;
+
+   void *iv;
+
+   struct af_alg_completion completion;
+
+   unsigned long used;
+
+   unsigned int len;
+   bool more;
+   bool merge;
+   bool enc;
+   bool trunc;
+
+   size_t aead_assoclen;
+   struct aead_request aead_req;
+};
+
+static inline int aead_sndbuf(struct sock *sk)
+{
+   struct alg_sock *ask = alg_sk(sk);
+   struct aead_ctx *ctx = ask->private;
+
+   return max_t(int, max_t(int, sk->sk_sndbuf & PAGE_MASK, PAGE_SIZE) -
+ ctx->used, 0);
+}
+
+static inline bool aead_writable(struct sock *sk)
+{
+   return PAGE_SIZE <= aead_sndbuf(sk);
+}
+
+static inline bool aead_sufficient_data(struct aead_ctx *ctx)
+{
+   unsigned as = crypto_aead_authsize(crypto_aead_reqtfm(>aead_req));
+
+   return (ctx->used >= (ctx->aead_assoclen + (ctx->enc ? 0 : as)));
+}
+
+static void aead_put_sgl(struct sock *sk)
+{
+   struct alg_sock *ask = alg_sk(sk);
+   struct aead_ctx *ctx = ask->private;
+   struct aead_sg_list *sgl = >tsgl;
+   struct scatterlist *sg = sgl->sg;
+   unsigned int i;
+
+   for (i = 0; i < sgl->cur; i++) {
+   if (!sg_page(sg + i))
+   continue;
+
+   put_page(sg_page(sg + i));
+   sg_assign_page(sg + i, NULL);
+   }
+   sgl->cur = 0;
+   ctx->used = 0;
+   ctx->more = 0;
+   ctx->merge = 0;
+   ctx->trunc = 0;
+}
+
+static int aead_wait_for_wmem(struct sock *sk, unsigned flags)
+{
+   long timeout;
+   DEFINE_WAIT(wait);
+   int err = -ERESTARTSYS;
+
+   if (flags & MSG_DONTWAIT)
+   return -EAGAIN;
+
+   set_bit(SOCK_ASYNC_NOSPACE, >sk_socket->flags);
+
+   for (;;) {
+   if (signal_pending(current))
+   break;
+   prepare_to_wait(sk_sleep(sk), , TASK_INTERRUPTIBLE);
+   timeout = MAX_SCHEDULE_TIMEOUT;
+   if (sk_wait_event(sk, , aead_writable(sk))) {
+   err = 0;
+   break;
+   }
+   }
+   finish_wait(sk_sleep(sk), );
+
+   return err;
+}
+
+static void aead_wmem_wakeup(struct sock *sk)
+{
+   struct socket_wq *wq;
+
+   if (!aead_writable(sk))
+   return;
+
+   rcu_read_lock();
+   wq = rcu_dereference(sk->sk_wq);
+   if (wq_has_sleeper(wq))
+   wake_up_interruptible_sync_poll(>wait, POLLIN |
+  POLLRDNORM |
+  POLLRDBAND);
+   sk_wake_async(sk, SOCK_WAKE_WAITD, POLL_IN);
+   rcu_read_unlock();
+}
+
+static int aead_wait_for_data(struct sock *sk, unsigned flags)
+{
+   struct alg_sock *ask = alg_sk(sk);
+   struct aead_ctx *ctx = ask->private;
+ 

[PATCH v9 2/2] crypto: AF_ALG: enable AEAD interface compilation

[Stephan Mueller]

Enable compilation of the AEAD AF_ALG support and provide a Kconfig
option to compile the AEAD AF_ALG support.

Signed-off-by: Stephan Mueller 
---
 crypto/Kconfig  | 9 +
 crypto/Makefile | 1 +
 2 files changed, 10 insertions(+)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 50f4da4..41a3fc5 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1523,6 +1523,15 @@ config CRYPTO_USER_API_RNG
  This option enables the user-spaces interface for random
  number generator algorithms.
 
+config CRYPTO_USER_API_AEAD
+   tristate "User-space interface for AEAD cipher algorithms"
+   depends on NET
+   select CRYPTO_AEAD
+   select CRYPTO_USER_API
+   help
+ This option enables the user-spaces interface for AEAD
+ cipher algorithms.
+
 config CRYPTO_HASH_INFO
bool
 
diff --git a/crypto/Makefile b/crypto/Makefile
index ba19465..97b7d3a 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -100,6 +100,7 @@ obj-$(CONFIG_CRYPTO_USER_API) += af_alg.o
 obj-$(CONFIG_CRYPTO_USER_API_HASH) += algif_hash.o
 obj-$(CONFIG_CRYPTO_USER_API_SKCIPHER) += algif_skcipher.o
 obj-$(CONFIG_CRYPTO_USER_API_RNG) += algif_rng.o
+obj-$(CONFIG_CRYPTO_USER_API_AEAD) += algif_aead.o
 
 #
 # generic algorithms and the async_tx api
-- 
2.1.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/

Re: [PATCH 3.12 00/78] 3.12.36-stable review

[Satoru Takeuchi]

At Fri, 9 Jan 2015 09:59:10 -0800,
Guenter Roeck wrote:
> 
> On Fri, Jan 09, 2015 at 11:30:32AM +0100, Jiri Slaby wrote:
> > This is the start of the stable review cycle for the 3.12.36 release.
> > There are 78 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Tue Jan 13 11:29:45 CET 2015.
> > Anything received after that time might be too late.
> > 
> Build results:
>   total: 135 pass: 135 fail: 0
> Qemu tests:
>   total: 27 pass: 27 fail: 0
> 
> Details are available at http://server.roeck-us.net:8010/builders.
> 
> Guenter

Plus, this kernel passed my test.

 - Test Cases:
   - Build this kernel.
   - Boot this kernel.
   - Build the latest mainline kernel with this kernel.

 - Test Tool:
   https://github.com/satoru-takeuchi/test-linux-stable

 - Test Result (kernel .config, ktest config and test log):
   http://satoru-takeuchi.org/test-linux-stable/results/-.tar.xz

 - Build Environment:
   - OS: Debian Jessy x86_64
   - CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
   - memory: 8GB

 - Test Target Environment:
   - Debian Jessy x86_64 (KVM guest on the Build Environment)
   - # of vCPU: 2
   - memory: 2GB

Thanks,
Satoru
--
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/4] x86: open-code register save/restore in trace_hardirqs thunks

[Denys Vlasenko]

On Sat, Jan 10, 2015 at 11:41 PM, Borislav Petkov  wrote:
> On Sat, Jan 10, 2015 at 11:35:58PM +0100, Denys Vlasenko wrote:
>> I don't know either... it seems to be used after push_cfi
>> *sometimes*, not always:
>>
>> .macro op_safe_regs op
>> ENTRY(\op\()_safe_regs)
>> CFI_STARTPROC
>> pushl_cfi %ebx
>> pushl_cfi %ebp
>> pushl_cfi %esi
>> pushl_cfi %edi
>>
>> but
>>
>> ENTRY(csum_partial)
>> CFI_STARTPROC
>> pushl_cfi %esi
>> CFI_REL_OFFSET esi, 0
>> pushl_cfi %ebx
>> CFI_REL_OFFSET ebx, 0
>>
>> We need an expert to enlighten us.
>
> I think Andy had it:
>
> https://lkml.kernel.org/r/calcetruuj8t%2blp23uyezhvxatf-l_20doad4adxcie7xzqd...@mail.gmail.com
>
> So we better hide that crap in the macro at least, like the rest of the
> CFI gunk.

I understand Andy's post.
My question is, what about places like this?

> .macro op_safe_regs op
> ENTRY(\op\()_safe_regs)
> CFI_STARTPROC
> pushl_cfi %ebx
> pushl_cfi %ebp
> pushl_cfi %esi
> pushl_cfi %edi

Do we need to convert it to use macros which also do
"CFI_REL_OFFSET reg, 0" thingy, or not?
In either case: why?
--
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] MAINTAINERS: add git url entry for UIO

[Mandeep Sandhu]

Added git url for UIO section.

Signed-off-by: Mandeep Sandhu 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ddb9ac8..13fa3b7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10146,6 +10146,7 @@ USERSPACE I/O (UIO)
 M: "Hans J. Koch" 
 M: Greg Kroah-Hartman 
 S: Maintained
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
 F: Documentation/DocBook/uio-howto.tmpl
 F: drivers/uio/
 F: include/linux/uio*.h
-- 
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/

[PATCH v2] MAINTAINERS: add git url entry for UIO

[Mandeep Sandhu]

Added git url for UIO section.

Mandeep Sandhu (1):
  MAINTAINERS: add git url entry for UIO

 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

-- 
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/

[PATCH] staging: unisys: Convert direct LOGERR uses to pr_err

[Joe Perches]

Use the normal logging facility instead of a new macro.

Miscellanea:

o Realign arguments
o Remove unnecessary alloc error messages as alloc failures
  already emits a generic OOM message with a dump_stack
o Add missing newlines to these messages to avoid interleaving
o Spelling/typo fixes in those messages

Signed-off-by: Joe Perches 
---
 drivers/staging/unisys/include/uisutils.h  |   4 +-
 drivers/staging/unisys/uislib/uislib.c | 169 ++---
 drivers/staging/unisys/uislib/uisqueue.c   |   4 +-
 drivers/staging/unisys/uislib/uisthread.c  |   4 +-
 drivers/staging/unisys/uislib/uisutils.c   |  34 ++---
 drivers/staging/unisys/virthba/virthba.c   | 119 +++
 drivers/staging/unisys/virtpci/virtpci.c   |  71 +
 drivers/staging/unisys/visorchipset/file.c |   2 +-
 .../unisys/visorchipset/visorchipset_main.c| 159 ++-
 9 files changed, 276 insertions(+), 290 deletions(-)

diff --git a/drivers/staging/unisys/include/uisutils.h 
b/drivers/staging/unisys/include/uisutils.h
index 7414220..f937892 100644
--- a/drivers/staging/unisys/include/uisutils.h
+++ b/drivers/staging/unisys/include/uisutils.h
@@ -206,10 +206,10 @@ wait_for_valid_guid(uuid_le __iomem *guid)
  (void __iomem *)guid, sizeof(uuid_le));
if (uuid_le_cmp(tmpguid, NULL_UUID_LE) != 0)
break;
-   LOGERR("Waiting for non-0 GUID (why???)...\n");
+   pr_err("Waiting for non-0 GUID (why???)...\n");
UIS_THREAD_WAIT_SEC(5);
}
-   LOGERR("OK... GUID is non-0 now\n");
+   pr_err("OK... GUID is non-0 now\n");
 }
 
 /* CopyFragsInfoFromSkb returns the number of entries added to frags array
diff --git a/drivers/staging/unisys/uislib/uislib.c 
b/drivers/staging/unisys/uislib/uislib.c
index 7c87452..3050591 100644
--- a/drivers/staging/unisys/uislib/uislib.c
+++ b/drivers/staging/unisys/uislib/uislib.c
@@ -136,9 +136,9 @@ init_vbus_channel(u64 channelAddr, u32 channelBytes)
void __iomem *pChan = uislib_ioremap_cache(channelAddr, channelBytes);
 
if (!pChan) {
-   LOGERR("CONTROLVM_BUS_CREATE error: ioremap_cache of 
channelAddr:%Lx for channelBytes:%llu failed",
-(unsigned long long) channelAddr,
-(unsigned long long) channelBytes);
+   pr_err("CONTROLVM_BUS_CREATE error: ioremap_cache of 
channelAddr:%Lx for channelBytes:%llu failed\n",
+  (unsigned long long)channelAddr,
+  (unsigned long long)channelBytes);
rc = NULL;
goto Away;
}
@@ -161,8 +161,8 @@ create_bus(struct controlvm_message *msg, char *buf)
size_t size;
 
if (MaxBusCount == BusListCount) {
-   LOGERR("CONTROLVM_BUS_CREATE Failed: max buses:%d already 
created\n",
-MaxBusCount);
+   pr_err("CONTROLVM_BUS_CREATE Failed: max buses:%d already 
created\n",
+  MaxBusCount);
POSTCODE_LINUX_3(BUS_CREATE_FAILURE_PC, MaxBusCount,
 POSTCODE_SEVERITY_ERR);
return CONTROLVM_RESP_ERROR_MAX_BUSES;
@@ -179,7 +179,6 @@ create_bus(struct controlvm_message *msg, char *buf)
(deviceCount * sizeof(struct device_info *));
bus = kzalloc(size, GFP_ATOMIC);
if (!bus) {
-   LOGERR("CONTROLVM_BUS_CREATE Failed: kmalloc for bus 
failed.\n");
POSTCODE_LINUX_3(BUS_CREATE_FAILURE_PC, busNo,
 POSTCODE_SEVERITY_ERR);
return CONTROLVM_RESP_ERROR_KMALLOC_FAILED;
@@ -214,7 +213,7 @@ create_bus(struct controlvm_message *msg, char *buf)
/* found a bus already in the list with same busNo -
 * reject add
 */
-   LOGERR("CONTROLVM_BUS_CREATE Failed: bus %d already exists.\n",
+   pr_err("CONTROLVM_BUS_CREATE Failed: bus %d already exists\n",
   bus->bus_no);
POSTCODE_LINUX_3(BUS_CREATE_FAILURE_PC, bus->bus_no,
 POSTCODE_SEVERITY_ERR);
@@ -239,14 +238,14 @@ create_bus(struct controlvm_message *msg, char *buf)
cmd.add_vbus.bus_uuid = msg->cmd.create_bus.bus_data_type_uuid;
cmd.add_vbus.instance_uuid = msg->cmd.create_bus.bus_inst_uuid;
if (!virt_control_chan_func) {
-   LOGERR("CONTROLVM_BUS_CREATE Failed: virtpci callback 
not registered.");
+   pr_err("CONTROLVM_BUS_CREATE Failed: virtpci callback 
not registered\n");
POSTCODE_LINUX_3(BUS_CREATE_FAILURE_PC, bus->bus_no,
 POSTCODE_SEVERITY_ERR);
kfree(bus);
return CONTROLVM_RESP_ERROR_VIRTPCI_DRIVER_FAILURE;
   

Re: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)

[Eric W. Biederman]

Rich Felker  writes:

> On Sat, Jan 10, 2015 at 04:27:23PM -0600, Eric W. Biederman wrote:
>> Rich Felker  writes:
>> 
>> > On Sat, Jan 10, 2015 at 04:14:57AM +, Al Viro wrote:
>> 
>> >> Except that if your interpreter does stat(2) (or access(2), or 
>> >> getxattr(2),
>> >> etc.) before bothering with open(2), you'll get screwed.
>> >
>> > Yes, but I think that would be very bad interpreter design.
>> > stat/getxattr/access/whatever followed by open is always a TOCTOU
>> > race. The correct sequence of actions is always open followed by
>> > fstat/fgetxattr/...
>> 
>> Sigh.  I think everyone who has looked at this has been blind.
>> 
>> If userspace is reasonable all we have to do is fix /proc/self/exe
>> for shell scripts to point at the actual script,
>> and then pass /proc/self/exe on the shell scripts command line.
>> 
>> At a practical level we have to worry about backwards compability and
>> chroot jails.  But the existence of a clean implementation with
>> /proc/self/exe serves a proof of concept that it would not be too
>> difficult.  When someone cares enough to implement it.
>
> Is /proc/self/exe a "magic symlink" that's bound to the inode, or just
> a regular symlink? In the latter case it defeats the whole purpose of
> using O_EXEC fds and fexecve rather than pathnames.

In implementation /proc/self/exe is a named rather than a numbered file
descriptor.  Essentially when loading an elf executable the file
descriptor is duped to the name /proc/self/exe.  The implementation
otherwise is the same as /proc/self/fd/N.

The downside of course is that I expect if we were actually to change
/proc/self/exe from to point at the script instead of the shell some
piece of software somewhere would come melting down.  I am totally not
ready to consider that kind of mine field today.

Eric

--
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/

[GIT PULL] irqchip: Fixes for v3.19

[Jason Cooper]

Thomas,

Here's a round of fixes for v3.19.  Nothing too exciting or
controversial (other than I'm a bit behind due to the holidays and
such).

Please pull.

thx,

Jason.

The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:

  Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)

are available in the git repository at:

  git://git.infradead.org/users/jcooper/linux.git tags/irqchip-urgent-3.19

for you to fetch changes up to 91d1179212161f220938198b742c328ad38fd0a3:

  irqchip: atmel-aic-common: Prevent clobbering of priority when changing IRQ 
type (2015-01-07 12:41:45 +)


irqchip urgent fixes for v3.19-rcX

 - mtk-sysirq: Fix error handling
 - hip04: Fix cpu map for 16bit value
 - gic-v3-its: Clear a warning regarding decimal constants
 - omap-intc: Fix legacy DMA regression
 - atmel-aic-common: Retain priority when changing type


Felipe Balbi (1):
  irqchip: omap-intc: Fix legacy DMA regression

Gavin Li (1):
  irqchip: atmel-aic-common: Prevent clobbering of priority when changing 
IRQ type

Wang Long (1):
  irqchip: hip04: Initialize hip04_cpu_map to 0x

Will Deacon (1):
  irqchip: gic-v3-its: Fix use of max with decimal constant

Yingjoe Chen (1):
  irqchip: mtk-sysirq: Use IS_ERR() instead of NULL pointer check

 drivers/irqchip/irq-atmel-aic-common.c |  4 ++--
 drivers/irqchip/irq-gic-v3-its.c   |  2 +-
 drivers/irqchip/irq-hip04.c|  2 +-
 drivers/irqchip/irq-mtk-sysirq.c   |  4 ++--
 drivers/irqchip/irq-omap-intc.c| 26 +-
 5 files changed, 27 insertions(+), 11 deletions(-)
--
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] avr32: remove fake at91 cpu identification

[Alexandre Belloni]

cpu_is_at91* are not used in any driver outside mach-at91. Remove those useless
definitions.

Signed-off-by: Alexandre Belloni 
---

Hans-Christian,

If you want, I guess that one could go through the at91 tree. Unless you have
more material and you want to do a pull request for 3.20.

Regards,

 arch/avr32/mach-at32ap/include/mach/cpu.h | 26 +-
 1 file changed, 1 insertion(+), 25 deletions(-)

diff --git a/arch/avr32/mach-at32ap/include/mach/cpu.h 
b/arch/avr32/mach-at32ap/include/mach/cpu.h
index 16a24b14146c..4181086f4ddc 100644
--- a/arch/avr32/mach-at32ap/include/mach/cpu.h
+++ b/arch/avr32/mach-at32ap/include/mach/cpu.h
@@ -1,5 +1,5 @@
 /*
- * AVR32 and (fake) AT91 CPU identification
+ * AVR32 CPU identification
  *
  * Copyright (C) 2007 Atmel Corporation
  *
@@ -20,28 +20,4 @@
 # define cpu_is_at32ap7000()   (0)
 #endif
 
-/*
- * Since this is AVR32, we will never run on any AT91 CPU. But these
- * definitions may reduce clutter in common drivers.
- */
-#define cpu_is_at91rm9200()(0)
-#define cpu_is_at91sam9xe()(0)
-#define cpu_is_at91sam9260()   (0)
-#define cpu_is_at91sam9261()   (0)
-#define cpu_is_at91sam9263()   (0)
-#define cpu_is_at91sam9rl()(0)
-#define cpu_is_at91sam9g10()   (0)
-#define cpu_is_at91sam9g20()   (0)
-#define cpu_is_at91sam9g45()   (0)
-#define cpu_is_at91sam9g45es() (0)
-#define cpu_is_at91sam9m10()   (0)
-#define cpu_is_at91sam9g46()   (0)
-#define cpu_is_at91sam9m11()   (0)
-#define cpu_is_at91sam9x5()(0)
-#define cpu_is_at91sam9g15()   (0)
-#define cpu_is_at91sam9g35()   (0)
-#define cpu_is_at91sam9x35()   (0)
-#define cpu_is_at91sam9g25()   (0)
-#define cpu_is_at91sam9x25()   (0)
-
 #endif /* __ASM_ARCH_CPU_H */
-- 
2.1.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/

Re: [PATCH 2/2] platform/x86: Add Intel Galileo platform specific setup

[Bryan O'Donoghue]

I'm wondering if there is a need for this to be a platform driver at
all. Could we, instead, tear down any unlocked IMRs at boot as part of the IMR
driver itself, as well as lock the kernel .text. Firmware has the option of
making an IMR mandatory by locking it. If it isn't locked, what use is it to the
OS without a lot more context? Any sort of policy enforced with IMRs is a
user-space decision, so clearing out the unlocked ones and then handing off to
user-space seems like a sane default mode to me.

I discussed this with Boon Leong this afternoon and we couldn't come up with a
justification for a platform-specific driver to do what this does.


I think there's no technical reason impeding what you've just suggested 
in the IMR init and I'm happy to move the code in there since basically 
any platform with IMR registers could justifiably


a) Tear down everything that's unlocked
b) Place a default IMR around the .text section

No reason it the world that that policy needs to be Galileo specific - 
and it's a valid argument to say - this behaviour can simply be an IMR 
policy in the kernel and less code for the same functionality, that adds 
consistency across x86 is a good thing.


I'll zap the Galileo platform code entirely for V2 unless there's a 
counter-argument from someone.


--
BOD

--
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: /proc/net/dev regression

[Al Viro]

On Sun, Jan 11, 2015 at 01:33:35AM +, Carlos R. Mafra wrote:

> I think the problem with wmnet is not that it was expecting the fields
> to be aligned because it never had problems before (when definitely more
> than 10 megabytes were received, wmnet is crappy but not _that_ crappy).
> 
> I think the problem really was here,
> 
>   totalbytes_in = strtoul([7], NULL, 10);
> 
> After the patch the device name is 8 characters long and [7]
> overlaps with the name instead of reading the bytes. Before the
> patch is was fine because the call to strtoul() seems correct in the
> sense that it would read everything until the NULL. So more than 10
> megabytes was still ok.
> 
> So I guess I was wrong when suggesting that the problem was the
> alignment.

Several lines below there's this:
totalpackets_out = strtoul([74], NULL, 10);
if (totalpackets_out != lastpackets_out) {
totalbytes_out = strtoul([66], NULL, 10);
diffpackets_out += totalpackets_out - 
lastpackets_out;
diffbytes_out += totalbytes_out - lastbytes_out;
lastpackets_out = totalpackets_out;
lastbytes_out = totalbytes_out;
tx = True;
}

So I'm afraid it *is* that crappy.  This function really should use scanf();
note that updateStats_ipchains() in the same file does just that (well,
fgets()+sscanf() for fsck knows what reason).  And I'd be careful with all
those %d, actually - it's not _that_ hard to get more than 4Gb sent.
scanf formats really ought to match the kernel-side (seq_)printf one...
--
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: [PATCHv3] hwmon: (ina2xx) implement update_interval attribute for ina226

[Guenter Roeck]

On 01/09/2015 08:03 AM, Bartosz Golaszewski wrote:

This attribute allows to configure the update interval of ina226. Although
the bus and shunt voltage conversion times remain hardcoded to 1.1 ms, we can
now modify said interval by changing the averaging rate.

While we're at it - add an additional variable to ina2xx_data, which holds
the current configuration settings - this way we'll be able to restore the
configuration in case of an unexpected chip reset.

Signed-off-by: Bartosz Golaszewski 


Applied to -next.

Thanks,
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: /proc/net/dev regression

[Carlos R. Mafra]

On Sun, 11 Jan 2015 at  1:00:36 +, Al Viro wrote:
> On Sun, Jan 11, 2015 at 12:27:06AM +, Al Viro wrote:
> > On Sat, Jan 10, 2015 at 11:25:18PM +, Carlos R. Mafra wrote:
> > > [mafra@linux-g29b:wmnet]$ cat net_dev_bad.txt
> > > Inter-|   Receive|  
> > > Transmit
> > >  face |bytespackets errs drop fifo frame compressed multicast|bytes   
> > >  packets errs drop fifo colls carrier compressed
> > > lo: 600   8000 0  0 0  
> > > 600   8000 0   0  0
> > > wlp3s0b1: 92668487298000 0  0 0   
> > > 3722294030000 0   0  0
> > > 
> > > And for some reason this change confuses 'wmnet'. Reading the source code
> > > of 'wmnet' I found that it reads the packets as follows,
> > > 
> > >   totalpackets_in = strtoul([15], NULL, 10);
> > > 
> > > I am not sure if 'wmnet' could do this better (any suggestions?),
> > 
> > *snort*
> > 
> > well, yes - it's called scanf().  And if one is really, really nervous
> > about the overhead of  parsing a bunch of integers (as if fopen/
> > fgets/fclose alone won't cost enough to make constantly calling that
> > sucker a bad idea), just use ptr +  - 6 instead of
> > [] in there.  That thing has just found where the
> > colon was (and replaced it with NUL), so dealing with "the first field
> > turned out to be too long and shifted everything past it" isn't hard.
> > 
> > > but the fact is that it was working before and now it is not.
> > 
> > True.  Mind you, the real issue is that this code expects the interface
> > names to be never longer than 6 characters, but then /proc/net/dev layout
> > strongly suggests that.  Hell knows; it is a regression and it does
> > break real-world userland code.  The only way to avoid that, AFAICS, is
> > to prohibit interface names longer than 6 chars ;-/
> > 
> > Lovely combination of crappy ABI (procfs file layout), crappy userland
> > code relying on details of said ABI out of sheer laziness and triggering
> > kernel change producing bloody long interface names...
> > 
> > Incidentally, sufficiently long interface name will produce other fun issues
> > for a docked app - it simply won't fit into 64x64 square on screen ;-)
> 
> Mind you, assuming that columns will align is obviously broken - the producing
> side of that thing is
> seq_printf(seq, "%6s: %7llu %7llu %4llu %4llu %4llu %5llu %10llu 
> %9llu "
>"%8llu %7llu %4llu %4llu %4llu %5llu %7llu %10llu\n",
>dev->name, stats->rx_bytes, stats->rx_packets,
>stats->rx_errors,
>stats->rx_dropped + stats->rx_missed_errors,
>stats->rx_fifo_errors,
>stats->rx_length_errors + stats->rx_over_errors +
> stats->rx_crc_errors + stats->rx_frame_errors,
>stats->rx_compressed, stats->multicast,
>stats->tx_bytes, stats->tx_packets,
>stats->tx_errors, stats->tx_dropped,
>stats->tx_fifo_errors, stats->collisions,
>stats->tx_carrier_errors +
> stats->tx_aborted_errors +
> stats->tx_window_errors +
> stats->tx_heartbeat_errors,
>stats->tx_compressed);
> To start with, expecting the ->rx_bytes to remain a 7-digit number is 
> somewhat,
> er, odd.  Long interace names be damned, the columns will not stay aligned,
> no matter what.  Unless your interface vanishes as soon as it has sent
> or received 10 megabytes, that is...

I think the problem with wmnet is not that it was expecting the fields
to be aligned because it never had problems before (when definitely more
than 10 megabytes were received, wmnet is crappy but not _that_ crappy).

I think the problem really was here,

totalbytes_in = strtoul([7], NULL, 10);

After the patch the device name is 8 characters long and [7]
overlaps with the name instead of reading the bytes. Before the
patch is was fine because the call to strtoul() seems correct in the
sense that it would read everything until the NULL. So more than 10
megabytes was still ok.

So I guess I was wrong when suggesting that the problem was the
alignment.
--
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: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)

[Rich Felker]

On Sat, Jan 10, 2015 at 04:27:23PM -0600, Eric W. Biederman wrote:
> Rich Felker  writes:
> 
> > On Sat, Jan 10, 2015 at 04:14:57AM +, Al Viro wrote:
> 
> >> Except that if your interpreter does stat(2) (or access(2), or getxattr(2),
> >> etc.) before bothering with open(2), you'll get screwed.
> >
> > Yes, but I think that would be very bad interpreter design.
> > stat/getxattr/access/whatever followed by open is always a TOCTOU
> > race. The correct sequence of actions is always open followed by
> > fstat/fgetxattr/...
> 
> Sigh.  I think everyone who has looked at this has been blind.
> 
> If userspace is reasonable all we have to do is fix /proc/self/exe
> for shell scripts to point at the actual script,
> and then pass /proc/self/exe on the shell scripts command line.
> 
> At a practical level we have to worry about backwards compability and
> chroot jails.  But the existence of a clean implementation with
> /proc/self/exe serves a proof of concept that it would not be too
> difficult.  When someone cares enough to implement it.

Is /proc/self/exe a "magic symlink" that's bound to the inode, or just
a regular symlink? In the latter case it defeats the whole purpose of
using O_EXEC fds and fexecve rather than pathnames.

Rich
--
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 3/8] watchdog: at91rm9200: use the regmap from mfd

[Guenter Roeck]

On 01/10/2015 10:41 AM, Alexandre Belloni wrote:

On 09/01/2015 at 16:39:21 -0800, Guenter Roeck wrote :

On 01/09/2015 01:51 AM, Alexandre Belloni wrote:

  /* . 
*/
@@ -204,6 +201,7 @@ static struct miscdevice at91wdt_miscdev = {
  static int at91wdt_probe(struct platform_device *pdev)
  {
int res;
+   regmap_st = dev_get_drvdata(pdev->dev.parent);



Is it guaranteed that parent is never NULL, and that the parent's
drvdata is always set ?



The only way to probe the driver left is to use platform_data. It is
done from the MFD driver. If you prefer, I can test for NULL here and
return.



I am fine if you are sure about that. The problem though is still the
check for double instantiation. Either the driver can not be instantiated
multiple times, and the check is no longer necessary, or it can, meaning
there must be some other means to instantiate it besides through the
mfd driver. And in that case you don't necessarily know if platform_data
is set.


Also, it seems that regmap_st will be overwritten if the device
is already open (see code below). That may not be a good idea.



I'm not sure what you meani, pdev->dev.parent and at91wdt_miscdev.parent
are not the same thing. I didn't touch the code below but I believe
there is no reason to pass in the probe twice and return -EBUSY.



Not sure I understand what my comment has to do with 'parent'.

The fact that the code checks if it has already been instantiated
suggests that the original author of the driver was concerned about
that case. Since you did not remove that check I have to assume that
this can still happen. If so, the second instantiation attempt will
overwrite regmap_st, since that variable is written prior to checking
for the dual instantiation.

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: /proc/net/dev regression

[Al Viro]

On Sun, Jan 11, 2015 at 12:27:06AM +, Al Viro wrote:
> On Sat, Jan 10, 2015 at 11:25:18PM +, Carlos R. Mafra wrote:
> > [mafra@linux-g29b:wmnet]$ cat net_dev_bad.txt
> > Inter-|   Receive|  Transmit
> >  face |bytespackets errs drop fifo frame compressed multicast|bytes
> > packets errs drop fifo colls carrier compressed
> > lo: 600   8000 0  0 0  600  
> >  8000 0   0  0
> > wlp3s0b1: 92668487298000 0  0 0   
> > 3722294030000 0   0  0
> > 
> > And for some reason this change confuses 'wmnet'. Reading the source code
> > of 'wmnet' I found that it reads the packets as follows,
> > 
> > totalpackets_in = strtoul([15], NULL, 10);
> > 
> > I am not sure if 'wmnet' could do this better (any suggestions?),
> 
> *snort*
> 
> well, yes - it's called scanf().  And if one is really, really nervous
> about the overhead of  parsing a bunch of integers (as if fopen/
> fgets/fclose alone won't cost enough to make constantly calling that
> sucker a bad idea), just use ptr +  - 6 instead of
> [] in there.  That thing has just found where the
> colon was (and replaced it with NUL), so dealing with "the first field
> turned out to be too long and shifted everything past it" isn't hard.
> 
> > but the fact is that it was working before and now it is not.
> 
> True.  Mind you, the real issue is that this code expects the interface
> names to be never longer than 6 characters, but then /proc/net/dev layout
> strongly suggests that.  Hell knows; it is a regression and it does
> break real-world userland code.  The only way to avoid that, AFAICS, is
> to prohibit interface names longer than 6 chars ;-/
> 
> Lovely combination of crappy ABI (procfs file layout), crappy userland
> code relying on details of said ABI out of sheer laziness and triggering
> kernel change producing bloody long interface names...
> 
> Incidentally, sufficiently long interface name will produce other fun issues
> for a docked app - it simply won't fit into 64x64 square on screen ;-)

Mind you, assuming that columns will align is obviously broken - the producing
side of that thing is
seq_printf(seq, "%6s: %7llu %7llu %4llu %4llu %4llu %5llu %10llu %9llu "
   "%8llu %7llu %4llu %4llu %4llu %5llu %7llu %10llu\n",
   dev->name, stats->rx_bytes, stats->rx_packets,
   stats->rx_errors,
   stats->rx_dropped + stats->rx_missed_errors,
   stats->rx_fifo_errors,
   stats->rx_length_errors + stats->rx_over_errors +
stats->rx_crc_errors + stats->rx_frame_errors,
   stats->rx_compressed, stats->multicast,
   stats->tx_bytes, stats->tx_packets,
   stats->tx_errors, stats->tx_dropped,
   stats->tx_fifo_errors, stats->collisions,
   stats->tx_carrier_errors +
stats->tx_aborted_errors +
stats->tx_window_errors +
stats->tx_heartbeat_errors,
   stats->tx_compressed);
To start with, expecting the ->rx_bytes to remain a 7-digit number is somewhat,
er, odd.  Long interace names be damned, the columns will not stay aligned,
no matter what.  Unless your interface vanishes as soon as it has sent
or received 10 megabytes, that is...
--
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: /proc/net/dev regression

[Carlos R. Mafra]

On Sun, 11 Jan 2015 at  0:27:06 +, Al Viro wrote:
> On Sat, Jan 10, 2015 at 11:25:18PM +, Carlos R. Mafra wrote:
> > [mafra@linux-g29b:wmnet]$ cat net_dev_bad.txt
> > Inter-|   Receive|  Transmit
> >  face |bytespackets errs drop fifo frame compressed multicast|bytes
> > packets errs drop fifo colls carrier compressed
> > lo: 600   8000 0  0 0  600  
> >  8000 0   0  0
> > wlp3s0b1: 92668487298000 0  0 0   
> > 3722294030000 0   0  0
> > 
> > And for some reason this change confuses 'wmnet'. Reading the source code
> > of 'wmnet' I found that it reads the packets as follows,
> > 
> > totalpackets_in = strtoul([15], NULL, 10);
> > 
> > I am not sure if 'wmnet' could do this better (any suggestions?),
> 
> *snort*
> 
> well, yes - it's called scanf().  And if one is really, really nervous
> about the overhead of  parsing a bunch of integers (as if fopen/
> fgets/fclose alone won't cost enough to make constantly calling that
> sucker a bad idea), just use ptr +  - 6 instead of
> [] in there.  That thing has just found where the
> colon was (and replaced it with NUL), so dealing with "the first field
> turned out to be too long and shifted everything past it" isn't hard.

Alright! Thank you.

> > but the fact is that it was working before and now it is not.
> 
> True.  Mind you, the real issue is that this code expects the interface
> names to be never longer than 6 characters, but then /proc/net/dev layout
> strongly suggests that.  Hell knows; it is a regression and it does
> break real-world userland code.  The only way to avoid that, AFAICS, is
> to prohibit interface names longer than 6 chars ;-/
> 
> Lovely combination of crappy ABI (procfs file layout), crappy userland
> code relying on details of said ABI out of sheer laziness and triggering
> kernel change producing bloody long interface names...

I won't mind just changing the crappy and fragile wmnet code and moving on.
I have already lost the 2 hours bisecting this anyway.

Thank you very much for your advice.

--
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/

[RESEND PATCH v2 2/2] usb: serial: handle -ENODEV quietly in generic_submit_read_urb

[Jeremiah Mahler]

If a USB serial device (e.g. /dev/ttyUSB0) with an active program is
unplugged, an -ENODEV (19) error will be produced after it gives up
trying to resubmit a read.

  usb_serial_generic_submit_read_urb - usb_submit_urb failed: -19

Add -ENODEV as one of the permanent errors along with -EPERM that
usb_serial_generic_submit_read_urb() handles quietly without an error.

Signed-off-by: Jeremiah Mahler 
---
 drivers/usb/serial/generic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/serial/generic.c b/drivers/usb/serial/generic.c
index 2d7207b..ccf1df7 100644
--- a/drivers/usb/serial/generic.c
+++ b/drivers/usb/serial/generic.c
@@ -286,7 +286,7 @@ static int usb_serial_generic_submit_read_urb(struct 
usb_serial_port *port,
 
res = usb_submit_urb(port->read_urbs[index], mem_flags);
if (res) {
-   if (res != -EPERM) {
+   if (res != -EPERM && res != -ENODEV) {
dev_err(>dev,
"%s - usb_submit_urb failed: %d\n",
__func__, res);
-- 
2.1.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/

[RESEND PATCH v2 1/2] usb: serial: handle -EPROTO quietly in generic_read_bulk

[Jeremiah Mahler]

If a USB serial device is unplugged while there is an active program
using the device it will spam the logs with -EPROTO (71) messages as it
attempts to retry.

Most serial usb drivers (metro-usb, pl2303, mos7840, ...) only output
these messages for debugging.  The generic driver treats these as
errors.

Change the default output for the generic serial driver from error to
debug.

Signed-off-by: Jeremiah Mahler 
---
 drivers/usb/serial/generic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/serial/generic.c b/drivers/usb/serial/generic.c
index 1bd1922..2d7207b 100644
--- a/drivers/usb/serial/generic.c
+++ b/drivers/usb/serial/generic.c
@@ -373,7 +373,7 @@ void usb_serial_generic_read_bulk_callback(struct urb *urb)
__func__, urb->status);
return;
default:
-   dev_err(>dev, "%s - nonzero urb status: %d\n",
+   dev_dbg(>dev, "%s - nonzero urb status: %d\n",
__func__, urb->status);
goto resubmit;
}
-- 
2.1.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/

[RESEND PATCH v2 0/2] usb: serial: handle -ENODEV and -EPROTO quietly

[Jeremiah Mahler]

(Jan 15) Just a resend of v2 [1].

  [1]: https://lkml.org/lkml/2014/12/20/16

If a USB serial device (e.g. /dev/ttyUSB0) with an active program is
unplugged, a bunch of -ENODEV and -EPROTO errors will be produced in the
logs.  This patch set quiets these messages without changing the
original behavior.

This change is beneficial when using daemons such as slcand, which is
similar to pppd or slip, that cannot determine whether they should exit
until after the USB serial device is unplugged.  Producing these error
messages for a normal use case is not helpful.

Jeremiah Mahler (2):
  usb: serial: handle -EPROTO quietly in generic_read_bulk
  usb: serial: handle -ENODEV quietly in generic_submit_read_urb

 drivers/usb/serial/generic.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
2.1.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: /proc/net/dev regression

[Al Viro]

On Sat, Jan 10, 2015 at 11:25:18PM +, Carlos R. Mafra wrote:
> [mafra@linux-g29b:wmnet]$ cat net_dev_bad.txt
> Inter-|   Receive|  Transmit
>  face |bytespackets errs drop fifo frame compressed multicast|bytes
> packets errs drop fifo colls carrier compressed
> lo: 600   8000 0  0 0  600
>8000 0   0  0
> wlp3s0b1: 92668487298000 0  0 0   372229  
>   4030000 0   0  0
> 
> And for some reason this change confuses 'wmnet'. Reading the source code
> of 'wmnet' I found that it reads the packets as follows,
> 
>   totalpackets_in = strtoul([15], NULL, 10);
> 
> I am not sure if 'wmnet' could do this better (any suggestions?),

*snort*

well, yes - it's called scanf().  And if one is really, really nervous
about the overhead of  parsing a bunch of integers (as if fopen/
fgets/fclose alone won't cost enough to make constantly calling that
sucker a bad idea), just use ptr +  - 6 instead of
[] in there.  That thing has just found where the
colon was (and replaced it with NUL), so dealing with "the first field
turned out to be too long and shifted everything past it" isn't hard.

> but the fact is that it was working before and now it is not.

True.  Mind you, the real issue is that this code expects the interface
names to be never longer than 6 characters, but then /proc/net/dev layout
strongly suggests that.  Hell knows; it is a regression and it does
break real-world userland code.  The only way to avoid that, AFAICS, is
to prohibit interface names longer than 6 chars ;-/

Lovely combination of crappy ABI (procfs file layout), crappy userland
code relying on details of said ABI out of sheer laziness and triggering
kernel change producing bloody long interface names...

Incidentally, sufficiently long interface name will produce other fun issues
for a docked app - it simply won't fit into 64x64 square on screen ;-)
--
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/

[3.2-stable] Suspend regression after "x86, mm: Set NX across entire PMD at boot"

[Ben Hutchings]

Commit 45e2a9d4701d8c624d4a4bcdd1084eae31e92f58 ("x86, mm: Set NX across
entire PMD at boot") has been backported to many stable branches:

v3.10.62: 0b15c16c4f4a x86, mm: Set NX across entire PMD at boot
v3.12.35: 868b19cb0314 x86, mm: Set NX across entire PMD at boot
v3.14.26: 1a829c59816e x86, mm: Set NX across entire PMD at boot
v3.17.5: 6231385167e0 x86, mm: Set NX across entire PMD at boot
v3.2.65: a5c187d92d2c x86, mm: Set NX across entire PMD at boot
v3.13.11-ckt12: 3657489f7009 x86, mm: Set NX across entire PMD at boot
v3.16.7-ckt3: de32229b546e x86, mm: Set NX across entire PMD at boot

Unfortunately, in 3.2.65 suspend/resume stopped working on at least some
systems - specifically, the system would reboot when woken:

https://bugs.debian.org/774436 - Lenovo ThinkPad T530
https://bugs.debian.org/774461 - Lenovo ThinkPad X230
https://bugs.debian.org/774526 - ECS P4M900T-M2
https://bugs.debian.org/775059 - ASUS X201EP

I could reproduce this on my own ASUS P8Z68-V LX and was able to bisect
to the backport of this commit.

Assuming that this regression has not occurred on mainline or the other
branches, I will revert this patch for 3.2.y unless someone can point
out a missing dependency that I should apply.

Ben.

-- 
Ben Hutchings
One of the nice things about standards is that there are so many of them.


signature.asc
Description: This is a digitally signed message part

Re: Bug#757733: RTS2557 SD card reader does not work

[Johannes Schauer]

Hi,

On Mon, 11 Aug 2014 06:45:24 +  wrote:
> Would you please try this patch. If it does work, we will submit it to 
> upstream kernel.

I own a Lenovo Thinkpad T440s as well just as the original bug submitter
(Philipp) and that patch by Wei does not fix the problem for me (I applied it
to a 3.18 tree).

What does work is to follow Philipp's instructions to patch the out-of-tree
driver from realtek.com.tw. That module then gives me my SD card as /dev/sdbX.

Weirdly, my SD card reader used to work (but presented the SD card as
/dev/mmcblk0pX). I do not know why it stopped working though as I didn't reboot
my laptop for several months. Running an older kernel version (3.14 for
example) does not fix the problem. Maybe it is related to other parts of my
(Debian testing) OS. I'll see if I can find a Debian unstable snapshot that
restores the behaviour I observed last year and try to bisect to find the
source of the regression.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: [PATCH] arch/x86/kernel/cpu/common.c: split log entry into logical components

[Borislav Petkov]

On Sat, Jan 10, 2015 at 11:57:04PM +, Scot Doyle wrote:
> Steven, are you planning to resubmit the patch as suggested by Borislav?

I think he did resubmit:

https://lkml.kernel.org/r/1415227938-16927-1-git-send-email-stevenhoney...@gmail.com

but it seems it has been forgotten. I'll pick it up.

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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] arch/x86/kernel/cpu/common.c: split log entry into logical components

[Scot Doyle]

On Sat, 10 Jan 2015, Joe Perches wrote:

> On Sat, 2015-01-10 at 22:21 +, Scot Doyle wrote:
> > Call printk twice since this log entry has two lines and headings.
> > 
> > [0.009285] Last level iTLB entries: 4KB 1024, 2MB 1024, 4MB 1024
> > Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 1024, 1GB 4
> > 
> > Signed-off-by: Scot Doyle 
> > ---
> >  arch/x86/kernel/cpu/common.c | 10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> > index c604965..76f253f 100644
> > --- a/arch/x86/kernel/cpu/common.c
> > +++ b/arch/x86/kernel/cpu/common.c
> > @@ -496,12 +496,12 @@ void cpu_detect_tlb(struct cpuinfo_x86 *c)
> > if (this_cpu->c_detect_tlb)
> > this_cpu->c_detect_tlb(c);
> >  
> > -   printk(KERN_INFO "Last level iTLB entries: 4KB %d, 2MB %d, 4MB %d\n"
> > -   "Last level dTLB entries: 4KB %d, 2MB %d, 4MB %d, 1GB %d\n",
> > +   printk(KERN_INFO "Last level iTLB entries: 4KB %d, 2MB %d, 4MB %d\n",
> > tlb_lli_4k[ENTRIES], tlb_lli_2m[ENTRIES],
> > -   tlb_lli_4m[ENTRIES], tlb_lld_4k[ENTRIES],
> > -   tlb_lld_2m[ENTRIES], tlb_lld_4m[ENTRIES],
> > -   tlb_lld_1g[ENTRIES]);
> > +   tlb_lli_4m[ENTRIES]);
> > +   printk(KERN_INFO "Last level dTLB entries: 4KB %d, 2MB %d, 4MB %d, 1GB 
> > %d\n",
> > +   tlb_lld_4k[ENTRIES], tlb_lld_2m[ENTRIES],
> > +   tlb_lld_4m[ENTRIES], tlb_lld_1g[ENTRIES]);
> >  }
> 
> Check your dmesg version
> 
> https://lkml.org/lkml/2014/11/1/67
> https://lkml.org/lkml/2014/11/2/1
> 

Thanks Joe.

Steven, are you planning to resubmit the patch as suggested by Borislav?
--
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 v7 3/5] usb: dwc2: add generic PHY framework support for dwc2 usb controler platform driver.

[Paul Zimmerman]

> From: Yunzhi Li [mailto:l...@rock-chips.com]
> Sent: Saturday, January 10, 2015 8:07 AM
> 
> 在 2015/1/9 10:15, Paul Zimmerman 写道:
> >> [...]
> >>/*
> >> -   * Attempt to find a generic PHY, then look for an old style
> >> -   * USB PHY, finally fall back to pdata
> >> +   * If platform probe couldn't find a generic PHY or an old style
> >> +   * USB PHY, fall back to pdata
> >> */
> >> -  phy = devm_phy_get(dev, "usb2-phy");
> >> -  if (IS_ERR(phy)) {
> >> -  uphy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
> >> -  if (IS_ERR(uphy)) {
> >> -  /* Fallback for pdata */
> >> -  plat = dev_get_platdata(dev);
> >> -  if (!plat) {
> >> -  dev_err(dev,
> >> -  "no platform data or transceiver defined\n");
> >> -  return -EPROBE_DEFER;
> >> -  }
> >> -  hsotg->plat = plat;
> >> -  } else
> >> -  hsotg->uphy = uphy;
> >> -  } else {
> >> -  hsotg->phy = phy;
> >> +  if (IS_ERR_OR_NULL(hsotg->phy) && IS_ERR_OR_NULL(hsotg->uphy)) {
> >> +  plat = dev_get_platdata(dev);
> >> +  if (!plat) {
> >> +  dev_err(dev,
> >> +  "no platform data or transceiver defined\n");
> >> +  return -EPROBE_DEFER;
> > Hi Yunzhi,
> >
> > Testing Felipe's testing/next branch on an Altera SOCFPGA platform,
> > the driver never loads because it always returns -EPROBE_DEFER here.
> > Apparently the SOCFPGA platform does not have any platform data
> > defined, because dev_get_platdata() always returns NULL.
> >
> > If I remove the -EPROBE_DEFER return and have it continue on, the
> > driver works. Reverting the patch also makes it work.
>  When I debug this problem, I checked socfpga.dtsi, there is a
> usbphy node defined for each
> dwc2 controller, so I think when running dwc2_driver_probe() uphy =
> devm_usb_get_phy()
> should get a valid usbphy pointer and hsotg->uphy will not be NULL or
> ERROR, then in dwc2_gadget_init()
> it will not return -EPROBE_DEFER. I have no idea about why you meet
> -EPROBE_DEFER, could you please tell
> me what's the return value of devm_usb_get_phy() on your socfpga board ?

I'm away from the hardware right now, but I just found this in a saved
boot log:

[1.097268] usb_phy_generic soc:usbphy@0: Error requesting RESET GPIO
[1.097285] usb_phy_generic: probe of soc:usbphy@0 failed with error -2

So that probably explains it. I'll dig into this some more on Monday.

-- 
Paul

Re: [PATCH 2/4] x86: ia32entry.S: fix wrong symbolic constant usage: R11->ARGOFFSET

[Andy Lutomirski]

On Sat, Jan 10, 2015 at 2:27 PM, Linus Torvalds
 wrote:
> On Sat, Jan 10, 2015 at 2:13 PM, Andy Lutomirski  wrote:
>>
>> I'll make the same change to my pending entry work, and hopefully we
>> can avoid conflicts.
>
> That's not how conflicts work.
>
> Either there is no overlap between the changes at all, in which case
> it doesn't matter if you then also have Denys' changes in your tree.
>
> Or you have other changes that change code around Denys' code, in
> which case you'll get conflicts whether you have Denys' changes or not
> (because two branches will be changing the same area differently, and
> so there's a conflict that needs to resolve which side was right).
>
> So the only way to avoid a conflict is to not touch the same code, or
> to touch it *exactly* the same way in all respects.
>
> Now, while the *conflict* is not something you can't avoid, some
> conflicts are easier to resolve than others, and from a conflict
> resolution standpoint it can make sense for your branch to include
> Denys' changes.

Hmm.  What I meant here about avoiding conflicts was more like "with
any luck, the timing will work out such that the code conflicts don't
end up happening."

>
> Why? Because if whoever resolves the conflict sees that one branch is
> a proper superset of the other branch, than the resolution is a much
> more obvious "let's just take everything from one side" edit, rather
> than having to pick-and-choose.
>
> I I do actually agree with you taking the fixes (and maybe you should
> *entirely* take ownership of all the entry_64.S changes, so that there
> is no "other side" to conflict with at all!). I just wanted to point
> out the actual effects from a conflict standpoint.
>

Egads.  As if the vdso isn't bad enough.

Mumble mumble maybe I'll agree to maintain this masterpiece of
well-engineered asm.

--Andy

>   Linus



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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/

/proc/net/dev regression

[Carlos R. Mafra]

I use a dockapp called 'wmnet' [1] to monitor the speed of
my internet connection and after the kernel v3.18 it does no
longer work properly (it still doesn't work in v3.19-rc3)

I bisected the problem and the culprit is this commit:

commit 6e094bd805a9b6ad2f5421125db8f604a166616c
Author: Rafał Miłecki 
Date:   Fri Sep 5 00:18:48 2014 +0200

bcma: move code for core registration into separate function

This cleans code a bit and will us to register cores in other places as
well. The only difference with this patch is using "core_index" for
setting device name.


The problem is caused by the different name that my wireless connection
receives after this patch:

wlp3s0b1 (after the patch)
wlp3s0   (before the patch)

because it affects the display of information in the file /proc/net/dev.

Before the patch the fields are all aligned:

[mafra@linux-g29b:wmnet]$ cat net_dev_good.txt
Inter-|   Receive|  Transmit
 face |bytespackets errs drop fifo frame compressed multicast|bytes
packets errs drop fifo colls carrier compressed
lo:   35916 332000 0  0 035916 
332000 0   0  0
wlp3s0: 64064285794000 0  0 0   426813
3778000 0   0  0

but after the patch the fields are misaligned:

[mafra@linux-g29b:wmnet]$ cat net_dev_bad.txt
Inter-|   Receive|  Transmit
 face |bytespackets errs drop fifo frame compressed multicast|bytes
packets errs drop fifo colls carrier compressed
lo: 600   8000 0  0 0  600  
 8000 0   0  0
wlp3s0b1: 92668487298000 0  0 0   372229
4030000 0   0  0

And for some reason this change confuses 'wmnet'. Reading the source code
of 'wmnet' I found that it reads the packets as follows,

totalpackets_in = strtoul([15], NULL, 10);

I am not sure if 'wmnet' could do this better (any suggestions?),
but the fact is that it was working before and now it is not.

Any help is greatly appreciated.

[1] wmnet can be found in http://repo.or.cz/w/dockapps.git
--
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: Getting new udev to run with 2.6.28

[Al Viro]

On Sat, Jan 10, 2015 at 11:25:39PM +0100, Martin Steigerwald wrote:

> > ... and this, boys and girls, is why quite a few of us have loathed udev
> > way before it got merged into even nastier shitpile.  Still do, for that
> > matter.
> 
> You mean systemd by that?

Yes, I do.  Has it been merged into any other?
--
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: Getting new udev to run with 2.6.28

[Aaro Koskinen]

Hi,

On Sat, Jan 10, 2015 at 09:18:05PM +, Al Viro wrote:
> On Sat, Jan 10, 2015 at 09:13:35PM +0200, Aaro Koskinen wrote:
> > On Sat, Jan 10, 2015 at 06:39:20PM +0100, Pavel Machek wrote:
> > > N900 has real problems on 3.19, and 2.6.28 should be very well
> > > debugged version. Getting it to compile on recent distribution was
> > > fun, but I succeeded. Unfortunately, Debian 7's udev does not work
> > > with 2.6.28...
> > 
> > I guess you will have many other issues too if you want to run
> > such combination (legacy kernel + modern userspace). E.g. current glibc
> > requires >= 2.6.32.
> 
> How current is current and just what does it require in 2.6.32?

In glibc 2.20 the minimum kernel version was increased to 2.6.32.
Maybe this patch gives some examples what features they now expect
to be present:

https://sourceware.org/ml/libc-alpha/2014-04/msg00691.html

But looks like Debian 7 is not bleeding-edge and is using older version...

A.
--
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: Getting new udev to run with 2.6.28

[Pavel Machek]

On Sat 2015-01-10 21:18:05, Al Viro wrote:
> On Sat, Jan 10, 2015 at 09:13:35PM +0200, Aaro Koskinen wrote:
> > Hi,
> > 
> > On Sat, Jan 10, 2015 at 06:39:20PM +0100, Pavel Machek wrote:
> > > N900 has real problems on 3.19, and 2.6.28 should be very well
> > > debugged version. Getting it to compile on recent distribution was
> > > fun, but I succeeded. Unfortunately, Debian 7's udev does not work
> > > with 2.6.28...
> > 
> > I guess you will have many other issues too if you want to run
> > such combination (legacy kernel + modern userspace). E.g. current glibc
> > requires >= 2.6.32.
> 
> How current is current and just what does it require in 2.6.32?

Debian 7 seems to contain

root@n900:~# ls /lib/arm-linux-gnueabi/libc
libc-2.13.so

. And that one seems to be happy with 2.6.28. Its just udev that is
the problem.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/4] x86: ia32entry.S: fix wrong symbolic constant usage: R11->ARGOFFSET

[Borislav Petkov]

On Sat, Jan 10, 2015 at 02:41:07PM -0800, Linus Torvalds wrote:
> On Sat, Jan 10, 2015 at 2:35 PM, Borislav Petkov  wrote:
> >
> > Haha, Linus just made you maintainer of entry_64.S :-)
> 
> Just going by
> 
> git shortlog --no-merges --since=6.months arch/x86/kernel/entry_64.S
> 
> and looking at the kind of changes are going on, I really think a
> "tag, you're it" to Andy is a reasonable thing to do.
> 
> I just hope he's stupid^Wambitious enough to fall for it.

I'm sure he will, he's doing nuts stuff anyway to that file but it seems
to work so far :-)

You should take a look at this other thing too, using SYSRET to return
from exceptions:

https://lkml.kernel.org/r/49394403b8b12486a6b9c9c70b72bd9f5dce7364.1415403984.git.l...@amacapital.net

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/4] x86: open-code register save/restore in trace_hardirqs thunks

[Borislav Petkov]

On Sat, Jan 10, 2015 at 11:35:58PM +0100, Denys Vlasenko wrote:
> I don't know either... it seems to be used after push_cfi
> *sometimes*, not always:
> 
> .macro op_safe_regs op
> ENTRY(\op\()_safe_regs)
> CFI_STARTPROC
> pushl_cfi %ebx
> pushl_cfi %ebp
> pushl_cfi %esi
> pushl_cfi %edi
> 
> but
> 
> ENTRY(csum_partial)
> CFI_STARTPROC
> pushl_cfi %esi
> CFI_REL_OFFSET esi, 0
> pushl_cfi %ebx
> CFI_REL_OFFSET ebx, 0
> 
> We need an expert to enlighten us.

I think Andy had it:

https://lkml.kernel.org/r/calcetruuj8t%2blp23uyezhvxatf-l_20doad4adxcie7xzqd...@mail.gmail.com

So we better hide that crap in the macro at least, like the rest of the
CFI gunk.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/4] x86: ia32entry.S: fix wrong symbolic constant usage: R11->ARGOFFSET

[Linus Torvalds]

On Sat, Jan 10, 2015 at 2:35 PM, Borislav Petkov  wrote:
>
> Haha, Linus just made you maintainer of entry_64.S :-)

Just going by

git shortlog --no-merges --since=6.months arch/x86/kernel/entry_64.S

and looking at the kind of changes are going on, I really think a
"tag, you're it" to Andy is a reasonable thing to do.

I just hope he's stupid^Wambitious enough to fall for it.

Linus
--
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/4] x86: ia32entry.S: fix wrong symbolic constant usage: R11->ARGOFFSET

[Linus Torvalds]

On Sat, Jan 10, 2015 at 2:27 PM, Linus Torvalds
 wrote:
>
> So the only way to avoid a conflict is to not touch the same code, or
> to touch it *exactly* the same way in all respects.

.. with the caveat that the exact definition of "overlap" can end up
being somewhat fuzzy with the whole conflict simplification, so I
guess it can actually end up helping. But I think it could go either
way. Just from experience, the more important part is seeing that one
branch is obviously a superset of the other, which tends to happen
particularly with the case of "small parts of the new branch were
already merged as bug-fixes during the last development cycle".

   Linus
--
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/4] x86: open-code register save/restore in trace_hardirqs thunks

[Denys Vlasenko]

On Sat, Jan 10, 2015 at 11:07 PM, Linus Torvalds
 wrote:
> On Sat, Jan 10, 2015 at 2:00 PM, Denys Vlasenko  wrote:
>> +   pushq_cfi %rdi
>> +   CFI_REL_OFFSET rdi, 0
>> +   pushq_cfi %rsi
>> +   CFI_REL_OFFSET rsi, 0
>> +   pushq_cfi %rdx
>> +   CFI_REL_OFFSET rdx, 0
> ..
> Ugh.
>
> This is too ugly, it needs to die.
>
> Why doesn't pushq_cfi do that CFI_REL_OFFSET thing?

I don't know either... it seems to be used after push_cfi
*sometimes*, not always:

.macro op_safe_regs op
ENTRY(\op\()_safe_regs)
CFI_STARTPROC
pushl_cfi %ebx
pushl_cfi %ebp
pushl_cfi %esi
pushl_cfi %edi

but

ENTRY(csum_partial)
CFI_STARTPROC
pushl_cfi %esi
CFI_REL_OFFSET esi, 0
pushl_cfi %ebx
CFI_REL_OFFSET ebx, 0

We need an expert to enlighten us.
--
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] arch/x86/kernel/cpu/common.c: split log entry into logical components

[Joe Perches]

On Sat, 2015-01-10 at 22:21 +, Scot Doyle wrote:
> Call printk twice since this log entry has two lines and headings.
> 
> [0.009285] Last level iTLB entries: 4KB 1024, 2MB 1024, 4MB 1024
> Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 1024, 1GB 4
> 
> Signed-off-by: Scot Doyle 
> ---
>  arch/x86/kernel/cpu/common.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index c604965..76f253f 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -496,12 +496,12 @@ void cpu_detect_tlb(struct cpuinfo_x86 *c)
>   if (this_cpu->c_detect_tlb)
>   this_cpu->c_detect_tlb(c);
>  
> - printk(KERN_INFO "Last level iTLB entries: 4KB %d, 2MB %d, 4MB %d\n"
> - "Last level dTLB entries: 4KB %d, 2MB %d, 4MB %d, 1GB %d\n",
> + printk(KERN_INFO "Last level iTLB entries: 4KB %d, 2MB %d, 4MB %d\n",
>   tlb_lli_4k[ENTRIES], tlb_lli_2m[ENTRIES],
> - tlb_lli_4m[ENTRIES], tlb_lld_4k[ENTRIES],
> - tlb_lld_2m[ENTRIES], tlb_lld_4m[ENTRIES],
> - tlb_lld_1g[ENTRIES]);
> + tlb_lli_4m[ENTRIES]);
> + printk(KERN_INFO "Last level dTLB entries: 4KB %d, 2MB %d, 4MB %d, 1GB 
> %d\n",
> + tlb_lld_4k[ENTRIES], tlb_lld_2m[ENTRIES],
> + tlb_lld_4m[ENTRIES], tlb_lld_1g[ENTRIES]);
>  }

Check your dmesg version

https://lkml.org/lkml/2014/11/1/67
https://lkml.org/lkml/2014/11/2/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 2/4] x86: ia32entry.S: fix wrong symbolic constant usage: R11->ARGOFFSET

[Borislav Petkov]

On Sat, Jan 10, 2015 at 02:27:06PM -0800, Linus Torvalds wrote:
> I I do actually agree with you taking the fixes (and maybe you should
> *entirely* take ownership of all the entry_64.S changes, so that there
> is no "other side" to conflict with at all!). I just wanted to point
> out the actual effects from a conflict standpoint.

Haha, Linus just made you maintainer of entry_64.S :-)

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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: [GIT PULL] Block changes for 3.19-rc3

[Jens Axboe]

On 01/10/2015 12:59 PM, Linus Torvalds wrote:

On Fri, Jan 9, 2015 at 9:54 AM, Jens Axboe  wrote:


Please pull!


You've completely screwed up your pull request. You ask me to pull,
but you don't mention where from!


Oops, looks like I cut a line too much from the request-pull output. 
This is the URL:


  git://git.kernel.dk/linux-block.git for-linus


--
Jens Axboe

--
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: [PATCHv10 man-pages 5/5] execveat.2: initial man page for execveat(2)

[Eric W. Biederman]

Rich Felker  writes:

> On Sat, Jan 10, 2015 at 04:14:57AM +, Al Viro wrote:

>> Except that if your interpreter does stat(2) (or access(2), or getxattr(2),
>> etc.) before bothering with open(2), you'll get screwed.
>
> Yes, but I think that would be very bad interpreter design.
> stat/getxattr/access/whatever followed by open is always a TOCTOU
> race. The correct sequence of actions is always open followed by
> fstat/fgetxattr/...

Sigh.  I think everyone who has looked at this has been blind.

If userspace is reasonable all we have to do is fix /proc/self/exe
for shell scripts to point at the actual script,
and then pass /proc/self/exe on the shell scripts command line.

At a practical level we have to worry about backwards compability and
chroot jails.  But the existence of a clean implementation with
/proc/self/exe serves a proof of concept that it would not be too
difficult.  When someone cares enough to implement it.

Eric
--
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/4] x86: ia32entry.S: fix wrong symbolic constant usage: R11->ARGOFFSET

[Linus Torvalds]

On Sat, Jan 10, 2015 at 2:13 PM, Andy Lutomirski  wrote:
>
> I'll make the same change to my pending entry work, and hopefully we
> can avoid conflicts.

That's not how conflicts work.

Either there is no overlap between the changes at all, in which case
it doesn't matter if you then also have Denys' changes in your tree.

Or you have other changes that change code around Denys' code, in
which case you'll get conflicts whether you have Denys' changes or not
(because two branches will be changing the same area differently, and
so there's a conflict that needs to resolve which side was right).

So the only way to avoid a conflict is to not touch the same code, or
to touch it *exactly* the same way in all respects.

Now, while the *conflict* is not something you can't avoid, some
conflicts are easier to resolve than others, and from a conflict
resolution standpoint it can make sense for your branch to include
Denys' changes.

Why? Because if whoever resolves the conflict sees that one branch is
a proper superset of the other branch, than the resolution is a much
more obvious "let's just take everything from one side" edit, rather
than having to pick-and-choose.

I I do actually agree with you taking the fixes (and maybe you should
*entirely* take ownership of all the entry_64.S changes, so that there
is no "other side" to conflict with at all!). I just wanted to point
out the actual effects from a conflict standpoint.

  Linus
--
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: Getting new udev to run with 2.6.28

[Martin Steigerwald]

Am Samstag, 10. Januar 2015, 21:18:58 schrieb Al Viro:
> On Sat, Jan 10, 2015 at 10:17:10AM -0800, Greg KH wrote:
> > > > Yes, 3.18, please use that instead.
> > > 
> > > Can't, sorry. My goal is to get 3.18/3.19 working, but I really need
> > > working kernel to debug userland (and then use that userland to debug
> > > kernel).> > 
> > > > Seriously, lots of things have changed, if you want to run a "new"
> > > > version of udev with an old kernel, try eudev, they have been
> > > > attempting
> > > > to keep "legacy" support around in it, don't know how well it has been
> > > > working though, you really are on your own.
> > > 
> > > I was hoping someone has devtmpfs patches I could just apply over
> > > 2.6.28 and get a working system?
> > 
> > If you want such a crazy thing, you have all of the source to do it
> > yourself, good luck.
> 
> ... and this, boys and girls, is why quite a few of us have loathed udev
> way before it got merged into even nastier shitpile.  Still do, for that
> matter.

You mean systemd by that?

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
--
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] arch/x86/kernel/cpu/common.c: split log entry into logical components

[Scot Doyle]

Call printk twice since this log entry has two lines and headings.

[0.009285] Last level iTLB entries: 4KB 1024, 2MB 1024, 4MB 1024
Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 1024, 1GB 4

Signed-off-by: Scot Doyle 
---
 arch/x86/kernel/cpu/common.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index c604965..76f253f 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -496,12 +496,12 @@ void cpu_detect_tlb(struct cpuinfo_x86 *c)
if (this_cpu->c_detect_tlb)
this_cpu->c_detect_tlb(c);
 
-   printk(KERN_INFO "Last level iTLB entries: 4KB %d, 2MB %d, 4MB %d\n"
-   "Last level dTLB entries: 4KB %d, 2MB %d, 4MB %d, 1GB %d\n",
+   printk(KERN_INFO "Last level iTLB entries: 4KB %d, 2MB %d, 4MB %d\n",
tlb_lli_4k[ENTRIES], tlb_lli_2m[ENTRIES],
-   tlb_lli_4m[ENTRIES], tlb_lld_4k[ENTRIES],
-   tlb_lld_2m[ENTRIES], tlb_lld_4m[ENTRIES],
-   tlb_lld_1g[ENTRIES]);
+   tlb_lli_4m[ENTRIES]);
+   printk(KERN_INFO "Last level dTLB entries: 4KB %d, 2MB %d, 4MB %d, 1GB 
%d\n",
+   tlb_lld_4k[ENTRIES], tlb_lld_2m[ENTRIES],
+   tlb_lld_4m[ENTRIES], tlb_lld_1g[ENTRIES]);
 }
 
 void detect_ht(struct cpuinfo_x86 *c)
-- 
2.1.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/

Re: [PATCH v5 3/7] iio: Add support for DA9150 GPADC

[Jonathan Cameron]

On 07/01/15 16:03, Opensource [Adam Thomson] wrote:
> On January 4, 2015 17:22, Jonathan Cameron wrote:
> 
>> On 22/12/14 16:51, Adam Thomson wrote:
>>> This patch adds support for DA9150 Charger & Fuel-Gauge IC GPADC.
>>>
>>> Signed-off-by: Adam Thomson 
>> One last query from me.
>>
>> Using the extended channel names in IIO is only really appropriate when
>> they don't correspond to simple pins on the side of the chip. For those
>> just drop the extname bit.  Some of the channels you have here, definitely
>> need them though.
>>
>> Drop those first 4 or convince me otherwise and add
>> Acked-by: Jonathan Cameron 
> 
> Have added responses below. If the comments are accepted then I'll respin
> and add you're 'Acked-by'. Is that ok?
> 
Not accepted as yet :)
>>> +#define DA9150_GPADC_CHANNEL_PROCESSED(_id, _hw_id, _type, _ext_name)
>>  \
>>> +   DA9150_GPADC_CHANNEL(_id, _hw_id, _type,\
>>> +BIT(IIO_CHAN_INFO_PROCESSED), _ext_name)
>>> +
>>> +/* Supported channels */
>>> +static const struct iio_chan_spec da9150_gpadc_channels[] = {
>>> +   DA9150_GPADC_CHANNEL_PROCESSED(GPIOA, GPIOA_6V, IIO_VOLTAGE,
>> "GPIOA"),
>>> +   DA9150_GPADC_CHANNEL_PROCESSED(GPIOB, GPIOB_6V, IIO_VOLTAGE,
>> "GPIOB"),
>>> +   DA9150_GPADC_CHANNEL_PROCESSED(GPIOC, GPIOC_6V, IIO_VOLTAGE,
>> "GPIOC"),
>>> +   DA9150_GPADC_CHANNEL_PROCESSED(GPIOD, GPIOD_6V, IIO_VOLTAGE,
>> "GPIOD"),
>> I'm not sure some of these really deserve extended names.  Those are usually
>> reserved for naming strange internal adc channels etc.  These first 4 are
>> presumably just for input pins?  Those should just be channels 0..3
>> On another note, unless you want really weird sysfs attribute names, the
>> extended names want to be lowercase.
>>
> 
> I'd prefer to keep the names because the input pins are muxed with GPIOs of 
> the
> chip, so thought it sensible to show that this is the case. Am happy to change
> to lower-case to follow convention.
Hmm.  It's a bit of an oddity as the point of the naming
is about the uses, not which pins they are on.  If we exposed the
'datasheet_name' parameter directly rather than just using it internally
I'd suggest relying on that - but clearly you want it to be apparent
in the interface.  Whether that is useful is the question I'd raise
here (and is the reason datasheet_name is not exposed.

The obvious question is does userspace care?  Answer is probably not.

It cares what is being measured but this is about what pins it is
on and doesn't provide any information on what is connected to them.


> 
>>> +   DA9150_GPADC_CHANNEL_PROCESSED(IBUS, IBUS_SENSE, IIO_CURRENT,
>> "IBUS"),
>>> +   DA9150_GPADC_CHANNEL_PROCESSED(VBUS, VBUS_DIV_, IIO_VOLTAGE,
>> "VBUS"),
>>> +   DA9150_GPADC_CHANNEL_RAW(ID, ID, IIO_VOLTAGE, "ID"),
>> You hae an identifier voltage? That's certainly unusual but if so - fair 
>> enough
>> and it defintely needs the extname!
> 
> Thanks for pointing that out. Having checked again, this is not needed and can
> be dispensed with.
> 
>>> +   DA9150_GPADC_CHANNEL_PROCESSED(VSYS, VSYS, IIO_VOLTAGE, "VSYS"),
>>> +   DA9150_GPADC_CHANNEL_SCALED(VBAT, VBAT, IIO_VOLTAGE, "VBAT"),
>>> +   DA9150_GPADC_CHANNEL_RAW(TBAT, TBAT, IIO_VOLTAGE, "TBAT"),
>>> +   DA9150_GPADC_CHANNEL_SCALED(TJUNC_CORE, TJUNC_CORE,
>> IIO_TEMP,
>>> +   "TJUNC_CORE"),
>> tjunc_core is a good use of extname ;)
>>> +   DA9150_GPADC_CHANNEL_SCALED(TJUNC_OVP, TJUNC_OVP, IIO_TEMP,
>>> +   "TJUNC_OVP"),
>>> +};
>>> +
>>> +/* Default maps used by da9150-charger */
>>> +static struct iio_map da9150_gpadc_default_maps[] = {
>>> +   {
>>> +   .consumer_dev_name = "da9150-charger",
>>> +   .consumer_channel = "CHAN_IBUS",
>>> +   .adc_channel_label = "IBUS",
>>> +   },
>>> +   {
>>> +   .consumer_dev_name = "da9150-charger",
>>> +   .consumer_channel = "CHAN_VBUS",
>>> +   .adc_channel_label = "VBUS",
>>> +   },
>>> +   {
>>> +   .consumer_dev_name = "da9150-charger",
>>> +   .consumer_channel = "CHAN_TJUNC",
>>> +   .adc_channel_label = "TJUNC_CORE",
>>> +   },
>>> +   {
>>> +   .consumer_dev_name = "da9150-charger",
>>> +   .consumer_channel = "CHAN_VBAT",
>>> +   .adc_channel_label = "VBAT",
>>> +   },
>>> +   {},
>>> +};
>>> +
>>> +static int da9150_gpadc_probe(struct platform_device *pdev)
>>> +{
>>> +   struct device *dev = >dev;
>>> +   struct da9150 *da9150 = dev_get_drvdata(dev->parent);
>>> +   struct da9150_gpadc *gpadc;
>>> +   struct iio_dev *indio_dev;
>>> +   int irq, ret;
>>> +
>>> +   indio_dev = devm_iio_device_alloc(>dev, sizeof(*gpadc));
>>> +   if (!indio_dev) {
>>> +   dev_err(>dev, "Failed to allocate IIO device\n");
>>> +   return -ENOMEM;
>>> +   }
>>> +   gpadc = iio_priv(indio_dev);
>>> +
>>> +   platform_set_drvdata(pdev, indio_dev);
>>> +   gpadc->da9150 = da9150;
>>> +   gpadc->dev = dev;
>>> +   

Re: [PATCH v3 1/3] input: misc: Support NI Ettus Research USRP E3x0 Button

[Dmitry Torokhov]

Hi Moritz,

On Fri, Jan 09, 2015 at 12:59:29AM +0100, Moritz Fischer wrote:
> +static struct platform_driver e3x0_button_driver = {
> + .driver = {
> + .name   = "e3x0-button",
> + .of_match_table = of_match_ptr(e3x0_button_match),

You forgot to assign .pm pointer here. I fixed it up and applied the
driver.

Thanks.

-- 
Dmitry
--
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/4] x86: ia32entry.S: fix wrong symbolic constant usage: R11->ARGOFFSET

[Andy Lutomirski]

On Sat, Jan 10, 2015 at 2:00 PM, Denys Vlasenko  wrote:
> The values of these two constants are the same, the meaning is different.

Acked-by: Andy Lutomirski 

I'll make the same change to my pending entry work, and hopefully we
can avoid conflicts.

--Andy

>
> Signed-off-by: Denys Vlasenko 
> Acked-by: Borislav Petkov 
> CC: Linus Torvalds 
> CC: Oleg Nesterov 
> CC: "H. Peter Anvin" 
> CC: Borislav Petkov 
> CC: Andy Lutomirski 
> CC: Frederic Weisbecker 
> CC: X86 ML 
> CC: Alexei Starovoitov 
> CC: Will Drewry 
> CC: Kees Cook 
> CC: linux-kernel@vger.kernel.org
> ---
>  arch/x86/ia32/ia32entry.S | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
> index 82e8a1d..156ebca 100644
> --- a/arch/x86/ia32/ia32entry.S
> +++ b/arch/x86/ia32/ia32entry.S
> @@ -179,8 +179,8 @@ sysenter_dispatch:
>  sysexit_from_sys_call:
> andl$~TS_COMPAT,TI_status+THREAD_INFO(%rsp,RIP-ARGOFFSET)
> /* clear IF, that popfq doesn't enable interrupts early */
> -   andl  $~0x200,EFLAGS-R11(%rsp)
> -   movlRIP-R11(%rsp),%edx  /* User %eip */
> +   andl$~0x200,EFLAGS-ARGOFFSET(%rsp)
> +   movlRIP-ARGOFFSET(%rsp),%edx/* User %eip */
> CFI_REGISTER rip,rdx
> RESTORE_ARGS 0,24,0,0,0,0
> xorq%r8,%r8
> --
> 1.8.1.4
>



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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/4] x86: entry_64.S: delete unused code

[Andy Lutomirski]

On Sat, Jan 10, 2015 at 2:00 PM, Denys Vlasenko  wrote:
> A define, two macros and an unreferenced bit of assembly are gone.


Acked-by: Andy Lutomirski 

>
> Signed-off-by: Denys Vlasenko 
> Acked-by: Borislav Petkov 
> CC: Linus Torvalds 
> CC: Oleg Nesterov 
> CC: "H. Peter Anvin" 
> CC: Borislav Petkov 
> CC: Andy Lutomirski 
> CC: Frederic Weisbecker 
> CC: X86 ML 
> CC: Alexei Starovoitov 
> CC: Will Drewry 
> CC: Kees Cook 
> CC: linux-kernel@vger.kernel.org
> ---
>  arch/x86/include/asm/calling.h |  1 -
>  arch/x86/kernel/entry_64.S | 34 --
>  2 files changed, 35 deletions(-)
>
> diff --git a/arch/x86/include/asm/calling.h b/arch/x86/include/asm/calling.h
> index 76659b6..1f1297b 100644
> --- a/arch/x86/include/asm/calling.h
> +++ b/arch/x86/include/asm/calling.h
> @@ -83,7 +83,6 @@ For 32-bit we have the following conventions - kernel is 
> built with
>  #define SS 160
>
>  #define ARGOFFSET  R11
> -#define SWFRAMEORIG_RAX
>
> .macro SAVE_ARGS addskip=0, save_rcx=1, save_r891011=1, rax_enosys=0
> subq  $9*8+\addskip, %rsp
> diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> index 931f32f..5ed4773 100644
> --- a/arch/x86/kernel/entry_64.S
> +++ b/arch/x86/kernel/entry_64.S
> @@ -155,27 +155,6 @@ ENDPROC(native_usergs_sysret64)
> movq \tmp,R11+\offset(%rsp)
> .endm
>
> -   .macro FAKE_STACK_FRAME child_rip
> -   /* push in order ss, rsp, eflags, cs, rip */
> -   xorl %eax, %eax
> -   pushq_cfi $__KERNEL_DS /* ss */
> -   /*CFI_REL_OFFSETss,0*/
> -   pushq_cfi %rax /* rsp */
> -   CFI_REL_OFFSET  rsp,0
> -   pushq_cfi $(X86_EFLAGS_IF|X86_EFLAGS_FIXED) /* eflags - interrupts on 
> */
> -   /*CFI_REL_OFFSETrflags,0*/
> -   pushq_cfi $__KERNEL_CS /* cs */
> -   /*CFI_REL_OFFSETcs,0*/
> -   pushq_cfi \child_rip /* rip */
> -   CFI_REL_OFFSET  rip,0
> -   pushq_cfi %rax /* orig rax */
> -   .endm
> -
> -   .macro UNFAKE_STACK_FRAME
> -   addq $8*6, %rsp
> -   CFI_ADJUST_CFA_OFFSET   -(6*8)
> -   .endm
> -
>  /*
>   * initial frame state for interrupts (and exceptions without error code)
>   */
> @@ -626,19 +605,6 @@ END(\label)
> FORK_LIKE  vfork
> FIXED_FRAME stub_iopl, sys_iopl
>
> -ENTRY(ptregscall_common)
> -   DEFAULT_FRAME 1 8   /* offset 8: return address */
> -   RESTORE_TOP_OF_STACK %r11, 8
> -   movq_cfi_restore R15+8, r15
> -   movq_cfi_restore R14+8, r14
> -   movq_cfi_restore R13+8, r13
> -   movq_cfi_restore R12+8, r12
> -   movq_cfi_restore RBP+8, rbp
> -   movq_cfi_restore RBX+8, rbx
> -   ret $REST_SKIP  /* pop extended registers */
> -   CFI_ENDPROC
> -END(ptregscall_common)
> -
>  ENTRY(stub_execve)
> CFI_STARTPROC
> addq $8, %rsp
> --
> 1.8.1.4
>



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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: [RFC PATCH] iio: Add new operating mode for non triggered sw buffers

[Jonathan Cameron]

On 08/01/15 10:47, Lars-Peter Clausen wrote:
> On 01/07/2015 07:36 PM, Karol Wrona wrote:
>> There was a need for non triggered software buffer type.  It can be used when
>> triggered model does not fit and INDIO_BUFFER_HARDWARE causes confusion 
>> because
>> the data stream can be obtained not directly form hardware backend.
>>
>> Suggested-by: Jonathan Cameron 
>> Signed-off-by: Karol Wrona 
> 
> Looks good, thanks.
> 
> Reviewed-by: Lars-Peter Clausen 
> 
Thanks for doing this.

Applied to the togreg branch of iio.git - initially pushed out
as testing.

Jonathan
>> ---
>>   drivers/iio/industrialio-buffer.c |2 ++
>>   include/linux/iio/iio.h   |6 --
>>   2 files changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/iio/industrialio-buffer.c 
>> b/drivers/iio/industrialio-buffer.c
>> index f971f79..15e6de3 100644
>> --- a/drivers/iio/industrialio-buffer.c
>> +++ b/drivers/iio/industrialio-buffer.c
>> @@ -680,6 +680,8 @@ static int __iio_update_buffers(struct iio_dev 
>> *indio_dev,
>>   indio_dev->currentmode = INDIO_BUFFER_TRIGGERED;
>>   } else if (indio_dev->modes & INDIO_BUFFER_HARDWARE) {
>>   indio_dev->currentmode = INDIO_BUFFER_HARDWARE;
>> +} else if (indio_dev->modes & INDIO_BUFFER_SOFTWARE) {
>> +indio_dev->currentmode = INDIO_BUFFER_SOFTWARE;
>>   } else { /* Should never be reached */
>>   ret = -EINVAL;
>>   goto error_run_postdisable;
>> diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
>> index 3642ce7..55e63fd 100644
>> --- a/include/linux/iio/iio.h
>> +++ b/include/linux/iio/iio.h
>> @@ -284,10 +284,11 @@ static inline s64 iio_get_time_ns(void)
>>   /* Device operating modes */
>>   #define INDIO_DIRECT_MODE0x01
>>   #define INDIO_BUFFER_TRIGGERED0x02
>> +#define INDIO_BUFFER_SOFTWARE0x04
>>   #define INDIO_BUFFER_HARDWARE0x08
>>
>>   #define INDIO_ALL_BUFFER_MODES\
>> -(INDIO_BUFFER_TRIGGERED | INDIO_BUFFER_HARDWARE)
>> +(INDIO_BUFFER_TRIGGERED | INDIO_BUFFER_HARDWARE | INDIO_BUFFER_SOFTWARE)
>>
>>   #define INDIO_MAX_RAW_ELEMENTS4
>>
>> @@ -591,7 +592,8 @@ void devm_iio_trigger_free(struct device *dev, struct 
>> iio_trigger *iio_trig);
>>   static inline bool iio_buffer_enabled(struct iio_dev *indio_dev)
>>   {
>>   return indio_dev->currentmode
>> -& (INDIO_BUFFER_TRIGGERED | INDIO_BUFFER_HARDWARE);
>> +& (INDIO_BUFFER_TRIGGERED | INDIO_BUFFER_HARDWARE |
>> +   INDIO_BUFFER_SOFTWARE);
>>   }
>>
>>   /**
>>
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
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: [BUG] 3.19-rc1 net: less interrupt masking in NAPI

[Oded Gabbay]

On 01/11/2015 12:05 AM, Oded Gabbay wrote:
> 
> 
> On 01/10/2015 11:50 PM, Eric Dumazet wrote:
>> On Sat, 2015-01-10 at 23:30 +0200, Oded Gabbay wrote:
>>
>>> Yes, no problem.
>>> I will update on the result.
>>
>> Please try this more complete patch, solving the TX pressure problem as
>> well, and not lying about NAPI budget. thanks !
>>
>>
>> diff --git a/drivers/net/ethernet/atheros/alx/main.c 
>> b/drivers/net/ethernet/atheros/alx/main.c
>> index e398eda07298..5f05b387c0a7 100644
>> --- a/drivers/net/ethernet/atheros/alx/main.c
>> +++ b/drivers/net/ethernet/atheros/alx/main.c
>> @@ -184,15 +184,16 @@ static void alx_schedule_reset(struct alx_priv *alx)
>>  schedule_work(>reset_wk);
>>  }
>>  
>> -static bool alx_clean_rx_irq(struct alx_priv *alx, int budget)
>> +static int alx_clean_rx_irq(struct alx_priv *alx, int budget)
>>  {
>>  struct alx_rx_queue *rxq = >rxq;
>>  struct alx_rrd *rrd;
>>  struct alx_buffer *rxb;
>>  struct sk_buff *skb;
>>  u16 length, rfd_cleaned = 0;
>> +int work = 0;
>>  
>> -while (budget > 0) {
>> +while (work < budget) {
>>  rrd = >rrd[rxq->rrd_read_idx];
>>  if (!(rrd->word3 & cpu_to_le32(1 << RRD_UPDATED_SHIFT)))
>>  break;
>> @@ -243,7 +244,7 @@ static bool alx_clean_rx_irq(struct alx_priv *alx, int 
>> budget)
>>  }
>>  
>>  napi_gro_receive(>napi, skb);
>> -budget--;
>> +work++;
>>  
>>  next_pkt:
>>  if (++rxq->read_idx == alx->rx_ringsz)
>> @@ -258,21 +259,22 @@ next_pkt:
>>  if (rfd_cleaned)
>>  alx_refill_rx_ring(alx, GFP_ATOMIC);
>>  
>> -return budget > 0;
>> +return work;
>>  }
>>  
>>  static int alx_poll(struct napi_struct *napi, int budget)
>>  {
>>  struct alx_priv *alx = container_of(napi, struct alx_priv, napi);
>>  struct alx_hw *hw = >hw;
>> -bool complete = true;
>>  unsigned long flags;
>> +bool tx_complete;
>> +int work;
>>  
>> -complete = alx_clean_tx_irq(alx) &&
>> -   alx_clean_rx_irq(alx, budget);
>> +tx_complete = alx_clean_tx_irq(alx);
>> +work = alx_clean_rx_irq(alx, budget);
>>  
>> -if (!complete)
>> -return 1;
>> +if (!tx_complete || work == budget)
>> +return budget;
>>  
>>  napi_complete(>napi);
>>  
>> @@ -284,7 +286,7 @@ static int alx_poll(struct napi_struct *napi, int budget)
>>  
>>  alx_post_write(hw);
>>  
>> -return 0;
>> +return work;
>>  }
>>  
>>  static irqreturn_t alx_intr_handle(struct alx_priv *alx, u32 intr)
>>
>>
> Hi,
> Checked it and its working.
> Thanks again.
> Please note that I only use this Ethernet controller for NFS and SCP, it is
> not used for development of networking software of any kind, so maybe a more
> extensive testing is needed.
> 
>   Oded
> --
> 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/
> 

But in any case, you can add:
Tested-by: Oded Gabbay 

Oded
--
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/

[char-misc-next V3] mei: add reference counting for me clients

[Tomas Winkler]

To support dynamic addition and removal of
me clients we add reference counter.

Update kdoc with locking requirements.

Signed-off-by: Tomas Winkler 
---
V2: add locking requirements to kdoc
V3: fix warning: 'cb/me_cl' may be used uninitialized in this function 

 drivers/misc/mei/amthif.c  |  14 +++--
 drivers/misc/mei/bus.c |  39 +++-
 drivers/misc/mei/client.c  | 152 ++---
 drivers/misc/mei/client.h  |  17 +++--
 drivers/misc/mei/debugfs.c |  32 ++
 drivers/misc/mei/hbm.c |  34 +-
 drivers/misc/mei/main.c|  22 +++
 drivers/misc/mei/mei_dev.h |   2 +
 drivers/misc/mei/nfc.c |   2 +
 drivers/misc/mei/wd.c  |   1 +
 10 files changed, 221 insertions(+), 94 deletions(-)

diff --git a/drivers/misc/mei/amthif.c b/drivers/misc/mei/amthif.c
index 79f53941779d..c4cb9a984a5f 100644
--- a/drivers/misc/mei/amthif.c
+++ b/drivers/misc/mei/amthif.c
@@ -97,23 +97,25 @@ int mei_amthif_host_init(struct mei_device *dev)
/* allocate storage for ME message buffer */
msg_buf = kcalloc(dev->iamthif_mtu,
sizeof(unsigned char), GFP_KERNEL);
-   if (!msg_buf)
-   return -ENOMEM;
+   if (!msg_buf) {
+   ret = -ENOMEM;
+   goto out;
+   }
 
dev->iamthif_msg_buf = msg_buf;
 
ret = mei_cl_link(cl, MEI_IAMTHIF_HOST_CLIENT_ID);
-
if (ret < 0) {
-   dev_err(dev->dev,
-   "amthif: failed link client %d\n", ret);
-   return ret;
+   dev_err(dev->dev, "amthif: failed cl_link %d\n", ret);
+   goto out;
}
 
ret = mei_cl_connect(cl, NULL);
 
dev->iamthif_state = MEI_IAMTHIF_IDLE;
 
+out:
+   mei_me_cl_put(me_cl);
return ret;
 }
 
diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 31164dd14bd0..be767f4db26a 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -228,8 +228,8 @@ static ssize_t ___mei_cl_send(struct mei_cl *cl, u8 *buf, 
size_t length,
bool blocking)
 {
struct mei_device *dev;
-   struct mei_me_client *me_cl;
-   struct mei_cl_cb *cb;
+   struct mei_me_client *me_cl = NULL;
+   struct mei_cl_cb *cb = NULL;
ssize_t rets;
 
if (WARN_ON(!cl || !cl->dev))
@@ -237,33 +237,40 @@ static ssize_t ___mei_cl_send(struct mei_cl *cl, u8 *buf, 
size_t length,
 
dev = cl->dev;
 
-   if (cl->state != MEI_FILE_CONNECTED)
-   return -ENODEV;
+   mutex_lock(>device_lock);
+   if (cl->state != MEI_FILE_CONNECTED) {
+   rets = -ENODEV;
+   goto out;
+   }
 
/* Check if we have an ME client device */
me_cl = mei_me_cl_by_uuid_id(dev, >cl_uuid, cl->me_client_id);
-   if (!me_cl)
-   return -ENOTTY;
+   if (!me_cl) {
+   rets = -ENOTTY;
+   goto out;
+   }
 
-   if (length > me_cl->props.max_msg_length)
-   return -EFBIG;
+   if (length > me_cl->props.max_msg_length) {
+   rets = -EFBIG;
+   goto out;
+   }
 
cb = mei_io_cb_init(cl, NULL);
-   if (!cb)
-   return -ENOMEM;
+   if (!cb) {
+   rets = -ENOMEM;
+   goto out;
+   }
 
rets = mei_io_cb_alloc_req_buf(cb, length);
-   if (rets < 0) {
-   mei_io_cb_free(cb);
-   return rets;
-   }
+   if (rets < 0)
+   goto out;
 
memcpy(cb->request_buffer.data, buf, length);
 
-   mutex_lock(>device_lock);
-
rets = mei_cl_write(cl, cb, blocking);
 
+out:
+   mei_me_cl_put(me_cl);
mutex_unlock(>device_lock);
if (rets < 0)
mei_io_cb_free(cb);
diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index 28e004b52dd2..9541218c10eb 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -27,7 +27,63 @@
 #include "client.h"
 
 /**
+ * mei_me_cl_init - initialize me client
+ *
+ * @me_cl: me client
+ */
+void mei_me_cl_init(struct mei_me_client *me_cl)
+{
+   INIT_LIST_HEAD(_cl->list);
+   kref_init(_cl->refcnt);
+}
+
+/**
+ * mei_me_cl_get - increases me client refcount
+ *
+ * @me_cl: me client
+ *
+ * Locking: called under "dev->device_lock" lock
+ *
+ * Return: me client or NULL
+ */
+struct mei_me_client *mei_me_cl_get(struct mei_me_client *me_cl)
+{
+   if (me_cl)
+   kref_get(_cl->refcnt);
+
+   return me_cl;
+}
+
+/**
+ * mei_me_cl_release - unlink and free me client
+ *
+ * Locking: called under "dev->device_lock" lock
+ *
+ * @ref: me_client refcount
+ */
+static void mei_me_cl_release(struct kref *ref)
+{
+   struct mei_me_client *me_cl =
+   container_of(ref, struct mei_me_client, refcnt);
+   list_del(_cl->list);
+   kfree(me_cl);
+}
+/**
+ * mei_me_cl_put - decrease me client refcount and free 

Re: [PATCH RESEND] nfs: prevent truncate on active swapfile

[Trond Myklebust]

Hi Omar,

On Thu, Jan 8, 2015 at 4:18 AM, Omar Sandoval  wrote:
> Most filesystems prevent truncation of an active swapfile by way of
> inode_newsize_ok, called from inode_change_ok. NFS doesn't call either
> from nfs_setattr, presumably because most of these checks are expected
> to be done server-side. However, the IS_SWAPFILE check can only be done
> client-side, and truncating a swapfile can't possibly be good.
>
> Signed-off-by: Omar Sandoval 
> ---
> Hi, Trond,
>
> Now that the holidays are over, could you take a look at this? It was
> generated against v3.19-rc3.
>
> Thanks!
>
>  fs/nfs/inode.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
> index 4bffe63..9205513 100644
> --- a/fs/nfs/inode.c
> +++ b/fs/nfs/inode.c
> @@ -506,10 +506,15 @@ nfs_setattr(struct dentry *dentry, struct iattr *attr)
> attr->ia_valid &= ~ATTR_MODE;
>
> if (attr->ia_valid & ATTR_SIZE) {
> +   loff_t i_size;
> +
> BUG_ON(!S_ISREG(inode->i_mode));
>
> -   if (attr->ia_size == i_size_read(inode))
> +   i_size = i_size_read(inode);
> +   if (attr->ia_size == i_size)
> attr->ia_valid &= ~ATTR_SIZE;
> +   else if (attr->ia_size < i_size && IS_SWAPFILE(inode))
> +   return -ETXTBSY;
> }
>
> /* Optimization: if the end result is no change, don't RPC */
> --
> 2.2.1
>

I agree that truncating a swap file is bad, however as you point out,
this really only addresses the case on the client that knows about
this being a swap file.
I'll take the patch, but I'm wondering if we couldn't do better in the
case where we're using NFSv4 by using share deny modes (which are
enforced by the server). The problem is that there appears to be
nothing in swapon() that tells the filesystem this is an open of a
swap file...

Cheers
  Trond
-- 
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.mykleb...@primarydata.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: [PATCH 3/4] x86: open-code register save/restore in trace_hardirqs thunks

[Linus Torvalds]

On Sat, Jan 10, 2015 at 2:00 PM, Denys Vlasenko  wrote:
> +   pushq_cfi %rdi
> +   CFI_REL_OFFSET rdi, 0
> +   pushq_cfi %rsi
> +   CFI_REL_OFFSET rsi, 0
> +   pushq_cfi %rdx
> +   CFI_REL_OFFSET rdx, 0
..
Ugh.

This is too ugly, it needs to die.

Why doesn't pushq_cfi do that CFI_REL_OFFSET thing?

And if there is some good reason why, then please let's just make sure
that there is a sane way to write pushes and pops, without having that
insane CFI crap for every single damn case.

Because this is unreadable.

   Linus
--
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: [BUG] 3.19-rc1 net: less interrupt masking in NAPI

[Oded Gabbay]

On 01/10/2015 11:50 PM, Eric Dumazet wrote:
> On Sat, 2015-01-10 at 23:30 +0200, Oded Gabbay wrote:
> 
>> Yes, no problem.
>> I will update on the result.
> 
> Please try this more complete patch, solving the TX pressure problem as
> well, and not lying about NAPI budget. thanks !
> 
> 
> diff --git a/drivers/net/ethernet/atheros/alx/main.c 
> b/drivers/net/ethernet/atheros/alx/main.c
> index e398eda07298..5f05b387c0a7 100644
> --- a/drivers/net/ethernet/atheros/alx/main.c
> +++ b/drivers/net/ethernet/atheros/alx/main.c
> @@ -184,15 +184,16 @@ static void alx_schedule_reset(struct alx_priv *alx)
>   schedule_work(>reset_wk);
>  }
>  
> -static bool alx_clean_rx_irq(struct alx_priv *alx, int budget)
> +static int alx_clean_rx_irq(struct alx_priv *alx, int budget)
>  {
>   struct alx_rx_queue *rxq = >rxq;
>   struct alx_rrd *rrd;
>   struct alx_buffer *rxb;
>   struct sk_buff *skb;
>   u16 length, rfd_cleaned = 0;
> + int work = 0;
>  
> - while (budget > 0) {
> + while (work < budget) {
>   rrd = >rrd[rxq->rrd_read_idx];
>   if (!(rrd->word3 & cpu_to_le32(1 << RRD_UPDATED_SHIFT)))
>   break;
> @@ -243,7 +244,7 @@ static bool alx_clean_rx_irq(struct alx_priv *alx, int 
> budget)
>   }
>  
>   napi_gro_receive(>napi, skb);
> - budget--;
> + work++;
>  
>  next_pkt:
>   if (++rxq->read_idx == alx->rx_ringsz)
> @@ -258,21 +259,22 @@ next_pkt:
>   if (rfd_cleaned)
>   alx_refill_rx_ring(alx, GFP_ATOMIC);
>  
> - return budget > 0;
> + return work;
>  }
>  
>  static int alx_poll(struct napi_struct *napi, int budget)
>  {
>   struct alx_priv *alx = container_of(napi, struct alx_priv, napi);
>   struct alx_hw *hw = >hw;
> - bool complete = true;
>   unsigned long flags;
> + bool tx_complete;
> + int work;
>  
> - complete = alx_clean_tx_irq(alx) &&
> -alx_clean_rx_irq(alx, budget);
> + tx_complete = alx_clean_tx_irq(alx);
> + work = alx_clean_rx_irq(alx, budget);
>  
> - if (!complete)
> - return 1;
> + if (!tx_complete || work == budget)
> + return budget;
>  
>   napi_complete(>napi);
>  
> @@ -284,7 +286,7 @@ static int alx_poll(struct napi_struct *napi, int budget)
>  
>   alx_post_write(hw);
>  
> - return 0;
> + return work;
>  }
>  
>  static irqreturn_t alx_intr_handle(struct alx_priv *alx, u32 intr)
> 
> 
Hi,
Checked it and its working.
Thanks again.
Please note that I only use this Ethernet controller for NFS and SCP, it is
not used for development of networking software of any kind, so maybe a more
extensive testing is needed.

Oded
--
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/4] x86: open-code register save/restore in trace_hardirqs thunks

[Andy Lutomirski]

On Sat, Jan 10, 2015 at 2:00 PM, Borislav Petkov  wrote:
> On Sat, Jan 10, 2015 at 09:14:03PM +0100, Denys Vlasenko wrote:
>> From 2f636e0a92db898f2bdb592027aa302fcb32a326 Mon Sep 17 00:00:00 2001
>> From: Denys Vlasenko 
>> To: linux-kernel@vger.kernel.org
>> Subject: [PATCH 3/4] x86: open-code register save/restore in trace_hardirqs 
>> thunks
>>
>> This is a preparatory patch for change in "struct pt_regs"
>> handling in entry_64.S.
>>
>> trace_hardirqs thunks were (ab)using a part of pt_regs
>> handling code, namely SAVE_ARGS/RESTORE_ARGS macros,
>> to save/restore registers across C function calls.
>>
>> Since SAVE_ARGS is going to be changed, open-code
>> register saving/restoring here. Take a page from thunk_32.S
>> and use push/pop insns instead of movq, they are far shorter:
>> 1 or 2 bytes versus 5, and no need for insns to adjust %rsp:
>>
>>text  data bss dec hex filename
>> 33340   0 373 175 thunk_64_movq.o
>> 10440   0 144  90 thunk_64_push_pop.o
>>
>> Incidentally, this removes a bit of dead code:
>> one SAVE_ARGS was used just to emit a CFI annotation,
>> but it also generated unreachable assembly insns.
>>
>> Signed-off-by: Denys Vlasenko 
>> CC: Linus Torvalds 
>> CC: Oleg Nesterov 
>> CC: "H. Peter Anvin" 
>> CC: Borislav Petkov 
>> CC: Andy Lutomirski 
>> CC: Frederic Weisbecker 
>> CC: X86 ML 
>> CC: Alexei Starovoitov 
>> CC: Will Drewry 
>> CC: Kees Cook 
>> CC: linux-kernel@vger.kernel.org
>> ---
>>  arch/x86/lib/thunk_64.S | 46 ++
>>  1 file changed, 42 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/lib/thunk_64.S b/arch/x86/lib/thunk_64.S
>> index b30b5eb..8ec443a 100644
>> --- a/arch/x86/lib/thunk_64.S
>> +++ b/arch/x86/lib/thunk_64.S
>> @@ -17,9 +17,27 @@
>>   CFI_STARTPROC
>>
>>   /* this one pushes 9 elems, the next one would be %rIP */
>> - SAVE_ARGS
>> + pushq_cfi %rdi
>> + CFI_REL_OFFSET rdi, 0
>
> Btw, why the second CFI annotation?
>
> pushq_cfi does already CFI_ADJUST_CFA_OFFSET 8. Can't we use one and
> hide it in the macro?

By my imperfect understanding of CFI:

CFI_ADJUST_CFA_OFFSET means that the offset between rsp and the
"canonical frame address" is increased by 8 (because we just
subtracted 8 from rsp) and CFI_REL_OFFSET reg, 0 means that the
unwinder can find reg at offset 0 + (cfa offset here) from the CFA.

IOW, one is to keep the stack frame tracking consistent and the other
is to tell the unwinder about the register we just saved.

--Andy

>
> Btw, patch boots fine in the guest.
>
> --
> Regards/Gruss,
> Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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/4] x86: open-code register save/restore in trace_hardirqs thunks

[Denys Vlasenko]

On Sat, Jan 10, 2015 at 11:00 PM, Borislav Petkov  wrote:
>> --- a/arch/x86/lib/thunk_64.S
>> +++ b/arch/x86/lib/thunk_64.S
>> @@ -17,9 +17,27 @@
>>   CFI_STARTPROC
>>
>>   /* this one pushes 9 elems, the next one would be %rIP */
>> - SAVE_ARGS
>> + pushq_cfi %rdi
>> + CFI_REL_OFFSET rdi, 0
>
> Btw, why the second CFI annotation?
>
> pushq_cfi does already CFI_ADJUST_CFA_OFFSET 8. Can't we use one and
> hide it in the macro?

We probably should.

Since thunk_32.S uses the very same construct, I think it should be fixed
in both files by one patch.
--
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/4] x86: open-code register save/restore in trace_hardirqs thunks

[Borislav Petkov]

On Sat, Jan 10, 2015 at 09:14:03PM +0100, Denys Vlasenko wrote:
> From 2f636e0a92db898f2bdb592027aa302fcb32a326 Mon Sep 17 00:00:00 2001
> From: Denys Vlasenko 
> To: linux-kernel@vger.kernel.org
> Subject: [PATCH 3/4] x86: open-code register save/restore in trace_hardirqs 
> thunks
> 
> This is a preparatory patch for change in "struct pt_regs"
> handling in entry_64.S.
> 
> trace_hardirqs thunks were (ab)using a part of pt_regs
> handling code, namely SAVE_ARGS/RESTORE_ARGS macros,
> to save/restore registers across C function calls.
> 
> Since SAVE_ARGS is going to be changed, open-code
> register saving/restoring here. Take a page from thunk_32.S
> and use push/pop insns instead of movq, they are far shorter:
> 1 or 2 bytes versus 5, and no need for insns to adjust %rsp:
> 
>text  data bss dec hex filename
> 33340   0 373 175 thunk_64_movq.o
> 10440   0 144  90 thunk_64_push_pop.o
> 
> Incidentally, this removes a bit of dead code:
> one SAVE_ARGS was used just to emit a CFI annotation,
> but it also generated unreachable assembly insns.
> 
> Signed-off-by: Denys Vlasenko 
> CC: Linus Torvalds 
> CC: Oleg Nesterov 
> CC: "H. Peter Anvin" 
> CC: Borislav Petkov 
> CC: Andy Lutomirski 
> CC: Frederic Weisbecker 
> CC: X86 ML 
> CC: Alexei Starovoitov 
> CC: Will Drewry 
> CC: Kees Cook 
> CC: linux-kernel@vger.kernel.org
> ---
>  arch/x86/lib/thunk_64.S | 46 ++
>  1 file changed, 42 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/lib/thunk_64.S b/arch/x86/lib/thunk_64.S
> index b30b5eb..8ec443a 100644
> --- a/arch/x86/lib/thunk_64.S
> +++ b/arch/x86/lib/thunk_64.S
> @@ -17,9 +17,27 @@
>   CFI_STARTPROC
>  
>   /* this one pushes 9 elems, the next one would be %rIP */
> - SAVE_ARGS
> + pushq_cfi %rdi
> + CFI_REL_OFFSET rdi, 0

Btw, why the second CFI annotation?

pushq_cfi does already CFI_ADJUST_CFA_OFFSET 8. Can't we use one and
hide it in the macro?

Btw, patch boots fine in the guest.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/4] x86: entry_64.S: delete unused code

[Denys Vlasenko]

A define, two macros and an unreferenced bit of assembly are gone.

Signed-off-by: Denys Vlasenko 
Acked-by: Borislav Petkov 
CC: Linus Torvalds 
CC: Oleg Nesterov 
CC: "H. Peter Anvin" 
CC: Borislav Petkov 
CC: Andy Lutomirski 
CC: Frederic Weisbecker 
CC: X86 ML 
CC: Alexei Starovoitov 
CC: Will Drewry 
CC: Kees Cook 
CC: linux-kernel@vger.kernel.org
---
 arch/x86/include/asm/calling.h |  1 -
 arch/x86/kernel/entry_64.S | 34 --
 2 files changed, 35 deletions(-)

diff --git a/arch/x86/include/asm/calling.h b/arch/x86/include/asm/calling.h
index 76659b6..1f1297b 100644
--- a/arch/x86/include/asm/calling.h
+++ b/arch/x86/include/asm/calling.h
@@ -83,7 +83,6 @@ For 32-bit we have the following conventions - kernel is 
built with
 #define SS 160
 
 #define ARGOFFSET  R11
-#define SWFRAMEORIG_RAX
 
.macro SAVE_ARGS addskip=0, save_rcx=1, save_r891011=1, rax_enosys=0
subq  $9*8+\addskip, %rsp
diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 931f32f..5ed4773 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -155,27 +155,6 @@ ENDPROC(native_usergs_sysret64)
movq \tmp,R11+\offset(%rsp)
.endm
 
-   .macro FAKE_STACK_FRAME child_rip
-   /* push in order ss, rsp, eflags, cs, rip */
-   xorl %eax, %eax
-   pushq_cfi $__KERNEL_DS /* ss */
-   /*CFI_REL_OFFSETss,0*/
-   pushq_cfi %rax /* rsp */
-   CFI_REL_OFFSET  rsp,0
-   pushq_cfi $(X86_EFLAGS_IF|X86_EFLAGS_FIXED) /* eflags - interrupts on */
-   /*CFI_REL_OFFSETrflags,0*/
-   pushq_cfi $__KERNEL_CS /* cs */
-   /*CFI_REL_OFFSETcs,0*/
-   pushq_cfi \child_rip /* rip */
-   CFI_REL_OFFSET  rip,0
-   pushq_cfi %rax /* orig rax */
-   .endm
-
-   .macro UNFAKE_STACK_FRAME
-   addq $8*6, %rsp
-   CFI_ADJUST_CFA_OFFSET   -(6*8)
-   .endm
-
 /*
  * initial frame state for interrupts (and exceptions without error code)
  */
@@ -626,19 +605,6 @@ END(\label)
FORK_LIKE  vfork
FIXED_FRAME stub_iopl, sys_iopl
 
-ENTRY(ptregscall_common)
-   DEFAULT_FRAME 1 8   /* offset 8: return address */
-   RESTORE_TOP_OF_STACK %r11, 8
-   movq_cfi_restore R15+8, r15
-   movq_cfi_restore R14+8, r14
-   movq_cfi_restore R13+8, r13
-   movq_cfi_restore R12+8, r12
-   movq_cfi_restore RBP+8, rbp
-   movq_cfi_restore RBX+8, rbx
-   ret $REST_SKIP  /* pop extended registers */
-   CFI_ENDPROC
-END(ptregscall_common)
-
 ENTRY(stub_execve)
CFI_STARTPROC
addq $8, %rsp
-- 
1.8.1.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: [char-misc-next 3/3 V2] mei: add reference counting for me clients

[Winkler, Tomas]

> >
> > Signed-off-by: Tomas Winkler 
> 
> This patch adds build warnings, I can't take it:
> 
> drivers/misc/mei/bus.c: In function ‘___mei_cl_send’:
> drivers/misc/mei/bus.c:276:3: warning: ‘cb’ may be used uninitialized in this
> function [-Wmaybe-uninitialized]
>mei_io_cb_free(cb);
>^
> drivers/misc/mei/bus.c:273:2: warning: ‘me_cl’ may be used uninitialized in 
> this
> function [-Wmaybe-uninitialized]
>   mei_me_cl_put(me_cl);
>   ^

CONFIG_CC_OPTIMIZE_FOR_SIZE  is pushing -Wno-maybe-uninitialized so this didn't 
pop up. 
Resending 

Thanks
Tomas

[PATCH 3/4] x86: open-code register save/restore in trace_hardirqs thunks

[Denys Vlasenko]

This is a preparatory patch for change in "struct pt_regs"
handling in entry_64.S.

trace_hardirqs thunks were (ab)using a part of pt_regs
handling code, namely SAVE_ARGS/RESTORE_ARGS macros,
to save/restore registers across C function calls.

Since SAVE_ARGS is going to be changed, open-code
register saving/restoring here.

Incidentally, this removes a bit of dead code:
one SAVE_ARGS was used just to emit a CFI annotation,
but it also generated unreachable assembly insns.

Take a page from thunk_32.S and use push/pop insns
instead of movq, they are far shorter:
1 or 2 bytes versus 5, and no need for insns to adjust %rsp:

   textdata bss dec hex filename
333  40   0 373 175 thunk_64_movq.o
104  40   0 144  90 thunk_64_push_pop.o

Signed-off-by: Denys Vlasenko 
CC: Linus Torvalds 
CC: Oleg Nesterov 
CC: "H. Peter Anvin" 
CC: Borislav Petkov 
CC: Andy Lutomirski 
CC: Frederic Weisbecker 
CC: X86 ML 
CC: Alexei Starovoitov 
CC: Will Drewry 
CC: Kees Cook 
CC: linux-kernel@vger.kernel.org
---
 arch/x86/lib/thunk_64.S | 46 ++
 1 file changed, 42 insertions(+), 4 deletions(-)

diff --git a/arch/x86/lib/thunk_64.S b/arch/x86/lib/thunk_64.S
index b30b5eb..8ec443a 100644
--- a/arch/x86/lib/thunk_64.S
+++ b/arch/x86/lib/thunk_64.S
@@ -17,9 +17,27 @@
CFI_STARTPROC
 
/* this one pushes 9 elems, the next one would be %rIP */
-   SAVE_ARGS
+   pushq_cfi %rdi
+   CFI_REL_OFFSET rdi, 0
+   pushq_cfi %rsi
+   CFI_REL_OFFSET rsi, 0
+   pushq_cfi %rdx
+   CFI_REL_OFFSET rdx, 0
+   pushq_cfi %rcx
+   CFI_REL_OFFSET rcx, 0
+   pushq_cfi %rax
+   CFI_REL_OFFSET rax, 0
+   pushq_cfi %r8
+   CFI_REL_OFFSET r8, 0
+   pushq_cfi %r9
+   CFI_REL_OFFSET r9, 0
+   pushq_cfi %r10
+   CFI_REL_OFFSET r10, 0
+   pushq_cfi %r11
+   CFI_REL_OFFSET r11, 0
 
.if \put_ret_addr_in_rdi
+   /* 9*8(%rsp) is return addr on stack */
movq_cfi_restore 9*8, rdi
.endif
 
@@ -45,11 +63,31 @@
 #endif
 #endif
 
-   /* SAVE_ARGS below is used only for the .cfi directives it contains. */
+#if defined(CONFIG_TRACE_IRQFLAGS) \
+ || defined(CONFIG_DEBUG_LOCK_ALLOC) \
+ || defined(CONFIG_PREEMPT)
CFI_STARTPROC
-   SAVE_ARGS
+   CFI_ADJUST_CFA_OFFSET 9*8
 restore:
-   RESTORE_ARGS
+   popq_cfi %r11
+   CFI_RESTORE r11
+   popq_cfi %r10
+   CFI_RESTORE r10
+   popq_cfi %r9
+   CFI_RESTORE r9
+   popq_cfi %r8
+   CFI_RESTORE r8
+   popq_cfi %rax
+   CFI_RESTORE rax
+   popq_cfi %rcx
+   CFI_RESTORE rcx
+   popq_cfi %rdx
+   CFI_RESTORE rdx
+   popq_cfi %rsi
+   CFI_RESTORE rsi
+   popq_cfi %rdi
+   CFI_RESTORE rdi
ret
CFI_ENDPROC
_ASM_NOKPROBE(restore)
+#endif
-- 
1.8.1.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/

[PATCH 4/4] x86: entry_64.S: fold SAVE_ARGS_IRQ macro into its sole user

[Denys Vlasenko]

No code changes.

This is a preparatory patch for change in "struct pt_regs" handling.

Signed-off-by: Denys Vlasenko 
CC: Linus Torvalds 
CC: Oleg Nesterov 
CC: "H. Peter Anvin" 
CC: Borislav Petkov 
CC: Andy Lutomirski 
CC: Frederic Weisbecker 
CC: X86 ML 
CC: Alexei Starovoitov 
CC: Will Drewry 
CC: Kees Cook 
CC: linux-kernel@vger.kernel.org
---
 arch/x86/kernel/entry_64.S | 88 ++
 1 file changed, 42 insertions(+), 46 deletions(-)

diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
index 5ed4773..7d59df2 100644
--- a/arch/x86/kernel/entry_64.S
+++ b/arch/x86/kernel/entry_64.S
@@ -217,51 +217,6 @@ ENDPROC(native_usergs_sysret64)
CFI_REL_OFFSET r15, R15+\offset
.endm
 
-/* save partial stack frame */
-   .macro SAVE_ARGS_IRQ
-   cld
-   /* start from rbp in pt_regs and jump over */
-   movq_cfi rdi, (RDI-RBP)
-   movq_cfi rsi, (RSI-RBP)
-   movq_cfi rdx, (RDX-RBP)
-   movq_cfi rcx, (RCX-RBP)
-   movq_cfi rax, (RAX-RBP)
-   movq_cfi  r8,  (R8-RBP)
-   movq_cfi  r9,  (R9-RBP)
-   movq_cfi r10, (R10-RBP)
-   movq_cfi r11, (R11-RBP)
-
-   /* Save rbp so that we can unwind from get_irq_regs() */
-   movq_cfi rbp, 0
-
-   /* Save previous stack value */
-   movq %rsp, %rsi
-
-   leaq -RBP(%rsp),%rdi/* arg1 for handler */
-   testl $3, CS-RBP(%rsi)
-   je 1f
-   SWAPGS
-   /*
-* irq_count is used to check if a CPU is already on an interrupt stack
-* or not. While this is essentially redundant with preempt_count it is
-* a little cheaper to use a separate counter in the PDA (short of
-* moving irq_enter into assembly, which would be too much work)
-*/
-1: incl PER_CPU_VAR(irq_count)
-   cmovzq PER_CPU_VAR(irq_stack_ptr),%rsp
-   CFI_DEF_CFA_REGISTERrsi
-
-   /* Store previous stack value */
-   pushq %rsi
-   CFI_ESCAPE  0x0f /* DW_CFA_def_cfa_expression */, 6, \
-   0x77 /* DW_OP_breg7 */, 0, \
-   0x06 /* DW_OP_deref */, \
-   0x08 /* DW_OP_const1u */, SS+8-RBP, \
-   0x22 /* DW_OP_plus */
-   /* We entered an interrupt context - irqs are off: */
-   TRACE_IRQS_OFF
-   .endm
-
 ENTRY(save_paranoid)
XCPT_FRAME 1 RDI+8
cld
@@ -745,7 +700,48 @@ END(interrupt)
/* reserve pt_regs for scratch regs and rbp */
subq $ORIG_RAX-RBP, %rsp
CFI_ADJUST_CFA_OFFSET ORIG_RAX-RBP
-   SAVE_ARGS_IRQ
+   cld
+   /* start from rbp in pt_regs and jump over */
+   movq_cfi rdi, (RDI-RBP)
+   movq_cfi rsi, (RSI-RBP)
+   movq_cfi rdx, (RDX-RBP)
+   movq_cfi rcx, (RCX-RBP)
+   movq_cfi rax, (RAX-RBP)
+   movq_cfi  r8,  (R8-RBP)
+   movq_cfi  r9,  (R9-RBP)
+   movq_cfi r10, (R10-RBP)
+   movq_cfi r11, (R11-RBP)
+
+   /* Save rbp so that we can unwind from get_irq_regs() */
+   movq_cfi rbp, 0
+
+   /* Save previous stack value */
+   movq %rsp, %rsi
+
+   leaq -RBP(%rsp),%rdi/* arg1 for handler */
+   testl $3, CS-RBP(%rsi)
+   je 1f
+   SWAPGS
+   /*
+* irq_count is used to check if a CPU is already on an interrupt stack
+* or not. While this is essentially redundant with preempt_count it is
+* a little cheaper to use a separate counter in the PDA (short of
+* moving irq_enter into assembly, which would be too much work)
+*/
+1: incl PER_CPU_VAR(irq_count)
+   cmovzq PER_CPU_VAR(irq_stack_ptr),%rsp
+   CFI_DEF_CFA_REGISTERrsi
+
+   /* Store previous stack value */
+   pushq %rsi
+   CFI_ESCAPE  0x0f /* DW_CFA_def_cfa_expression */, 6, \
+   0x77 /* DW_OP_breg7 */, 0, \
+   0x06 /* DW_OP_deref */, \
+   0x08 /* DW_OP_const1u */, SS+8-RBP, \
+   0x22 /* DW_OP_plus */
+   /* We entered an interrupt context - irqs are off: */
+   TRACE_IRQS_OFF
+
call \func
.endm
 
-- 
1.8.1.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/

[PATCH 0/4 v2] x86: entry.S cleanup

[Denys Vlasenko]

This is the first part of a bigger patch set I posted last August,
then under title of "x86: entry.S optimizations".

I fully rebased that patch set to Linus tree, but currently
Linus and -next are diverging a bit in arch/x86/kernel/entry_64.S

To make it easier for mainteiners, I'm splitting the old patch set
into more digestible parts.

This is the first set. These four patches apply both to Linus and -next.
They do not contain any substantial code changes.
Patches 2 and 4 don't result in any actual code changes.

Changes since v1:
Patch #3 had a bug.

CC: Linus Torvalds 
CC: Oleg Nesterov 
CC: "H. Peter Anvin" 
CC: Borislav Petkov 
CC: Andy Lutomirski 
CC: Frederic Weisbecker 
CC: X86 ML 
CC: Alexei Starovoitov 
CC: Will Drewry 
CC: Kees Cook 
CC: linux-kernel@vger.kernel.org

Denys Vlasenko (4):
  x86: entry_64.S: delete unused code
  x86: ia32entry.S: fix wrong symbolic constant usage: R11->ARGOFFSET
  x86: open-code register save/restore in trace_hardirqs thunks
  x86: entry_64.S: fold SAVE_ARGS_IRQ macro into its sole user

 arch/x86/ia32/ia32entry.S  |   4 +-
 arch/x86/include/asm/calling.h |   1 -
 arch/x86/kernel/entry_64.S | 122 ++---
 arch/x86/lib/thunk_64.S|  29 --
 4 files changed, 68 insertions(+), 88 deletions(-)

-- 
1.8.1.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/

[PATCH 2/4] x86: ia32entry.S: fix wrong symbolic constant usage: R11->ARGOFFSET

[Denys Vlasenko]

The values of these two constants are the same, the meaning is different.

Signed-off-by: Denys Vlasenko 
Acked-by: Borislav Petkov 
CC: Linus Torvalds 
CC: Oleg Nesterov 
CC: "H. Peter Anvin" 
CC: Borislav Petkov 
CC: Andy Lutomirski 
CC: Frederic Weisbecker 
CC: X86 ML 
CC: Alexei Starovoitov 
CC: Will Drewry 
CC: Kees Cook 
CC: linux-kernel@vger.kernel.org
---
 arch/x86/ia32/ia32entry.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S
index 82e8a1d..156ebca 100644
--- a/arch/x86/ia32/ia32entry.S
+++ b/arch/x86/ia32/ia32entry.S
@@ -179,8 +179,8 @@ sysenter_dispatch:
 sysexit_from_sys_call:
andl$~TS_COMPAT,TI_status+THREAD_INFO(%rsp,RIP-ARGOFFSET)
/* clear IF, that popfq doesn't enable interrupts early */
-   andl  $~0x200,EFLAGS-R11(%rsp) 
-   movlRIP-R11(%rsp),%edx  /* User %eip */
+   andl$~0x200,EFLAGS-ARGOFFSET(%rsp)
+   movlRIP-ARGOFFSET(%rsp),%edx/* User %eip */
CFI_REGISTER rip,rdx
RESTORE_ARGS 0,24,0,0,0,0
xorq%r8,%r8
-- 
1.8.1.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 3/4] x86: open-code register save/restore in trace_hardirqs thunks

[Denys Vlasenko]

On Sat, Jan 10, 2015 at 10:27 PM, Linus Torvalds
 wrote:
> On Sat, Jan 10, 2015 at 1:09 PM, Denys Vlasenko
>  wrote:
>>
>> I think using push/pop is okay. In the very hottest code paths
>> you may want to prefer mov's.
>
> For kernel entrypoints in particular, the code sequence is quite
> possibly constrained by the decoder and instruction fetch rather than
> the execution engine. Even if the entrypoint were to be in the L1 I$
> (which is not generally the case except in microbenchmarks), I am
> pretty sure that even Intel doesn't actually speculatively decode
> across system call boundaries, so unlike normal nice code, you don't
> have the front end running ahead of the execution engine.
>
> Looking at the system call hotpath, for example, it looks like we
> save/restore 8 registers. So 16 instructions or about 80 bytes of
> code. I could easily imagine us avoiding one cacheline access by using
> shorter 1- and 2-byte push/pop instructions (depending a bit on how
> the cacheline alignment works out, of course).
>
> Depending on how well it prefetches from L2 and/or exact decoder
> details, that kind of issue *can* overshadow the actual execution
> costs. Of course, on microbenchmarks (eg some system call benchmark
> that does "getppid()" in a loop), even the kernel side stays in the
> L1, so those might show possible execution issues more. And
> macrobenchmarks probably won't show a cycle or two in the system call
> or fault path anyway.
>
> Linus

Looks like consensus to me. I'm resending patches with patch #3 reworked.
--
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 07/16] ARM: integrator: convert PCI to use generic config accesses

[Arnd Bergmann]

On Saturday 10 January 2015 22:40:22 Linus Walleij wrote:
> >  static int v3_read_config(struct pci_bus *bus, unsigned int devfn, int 
> > where,
> >   int size, u32 *val)
> >  {
> > -   addr = v3_open_config_window(bus, devfn, where);
> > +   int ret = pci_generic_config_read(bus, devfn, where, size, val);
> > v3_close_config_window();
> > +   return ret;
> >  }
> >
> >  static int v3_write_config(struct pci_bus *bus, unsigned int devfn, int 
> > where,
> >int size, u32 val)
> >  {
> > +   int ret = pci_generic_config_write(bus, devfn, where, size, val);
> > v3_close_config_window();
> > -   raw_spin_unlock_irqrestore(_lock, flags);
> > +   return ret;
> >  }
> >
> >  static struct pci_ops pci_v3_ops = {
> > +   .map_bus = v3_open_config_window,
> > .read   = v3_read_config,
> > .write  = v3_write_config,
> 
> So .map_bus is called before every .read/.write operation I take it.
> 
> Wouldn't it be proper to call the v3_close_config_window() from a
> matching .unmap_bus() callback for symmetry?

It would be nicer for integrator but useless for anything else, so
I'd vote for leaving it the way Rob posted.

Arnd
--
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 v2] UBI: Add initial support for scatter gather

[Richard Weinberger]

Adds a new set of functions to deal with scatter gather.
ubi_eba_read_leb_sg() will read from a LEB into a scatter gather list.
The new data structure struct ubi_sgl will be used within UBI to
hold the scatter gather list itself and metadata to have a cursor
within the list.

Signed-off-by: Richard Weinberger 
Tested-by: Ezequiel Garcia 
---
 drivers/mtd/ubi/eba.c   | 56 +
 drivers/mtd/ubi/kapi.c  | 95 +
 drivers/mtd/ubi/ubi.h   |  3 ++
 include/linux/mtd/ubi.h | 46 
 4 files changed, 185 insertions(+), 15 deletions(-)

diff --git a/drivers/mtd/ubi/eba.c b/drivers/mtd/ubi/eba.c
index b698534..0aaf707 100644
--- a/drivers/mtd/ubi/eba.c
+++ b/drivers/mtd/ubi/eba.c
@@ -481,6 +481,62 @@ out_unlock:
 }
 
 /**
+ * ubi_eba_read_leb_sg - read data into a scatter gather list.
+ * @ubi: UBI device description object
+ * @vol: volume description object
+ * @lnum: logical eraseblock number
+ * @sgl: UBI scatter gather list to store the read data
+ * @offset: offset from where to read
+ * @len: how many bytes to read
+ * @check: data CRC check flag
+ *
+ * This function works exactly like ubi_eba_read_leb(). But instead of
+ * storing the read data into a buffer it writes to an UBI scatter gather
+ * list.
+ */
+int ubi_eba_read_leb_sg(struct ubi_device *ubi, struct ubi_volume *vol,
+   struct ubi_sgl *sgl, int lnum, int offset, int len,
+   int check)
+{
+   int to_read;
+   int ret;
+   struct scatterlist *sg;
+
+   for (;;) {
+   ubi_assert(sgl->list_pos < UBI_MAX_SG_COUNT);
+   sg = >sg[sgl->list_pos];
+   if (len < sg->length - sgl->page_pos)
+   to_read = len;
+   else
+   to_read = sg->length - sgl->page_pos;
+
+   ret = ubi_eba_read_leb(ubi, vol, lnum,
+  sg_virt(sg) + sgl->page_pos, offset,
+  to_read, check);
+   if (ret < 0)
+   goto out;
+
+   offset += to_read;
+   len -= to_read;
+   if (!len) {
+   sgl->page_pos += to_read;
+   if (sgl->page_pos == sg->length) {
+   sgl->list_pos++;
+   sgl->page_pos = 0;
+   }
+
+   break;
+   }
+
+   sgl->list_pos++;
+   sgl->page_pos = 0;
+   }
+
+out:
+   return ret;
+}
+
+/**
  * recover_peb - recover from write failure.
  * @ubi: UBI device description object
  * @pnum: the physical eraseblock to recover
diff --git a/drivers/mtd/ubi/kapi.c b/drivers/mtd/ubi/kapi.c
index f3bab66..d0055a2 100644
--- a/drivers/mtd/ubi/kapi.c
+++ b/drivers/mtd/ubi/kapi.c
@@ -355,6 +355,43 @@ void ubi_close_volume(struct ubi_volume_desc *desc)
 EXPORT_SYMBOL_GPL(ubi_close_volume);
 
 /**
+ * leb_read_sanity_check - does sanity checks on read requests.
+ * @desc: volume descriptor
+ * @lnum: logical eraseblock number to read from
+ * @offset: offset within the logical eraseblock to read from
+ * @len: how many bytes to read
+ *
+ * This function is used by ubi_leb_read() and ubi_leb_read_sg()
+ * to perfrom sanity checks.
+ */
+static int leb_read_sanity_check(struct ubi_volume_desc *desc, int lnum,
+int offset, int len)
+{
+   struct ubi_volume *vol = desc->vol;
+   struct ubi_device *ubi = vol->ubi;
+   int vol_id = vol->vol_id;
+
+   if (vol_id < 0 || vol_id >= ubi->vtbl_slots || lnum < 0 ||
+   lnum >= vol->used_ebs || offset < 0 || len < 0 ||
+   offset + len > vol->usable_leb_size)
+   return -EINVAL;
+
+   if (vol->vol_type == UBI_STATIC_VOLUME) {
+   if (vol->used_ebs == 0)
+   /* Empty static UBI volume */
+   return 0;
+   if (lnum == vol->used_ebs - 1 &&
+   offset + len > vol->last_eb_bytes)
+   return -EINVAL;
+   }
+
+   if (vol->upd_marker)
+   return -EBADF;
+
+   return 0;
+}
+
+/**
  * ubi_leb_read - read data.
  * @desc: volume descriptor
  * @lnum: logical eraseblock number to read from
@@ -390,22 +427,10 @@ int ubi_leb_read(struct ubi_volume_desc *desc, int lnum, 
char *buf, int offset,
 
dbg_gen("read %d bytes from LEB %d:%d:%d", len, vol_id, lnum, offset);
 
-   if (vol_id < 0 || vol_id >= ubi->vtbl_slots || lnum < 0 ||
-   lnum >= vol->used_ebs || offset < 0 || len < 0 ||
-   offset + len > vol->usable_leb_size)
-   return -EINVAL;
-
-   if (vol->vol_type == UBI_STATIC_VOLUME) {
-   if (vol->used_ebs == 0)
-   /* Empty static UBI volume */
-   return 0;
-   if (lnum == vol->used_ebs - 1 &&
-  

[PATCH 2/2 v2] UBI: Block: Add blk-mq support

[Richard Weinberger]

Convert the driver to blk-mq.
Beside of moving to the modern block interface this change boosts
also the performance of the driver.

nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron NAND 256MiB 3,3V 8-bit
nand: 256MiB, SLC, page size: 2048, OOB size: 64

root@debian-armhf:~# dd if=/dev/ubiblock0_0 of=/dev/zero bs=1M
243+1 records in
243+1 records out
255080448 bytes (255 MB) copied, 4.39295 s, 58.1 MB/s

vs.

root@debian-armhf:~# dd if=/dev/ubiblock0_0 of=/dev/zero bs=1M
243+1 records in
243+1 records out
255080448 bytes (255 MB) copied, 2.87676 s, 88.7 MB/s

Cc: h...@infradead.org
Cc: ax...@fb.com
Cc: tom.leim...@gmail.com
Signed-off-by: Richard Weinberger 
Tested-by: Ezequiel Garcia 
---
 drivers/mtd/ubi/block.c | 202 ++--
 1 file changed, 94 insertions(+), 108 deletions(-)

diff --git a/drivers/mtd/ubi/block.c b/drivers/mtd/ubi/block.c
index 6b6bce2..00caf46 100644
--- a/drivers/mtd/ubi/block.c
+++ b/drivers/mtd/ubi/block.c
@@ -42,11 +42,12 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 
 #include "ubi-media.h"
@@ -67,6 +68,11 @@ struct ubiblock_param {
char name[UBIBLOCK_PARAM_LEN+1];
 };
 
+struct ubiblock_pdu {
+   struct work_struct work;
+   struct ubi_sgl usgl;
+};
+
 /* Numbers of elements set in the @ubiblock_param array */
 static int ubiblock_devs __initdata;
 
@@ -84,11 +90,10 @@ struct ubiblock {
struct request_queue *rq;
 
struct workqueue_struct *wq;
-   struct work_struct work;
 
struct mutex dev_mutex;
-   spinlock_t queue_lock;
struct list_head list;
+   struct blk_mq_tag_set tag_set;
 };
 
 /* Linked list of all ubiblock instances */
@@ -181,31 +186,20 @@ static struct ubiblock *find_dev_nolock(int ubi_num, int 
vol_id)
return NULL;
 }
 
-static int ubiblock_read_to_buf(struct ubiblock *dev, char *buffer,
-   int leb, int offset, int len)
+static int ubiblock_read(struct ubiblock_pdu *pdu)
 {
-   int ret;
+   int ret, leb, offset, bytes_left, to_read;
+   u64 pos;
+   struct request *req = blk_mq_rq_from_pdu(pdu);
+   struct ubiblock *dev = req->q->queuedata;
 
-   ret = ubi_read(dev->desc, leb, buffer, offset, len);
-   if (ret) {
-   dev_err(disk_to_dev(dev->gd), "%d while reading from LEB %d 
(offset %d, length %d)",
-   ret, leb, offset, len);
-   return ret;
-   }
-   return 0;
-}
-
-static int ubiblock_read(struct ubiblock *dev, char *buffer,
-sector_t sec, int len)
-{
-   int ret, leb, offset;
-   int bytes_left = len;
-   int to_read = len;
-   u64 pos = sec << 9;
+   to_read = blk_rq_bytes(req);
+   pos = blk_rq_pos(req) << 9;
 
/* Get LEB:offset address to read from */
offset = do_div(pos, dev->leb_size);
leb = pos;
+   bytes_left = to_read;
 
while (bytes_left) {
/*
@@ -215,11 +209,10 @@ static int ubiblock_read(struct ubiblock *dev, char 
*buffer,
if (offset + to_read > dev->leb_size)
to_read = dev->leb_size - offset;
 
-   ret = ubiblock_read_to_buf(dev, buffer, leb, offset, to_read);
-   if (ret)
+   ret = ubi_read_sg(dev->desc, leb, >usgl, offset, to_read);
+   if (ret < 0)
return ret;
 
-   buffer += to_read;
bytes_left -= to_read;
to_read = bytes_left;
leb += 1;
@@ -228,79 +221,6 @@ static int ubiblock_read(struct ubiblock *dev, char 
*buffer,
return 0;
 }
 
-static int do_ubiblock_request(struct ubiblock *dev, struct request *req)
-{
-   int len, ret;
-   sector_t sec;
-
-   if (req->cmd_type != REQ_TYPE_FS)
-   return -EIO;
-
-   if (blk_rq_pos(req) + blk_rq_cur_sectors(req) >
-   get_capacity(req->rq_disk))
-   return -EIO;
-
-   if (rq_data_dir(req) != READ)
-   return -ENOSYS; /* Write not implemented */
-
-   sec = blk_rq_pos(req);
-   len = blk_rq_cur_bytes(req);
-
-   /*
-* Let's prevent the device from being removed while we're doing I/O
-* work. Notice that this means we serialize all the I/O operations,
-* but it's probably of no impact given the NAND core serializes
-* flash access anyway.
-*/
-   mutex_lock(>dev_mutex);
-   ret = ubiblock_read(dev, bio_data(req->bio), sec, len);
-   mutex_unlock(>dev_mutex);
-
-   return ret;
-}
-
-static void ubiblock_do_work(struct work_struct *work)
-{
-   struct ubiblock *dev =
-   container_of(work, struct ubiblock, work);
-   struct request_queue *rq = dev->rq;
-   struct request *req;
-   int res;
-
-   spin_lock_irq(rq->queue_lock);
-
-   req = 

Re: [PATCH 2/2] UBI: Block: Add blk-mq support

[Richard Weinberger]

Am 10.01.2015 um 19:58 schrieb Christoph Hellwig:
>> +struct ubiblock_pdu {
>> +struct request *req;
> 
> No need to store the request, you can trivially get at it using
> blk_mq_rq_from_pdu().

Very handy, I was not aware of blk_mq_rq_from_pdu().

>> +struct ubiblock *dev;
> 
> Why do you need the dev pointer?  You can always trivially get
> it using req->queuedata.

Same here.

>> +static void ubiblock_do_work(struct work_struct *work)
>> +{
>> +int ret;
>> +struct ubiblock_pdu *pdu = container_of(work, struct ubiblock_pdu, 
>> work);
>> +
>> +ret = ubiblock_read(pdu);
>> +blk_mq_end_request(pdu->req, ret ?: 0);
> 
> Why not just pass ret as-is?

Obviously a brain fart. :-\

>> +if (blk_rq_pos(req) + blk_rq_cur_sectors(req) >
>> +get_capacity(req->rq_disk))
>> +return BLK_MQ_RQ_QUEUE_ERROR;
> 
> The upper layers take are of this check.

Ok.

>> +pdu->usgl.list_pos = 0;
>> +pdu->usgl.page_pos = 0;
> 
> Having a helper to initialize a ubi_sgl would be nicer than having
> to open code it ike here.

Ok.

>> +
>> +blk_mq_start_request(req);
>> +ret = blk_rq_map_sg(hctx->queue, req, pdu->usgl.sg);
>> +
>> +queue_work(dev->wq, >work);
> 
> Why don't you move these calls into the work queue as well?  The
> queue_rq call would literally just become a queue_work call.

I did not know that I'm allowed to get hctx->queue also via req->q.

> And given that this is a fairly common patter this should allow
> us to refactor / optimize this case a bit later on.

Will send a v2 in a jiffy!

Thanks,
//richard
--
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] pinctrl: pass -DDEBUG in subdirs

[Linus Walleij]

When drivers are compiled in subdirectories the -DDEBUG flag need
to be passed in the individual Makefiles.

Reported-by: Mika Westerberg 
Suggested-by: Yingjoe Chen 
Cc: Mika Westerberg 
Signed-off-by: Linus Walleij 
---
This replaces Mika's patch too.
---
 drivers/pinctrl/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index c030b3db8034..c7139ba195fe 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -1,6 +1,6 @@
 # generic pinmux support
 
-ccflags-$(CONFIG_DEBUG_PINCTRL)+= -DDEBUG
+subdir-ccflags-$(CONFIG_DEBUG_PINCTRL) += -DDEBUG
 
 obj-$(CONFIG_PINCTRL)  += core.o pinctrl-utils.o
 obj-$(CONFIG_PINMUX)   += pinmux.o
-- 
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/

Re: [BUG] 3.19-rc1 net: less interrupt masking in NAPI

[Eric Dumazet]

On Sat, 2015-01-10 at 23:30 +0200, Oded Gabbay wrote:

> Yes, no problem.
> I will update on the result.

Please try this more complete patch, solving the TX pressure problem as
well, and not lying about NAPI budget. thanks !


diff --git a/drivers/net/ethernet/atheros/alx/main.c 
b/drivers/net/ethernet/atheros/alx/main.c
index e398eda07298..5f05b387c0a7 100644
--- a/drivers/net/ethernet/atheros/alx/main.c
+++ b/drivers/net/ethernet/atheros/alx/main.c
@@ -184,15 +184,16 @@ static void alx_schedule_reset(struct alx_priv *alx)
schedule_work(>reset_wk);
 }
 
-static bool alx_clean_rx_irq(struct alx_priv *alx, int budget)
+static int alx_clean_rx_irq(struct alx_priv *alx, int budget)
 {
struct alx_rx_queue *rxq = >rxq;
struct alx_rrd *rrd;
struct alx_buffer *rxb;
struct sk_buff *skb;
u16 length, rfd_cleaned = 0;
+   int work = 0;
 
-   while (budget > 0) {
+   while (work < budget) {
rrd = >rrd[rxq->rrd_read_idx];
if (!(rrd->word3 & cpu_to_le32(1 << RRD_UPDATED_SHIFT)))
break;
@@ -243,7 +244,7 @@ static bool alx_clean_rx_irq(struct alx_priv *alx, int 
budget)
}
 
napi_gro_receive(>napi, skb);
-   budget--;
+   work++;
 
 next_pkt:
if (++rxq->read_idx == alx->rx_ringsz)
@@ -258,21 +259,22 @@ next_pkt:
if (rfd_cleaned)
alx_refill_rx_ring(alx, GFP_ATOMIC);
 
-   return budget > 0;
+   return work;
 }
 
 static int alx_poll(struct napi_struct *napi, int budget)
 {
struct alx_priv *alx = container_of(napi, struct alx_priv, napi);
struct alx_hw *hw = >hw;
-   bool complete = true;
unsigned long flags;
+   bool tx_complete;
+   int work;
 
-   complete = alx_clean_tx_irq(alx) &&
-  alx_clean_rx_irq(alx, budget);
+   tx_complete = alx_clean_tx_irq(alx);
+   work = alx_clean_rx_irq(alx, budget);
 
-   if (!complete)
-   return 1;
+   if (!tx_complete || work == budget)
+   return budget;
 
napi_complete(>napi);
 
@@ -284,7 +286,7 @@ static int alx_poll(struct napi_struct *napi, int budget)
 
alx_post_write(hw);
 
-   return 0;
+   return work;
 }
 
 static irqreturn_t alx_intr_handle(struct alx_priv *alx, u32 intr)


--
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: Linux 3.19-rc3

[Linus Torvalds]

On Sat, Jan 10, 2015 at 1:36 PM, Arnd Bergmann  wrote:
>>
>>  (d) the powerpc TLB fill/buildup/teardown costs are horrible, so on
>> AIX the cost of lots of small pages is much higher too.
>
> I think (d) applies to ARM as well, since it has no hardware
> dirty/referenced bit tracking and requires the OS to mark the
> pages as invalid/readonly until the first access. ARMv8.1
> has a fix for that, but it's optional and we haven't seen any
> implementations yet.

Powerpc really makes things worse by having those hashed page tables
that (a) have bad locality and (b) have to be built up and torn down
in software. I don't think ARM ends up coming close, even with the
issues it has.

Now, it's definitely true that the x86 page table handling hadrware
tends to just be superior. Both Intel and AMD had to work really hard
on it, because Windows (in the pre-NT days) used to flush the TLB
absolutely _all_ the time.  So x86 hardware really does tend to do
very well on this.

ARM simply doesn't have the same kind of history. TLB issues seldom
show up very much on simple benchmarks or on smaller loads. It's one
of those things that tends to take a couple of generations.

[ Or, sadly, _much_ more, because some hardware designers never get
the memo, and continue to blame software and say "you should use big
pages", because they don't see the problems ]

Of course, it's entirely possible that vendors like AMD coudl transfer
their TLB handling know-how to their ARM64 cores. I have no visibility
into that, maybe some people here do..

  Linus
--
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] pinctrl: pass -DDEBUG in subdirs

[Linus Walleij]

On Fri, Jan 9, 2015 at 11:22 AM, Yingjoe Chen  wrote:
>
> On Fri, 2015-01-09 at 10:41 +0100, Linus Walleij wrote:
>> When drivers are compiled in subdirectories the -DDEBUG flag need
>> to be passed in the individual Makefiles.
>
> Hi,
>
> It will be easy to forget adding this when adding new subdirectories.
> Can we do this instead?
(...)
> -ccflags-$(CONFIG_DEBUG_PINCTRL)+= -DDEBUG
> +subdir-ccflags-$(CONFIG_DEBUG_PINCTRL) += -DDEBUG

Yeah of course :/

subdir-ccflags applies to this subdir and all below it then I take it.
Typical I don't know such stuff :(

Yours,
Linus Walleij
--
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: [BUG] 3.19-rc1 net: less interrupt masking in NAPI

[Oded Gabbay]

On 01/10/2015 11:30 PM, Oded Gabbay wrote:
> 
> 
> On 01/10/2015 10:58 PM, Eric Dumazet wrote:
>> On Sat, 2015-01-10 at 22:39 +0200, Oded Gabbay wrote:
>>> Hi,
>>>
>>> Commit d75b1ade567ffab085e8adbbdacf0092d10cd09c breaks my "Qualcomm Atheros
>>> AR8161 Gigabit Ethernet (rev 10)" Ethernet controller, which is handled by
>>> the alx network driver.
>>>
>>> ogabbay@odedg-ubuntu:~$ lspci -s 01:00.0 -k
>>> 01:00.0 Ethernet controller:
>>> Qualcomm Atheros AR8161 Gigabit Ethernet (rev 10)
>>> Subsystem: Qualcomm Atheros Device 1071
>>> Kernel driver in use: alx
>>>
>>> I have this controller on a mobile platform of AMD APU Kaveri, which I use
>>> to test amdkfd, and from 3.19-rc1 the network stopped working when trying to
>>> transfer files through scp or nfs.
>>>
>>> I bisected the kernel (from 3.18.0 to 3.19-rc1) and reached this commit.
>>>
>>> Here is the log of the bisect:
>>>
>>> git bisect start
>>> # bad: [97bf6af1f928216fd6c5a66e8a57bfa95a659672] Linux 3.19-rc1
>>> git bisect bad 97bf6af1f928216fd6c5a66e8a57bfa95a659672
>>>
>>> # good: [b2776bf7149bddd1f4161f14f79520f17fc1d71d] Linux 3.18
>>> git bisect good b2776bf7149bddd1f4161f14f79520f17fc1d71d
>>>
>>> # bad: [70e71ca0af244f48a5dcf56dc435243792e3a495] Merge
>>> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
>>> git bisect bad 70e71ca0af244f48a5dcf56dc435243792e3a495
>>>
>>> # good: [e28870f9b3e92cd3570925089c6bb789c2603bc4] Merge tag
>>> 'backlight-for-linus-3.19' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight
>>> git bisect good e28870f9b3e92cd3570925089c6bb789c2603bc4
>>>
>>> # bad: [450fa21942fe2c37f0c9f52d1a33bbc081eee288] sh_eth: Remove redundant
>>> alignment adjustment
>>> git bisect bad 450fa21942fe2c37f0c9f52d1a33bbc081eee288
>>>
>>> # bad: [5c8d19da950861d0482abc0ac3481acca34b008f] e100e: use
>>> netdev_rss_key_fill() helper
>>> git bisect bad 5c8d19da950861d0482abc0ac3481acca34b008f
>>>
>>> # good: [bf515fb11ab539c76d04f0e3c5216ed41f41d81f] Merge tag
>>> 'mac80211-next-for-john-2014-11-04' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next
>>> git bisect good bf515fb11ab539c76d04f0e3c5216ed41f41d81f
>>>
>>> # bad: [2c99cd914d4fed9160d98849c9dd38034616768e] Merge branch 
>>> 'amd-xgbe-next'
>>> git bisect bad 2c99cd914d4fed9160d98849c9dd38034616768e
>>>
>>> # good: [3d762a0f0ab9cb4a6b5993db3ce56c92f9f90ab2] net: dsa: Add support for
>>> reading switch registers with ethtool
>>> git bisect good 3d762a0f0ab9cb4a6b5993db3ce56c92f9f90ab2
>>>
>>> # bad: [8ce0c8254f15229aa99fc6c04141f28c446e5f8c] Merge branch 'master' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next
>>> git bisect bad 8ce0c8254f15229aa99fc6c04141f28c446e5f8c
>>>
>>> # good: [f0c65567b3c1b23f79e8a49139580a3872a68d1f] Merge branch
>>> 'sunvnet-multi-tx-queue'
>>> git bisect good f0c65567b3c1b23f79e8a49139580a3872a68d1f
>>>
>>> # bad: [547f2735c20023d7b50a791b1b17cacb652e9237] Merge branch 'mlx4-next'
>>> git bisect bad 547f2735c20023d7b50a791b1b17cacb652e9237
>>>
>>> # good: [4cdb1e2e3d3495423db558d3bb7ed11d66aabce7] net: shrink struct
>>> softnet_data
>>> git bisect good 4cdb1e2e3d3495423db558d3bb7ed11d66aabce7
>>>
>>> # bad: [0a98455666ec87378148a1dde97f1ce5baf75a64] net/mlx4_core: Protect
>>> port type setting by mutex
>>> git bisect bad 0a98455666ec87378148a1dde97f1ce5baf75a64
>>>
>>> # bad: [6e8066999800d90d52af5c84ac49ebf683d14cdc] net/mlx4_core: Prevent VF
>>> from changing port configuration
>>> git bisect bad 6e8066999800d90d52af5c84ac49ebf683d14cdc
>>>
>>> # bad: [d75b1ade567ffab085e8adbbdacf0092d10cd09c] net: less interrupt
>>> masking in NAPI
>>> git bisect bad d75b1ade567ffab085e8adbbdacf0092d10cd09c
>>>
>>> # first bad commit: [d75b1ade567ffab085e8adbbdacf0092d10cd09c]
>>> net: less interrupt masking in NAPI
>>>
>>> Could you please solve this issue as it renders my board quite useless.
>>>
>>
>> Thanks for the report and bisection !
>>
>> Could you try following fix ?
>>
>> diff --git a/drivers/net/ethernet/atheros/alx/main.c 
>> b/drivers/net/ethernet/atheros/alx/main.c
>> index e398eda07298..209c40765e0d 100644
>> --- a/drivers/net/ethernet/atheros/alx/main.c
>> +++ b/drivers/net/ethernet/atheros/alx/main.c
>> @@ -272,7 +272,7 @@ static int alx_poll(struct napi_struct *napi, int budget)
>> alx_clean_rx_irq(alx, budget);
>>  
>>  if (!complete)
>> -return 1;
>> +return budget;
>>  
>>  napi_complete(>napi);
>>  
>>
>>
>>
>>
> Yes, no problem.
> I will update on the result.
> 
>   Oded
> --
> 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/
> 

Hi Eric,
Your patch fixed the problem.
Thanks for the quick help!

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

[PATCH cgroup/for-3.19-fixes] cgroup: implement cgroup_subsys->unbind() callback

[Tejun Heo]

Currently, if a hierarchy doesn't have any live children when it's
unmounted, the hierarchy starts dying by killing its refcnt.  The
expectation is that even if there are lingering dead children which
are lingering due to remaining references, they'll be put in a finite
amount of time.  When the children are finally released, the hierarchy
is destroyed and all controllers bound to it also are released.

However, for memcg, the premise that the lingering refs will be put in
a finite amount time is not true.  In the absense of memory pressure,
dead memcg's may hang around indefinitely pinned by its pages.  This
unfortunately may lead to indefinite hang on the next mount attempt
involving memcg as the mount logic waits for it to get released.

While we can change hierarchy destruction logic such that a hierarchy
is only destroyed when it's not mounted anywhere and all its children,
live or dead, are gone, this makes whether the hierarchy gets
destroyed or not to be determined by factors opaque to userland.
Userland may or may not get a new hierarchy on the next mount attempt.
Worse, if it explicitly wants to create a new hierarchy with different
options or controller compositions involving memcg, it will fail in an
essentially arbitrary manner.

We want to guarantee that a hierarchy is destroyed once the
conditions, unmounted and no visible children, are met.  To aid it,
this patch introduces a new callback cgroup_subsys->unbind() which is
invoked right before the hierarchy a subsystem is bound to starts
dying.  memcg can implement this callback and initiate draining of
remaining refs so that the hierarchy can eventually be released in a
finite amount of time.

Signed-off-by: Tejun Heo 
Cc: Li Zefan 
Cc: Johannes Weiner 
Cc: Michal Hocko 
Cc: Vladimir Davydov 
---
Hello,

> May be, we should kill the ref counter to the memory controller root in
> cgroup_kill_sb only if there is no children at all, neither online nor
> offline.

Ah, thanks for the analysis, but I really wanna avoid making hierarchy
destruction conditions opaque to userland.  This is userland visible
behavior.  It shouldn't be determined by kernel internals invisible
outside.  This patch adds ss->unbind() which memcg can hook into to
kick off draining of residual refs.  If this would work, I'll add this
patch to cgroup/for-3.19-fixes, possibly with stable cc'd.

Thanks.

 Documentation/cgroups/cgroups.txt |   12 +++-
 include/linux/cgroup.h|1 +
 kernel/cgroup.c   |   14 --
 3 files changed, 24 insertions(+), 3 deletions(-)

--- a/Documentation/cgroups/cgroups.txt
+++ b/Documentation/cgroups/cgroups.txt
@@ -637,7 +637,7 @@ void exit(struct task_struct *task)
 
 Called during task exit.
 
-void bind(struct cgroup *root)
+void bind(struct cgroup_subsys_state *root_css)
 (cgroup_mutex held by caller)
 
 Called when a cgroup subsystem is rebound to a different hierarchy
@@ -645,6 +645,16 @@ and root cgroup. Currently this will onl
 the default hierarchy (which never has sub-cgroups) and a hierarchy
 that is being created/destroyed (and hence has no sub-cgroups).
 
+void unbind(struct cgroup_subsys_state *root_css)
+(cgroup_mutex held by caller)
+
+Called when a cgroup subsys is unbound from its current hierarchy. The
+subsystem must guarantee that all offline cgroups are going to be
+released in a finite amount of time after this function is called.
+Such draining can be asynchronous. The following binding of the
+subsystem to a hierarchy will be delayed till the draining is
+complete.
+
 4. Extended attribute usage
 ===
 
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -654,6 +654,7 @@ struct cgroup_subsys {
 struct cgroup_subsys_state *old_css,
 struct task_struct *task);
void (*bind)(struct cgroup_subsys_state *root_css);
+   void (*unbind)(struct cgroup_subsys_state *root_css);
 
int disabled;
int early_init;
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1910,10 +1910,20 @@ static void cgroup_kill_sb(struct super_
 * And don't kill the default root.
 */
if (css_has_online_children(>cgrp.self) ||
-   root == _dfl_root)
+   root == _dfl_root) {
cgroup_put(>cgrp);
-   else
+   } else {
+   struct cgroup_subsys *ss;
+   int i;
+
+   mutex_lock(_mutex);
+   for_each_subsys(ss, i)
+   if ((root->subsys_mask & (1UL << i)) && ss->unbind)
+   ss->unbind(cgroup_css(>cgrp, ss));
+   mutex_unlock(_mutex);
+
percpu_ref_kill(>cgrp.self.refcnt);
+   }
 
kernfs_kill_sb(sb);
 }
--
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  

Re: [PATCH 07/16] ARM: integrator: convert PCI to use generic config accesses

[Linus Walleij]

On Sat, Jan 10, 2015 at 3:34 AM, Rob Herring  wrote:

> Convert the integrator PCI driver to use the generic config access
> functions.
>
> This changes accesses from __raw_readX/__raw_writeX to readX/writeX
> variants.

Just as good.

> The spinlock is removed because it is unnecessary. The config
> read and write functions are already protected with a spinlock and no
> access can occur during the .pre_init function.
>
> Signed-off-by: Rob Herring 
> Cc: Russell King 
> Cc: Linus Walleij 
> Cc: linux-arm-ker...@lists.infradead.org

I trust that you do the right thing I guess...
Acked-by: Linus Walleij 

>  static int v3_read_config(struct pci_bus *bus, unsigned int devfn, int where,
>   int size, u32 *val)
>  {
> -   addr = v3_open_config_window(bus, devfn, where);
> +   int ret = pci_generic_config_read(bus, devfn, where, size, val);
> v3_close_config_window();
> +   return ret;
>  }
>
>  static int v3_write_config(struct pci_bus *bus, unsigned int devfn, int 
> where,
>int size, u32 val)
>  {
> +   int ret = pci_generic_config_write(bus, devfn, where, size, val);
> v3_close_config_window();
> -   raw_spin_unlock_irqrestore(_lock, flags);
> +   return ret;
>  }
>
>  static struct pci_ops pci_v3_ops = {
> +   .map_bus = v3_open_config_window,
> .read   = v3_read_config,
> .write  = v3_write_config,

So .map_bus is called before every .read/.write operation I take it.

Wouldn't it be proper to call the v3_close_config_window() from a
matching .unmap_bus() callback for symmetry?

Yours,
Linus Walleij
--
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: Linux 3.19-rc3

[Arnd Bergmann]

On Saturday 10 January 2015 13:00:27 Linus Torvalds wrote:
> 
> > IIRC, AIX works great with 64k pages, but only because of two
> > reasons that don't apply on Linux:
> 
> .. there's a few other ones:
> 
>  (c) nobody really runs AIX on dekstops. It's very much a DB load
> environment, with historically some HPC.
> 
>  (d) the powerpc TLB fill/buildup/teardown costs are horrible, so on
> AIX the cost of lots of small pages is much higher too.

I think (d) applies to ARM as well, since it has no hardware
dirty/referenced bit tracking and requires the OS to mark the
pages as invalid/readonly until the first access. ARMv8.1
has a fix for that, but it's optional and we haven't seen any
implementations yet.

> so I feel pretty confident in saying it won't happen. It's just too
> much of a bother, for little to no actual upside. It's likely a much
> better approach to try to instead use THP for anonymous mappings.

arm64 already supports 2MB transparent hugepages. I guess it
wouldn't be too hard to change it so that an existing hugepage
on an anonymous mapping that gets split up into 4KB pages gets
split along 64KB boundaries with the contiguous mapping bit set.

Having full support for multiple hugepage sizes (64KB, 2MB and 32MB
in case of ARM64 with 4KB PAGE_SIZE) would be even better and
probably negate any benefits of 64KB PAGE_SIZE, but requires more
changes to common mm code.

Arnd
--
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 2/3] dt-bindings: Add pinctrl bindings for mt65xx/mt81xx.

[Linus Walleij]

On Tue, Dec 2, 2014 at 2:55 PM, Sascha Hauer  wrote:

Sorry for taking eternities to get back on this, I ran into a merge window
and some christmas. I do hope we can resolve this in the current
development cycle so we can get this support in.

> On Fri, Nov 28, 2014 at 05:12:44PM +0100, Linus Walleij wrote:
>> On Thu, Nov 27, 2014 at 11:18 AM, Sascha Hauer  
>> wrote:
>> > On Thu, Nov 27, 2014 at 09:44:42AM +0100, Linus Walleij wrote:
>> >> On Tue, Nov 11, 2014 at 1:38 PM, Hongzhou Yang
>> >>  wrote:

>> >> > +node {
>> >> > + mediatek,pins = ;
>> >> > + GENERIC_PINCONFIG;
>> >> > +};
>> >>
>> >> As suggested by Sacha, use just "pins" and define the binding as a patch
>> >> to Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
>> >> that is generic for multiplexing, so we get some order here.
>> >>
>> >> I want you however to put pin multiplexing and pin configuration into
>> >> different nodes if possible. I don't like combines muxing and config
>> >> nodes. If necessary tag the node with something.
>> >
>> > Why? I think the properties can live happily together, even when the
>> > parsing functions go to the pinctrl core.
>>
>> I'm worried about the semantic ambiguity between the pins = <...>;
>> property on different pin controllers, whether they are based on
>> function+group or per-pin. It's not even up to me to decide,
>> this is for the DT binding people.
>>
>> In this case:
>>
>> pins = ,
>>   ;
>>
>> Each element is a 32bit unsigned where the lower and higher
>> 16 bits have different meanings.
>>
>> In some other pin controller (using generic bindings and
>> already merged! arch/arm/boot/dts/ste-href-ab8500.dtsi):
>>
>> gpio39 {
>>   gpio39_default_mode: gpio39_default {
>>  default_mux {
>>   function = "gpio";
>>   groups = "gpio39_a_1";
>>  };
>>  default_cfg {
>>   pins = "GPIO39_E16";
>>   input-enable;
>>   bias-pull-down;
>>  };
>>  };
>> };
>>
>> Can we get away with using the same core parser with this
>> as well, here the nodes are split and using strings to identify
>> pins, not 32bit numbers.
>>
>> I am worried about semantic coexistance...
>
> We could rename the property from 'pins' to 'pinmux' for this variant of
> the binding. Then a parser would know that this property is about pins
> and muxing.

OK sounds like a viable compromise.

I am mostly worried that none of the fine device tree people say
anything about this stuff we're discussing here, maybe absolutely
nobody else understands...

>> >> i2c0_pins_a: i2c0@0 {
>> >> pins1 {
>> >> pins = ;
>> >> function = ;
>> >> };
>> >
>> > The reason to put this in a single define was to make writing the device
>> > trees less error prone. When you have two arrays you must correlate the
>> > entries.
>>
>> I see the upside. I'm just worried about ambiguity when comparing
>> different device trees to each other, because they should be about
>> readability and understanding, not confusing...
>
> Sorry, given the currently existing devicetrees I don't buy that
> readability argument. Let's look into the snowball example, here ssp0:
>
> ssp0_snowball_mode: ssp0_snowball_default {
> snowball_mux {
> ste,function = "ssp0";
> ste,pins = "ssp0_a_1";
> };
> snowball_cfg1 {
> ste,pins = "GPIO144_B13"; /* FRM */
> ste,config = <_out_hi>;
> };
> snowball_cfg2 {
> ste,pins = "GPIO145_C13"; /* RXD */
> ste,config = <_pd>;
> };
> snowball_cfg3 {
> ste,pins =
> "GPIO146_D13", /* TXD */
> "GPIO143_D12"; /* CLK */
> ste,config = <_lo>;
> };
> };

I agree the ste,pins is not a good example, it is insane to have
something group and pins mixed, and that is why
I migrated it in the last merge window, notably the pin multiplex thing
so it now looks like this:

ssp0 {
ssp0_snowball_mode: ssp0_snowball_default {
snowball_mux {
function = "ssp0";
groups = "ssp0_a_1";
};
snowball_cfg1 {
pins = "GPIO144_B13"; /* FRM */
ste,config = <_out_hi>;
};
(...)

I'm sorry about not migrating the ste,config part to
generic bindings yet :( that is 

Re: [BUG] 3.19-rc1 net: less interrupt masking in NAPI

[Oded Gabbay]

On 01/10/2015 10:58 PM, Eric Dumazet wrote:
> On Sat, 2015-01-10 at 22:39 +0200, Oded Gabbay wrote:
>> Hi,
>>
>> Commit d75b1ade567ffab085e8adbbdacf0092d10cd09c breaks my "Qualcomm Atheros
>> AR8161 Gigabit Ethernet (rev 10)" Ethernet controller, which is handled by
>> the alx network driver.
>>
>> ogabbay@odedg-ubuntu:~$ lspci -s 01:00.0 -k
>> 01:00.0 Ethernet controller:
>>  Qualcomm Atheros AR8161 Gigabit Ethernet (rev 10)
>>  Subsystem: Qualcomm Atheros Device 1071
>>  Kernel driver in use: alx
>>
>> I have this controller on a mobile platform of AMD APU Kaveri, which I use
>> to test amdkfd, and from 3.19-rc1 the network stopped working when trying to
>> transfer files through scp or nfs.
>>
>> I bisected the kernel (from 3.18.0 to 3.19-rc1) and reached this commit.
>>
>> Here is the log of the bisect:
>>
>> git bisect start
>> # bad: [97bf6af1f928216fd6c5a66e8a57bfa95a659672] Linux 3.19-rc1
>> git bisect bad 97bf6af1f928216fd6c5a66e8a57bfa95a659672
>>
>> # good: [b2776bf7149bddd1f4161f14f79520f17fc1d71d] Linux 3.18
>> git bisect good b2776bf7149bddd1f4161f14f79520f17fc1d71d
>>
>> # bad: [70e71ca0af244f48a5dcf56dc435243792e3a495] Merge
>> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
>> git bisect bad 70e71ca0af244f48a5dcf56dc435243792e3a495
>>
>> # good: [e28870f9b3e92cd3570925089c6bb789c2603bc4] Merge tag
>> 'backlight-for-linus-3.19' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight
>> git bisect good e28870f9b3e92cd3570925089c6bb789c2603bc4
>>
>> # bad: [450fa21942fe2c37f0c9f52d1a33bbc081eee288] sh_eth: Remove redundant
>> alignment adjustment
>> git bisect bad 450fa21942fe2c37f0c9f52d1a33bbc081eee288
>>
>> # bad: [5c8d19da950861d0482abc0ac3481acca34b008f] e100e: use
>> netdev_rss_key_fill() helper
>> git bisect bad 5c8d19da950861d0482abc0ac3481acca34b008f
>>
>> # good: [bf515fb11ab539c76d04f0e3c5216ed41f41d81f] Merge tag
>> 'mac80211-next-for-john-2014-11-04' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next
>> git bisect good bf515fb11ab539c76d04f0e3c5216ed41f41d81f
>>
>> # bad: [2c99cd914d4fed9160d98849c9dd38034616768e] Merge branch 
>> 'amd-xgbe-next'
>> git bisect bad 2c99cd914d4fed9160d98849c9dd38034616768e
>>
>> # good: [3d762a0f0ab9cb4a6b5993db3ce56c92f9f90ab2] net: dsa: Add support for
>> reading switch registers with ethtool
>> git bisect good 3d762a0f0ab9cb4a6b5993db3ce56c92f9f90ab2
>>
>> # bad: [8ce0c8254f15229aa99fc6c04141f28c446e5f8c] Merge branch 'master' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next
>> git bisect bad 8ce0c8254f15229aa99fc6c04141f28c446e5f8c
>>
>> # good: [f0c65567b3c1b23f79e8a49139580a3872a68d1f] Merge branch
>> 'sunvnet-multi-tx-queue'
>> git bisect good f0c65567b3c1b23f79e8a49139580a3872a68d1f
>>
>> # bad: [547f2735c20023d7b50a791b1b17cacb652e9237] Merge branch 'mlx4-next'
>> git bisect bad 547f2735c20023d7b50a791b1b17cacb652e9237
>>
>> # good: [4cdb1e2e3d3495423db558d3bb7ed11d66aabce7] net: shrink struct
>> softnet_data
>> git bisect good 4cdb1e2e3d3495423db558d3bb7ed11d66aabce7
>>
>> # bad: [0a98455666ec87378148a1dde97f1ce5baf75a64] net/mlx4_core: Protect
>> port type setting by mutex
>> git bisect bad 0a98455666ec87378148a1dde97f1ce5baf75a64
>>
>> # bad: [6e8066999800d90d52af5c84ac49ebf683d14cdc] net/mlx4_core: Prevent VF
>> from changing port configuration
>> git bisect bad 6e8066999800d90d52af5c84ac49ebf683d14cdc
>>
>> # bad: [d75b1ade567ffab085e8adbbdacf0092d10cd09c] net: less interrupt
>> masking in NAPI
>> git bisect bad d75b1ade567ffab085e8adbbdacf0092d10cd09c
>>
>> # first bad commit: [d75b1ade567ffab085e8adbbdacf0092d10cd09c]
>> net: less interrupt masking in NAPI
>>
>> Could you please solve this issue as it renders my board quite useless.
>>
> 
> Thanks for the report and bisection !
> 
> Could you try following fix ?
> 
> diff --git a/drivers/net/ethernet/atheros/alx/main.c 
> b/drivers/net/ethernet/atheros/alx/main.c
> index e398eda07298..209c40765e0d 100644
> --- a/drivers/net/ethernet/atheros/alx/main.c
> +++ b/drivers/net/ethernet/atheros/alx/main.c
> @@ -272,7 +272,7 @@ static int alx_poll(struct napi_struct *napi, int budget)
>  alx_clean_rx_irq(alx, budget);
>  
>   if (!complete)
> - return 1;
> + return budget;
>  
>   napi_complete(>napi);
>  
> 
> 
> 
> 
Yes, no problem.
I will update on the result.

Oded
--
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/

[REGRESSION] media: cx23885 broken by commit 453afdd9ce33293f640e84dc17e5f366701516e8 (was: Help needed: complex case bisection (TBS6981))

[Raimonds Cicans]

TL;DR:
media: cx23885 broken by commit 453afdd9ce33293f640e84dc17e5f366701516e8
"[media] cx23885: convert to vb2"
Broken mean: until this commit driver was rock solid, after I started to 
receive

IOMMU related warnings and sometimes card stopped working


Full report:

On 09.01.2015 10:34, Raimonds Cicans wrote:

History of problem:
1) I own computer based on AMD Athlon(tm) II X2 240e Processor on Asus 
M5A97 LE R2.0 motherboard

2) I own TBS6981 card (Dual DVB-S/S2 PCIe receiver, in kernel driver)
3) I used kernel 3.13.something
4) everything was fine
5) time to time I tried to upgrade to newer kernels
but I got AMD IOMMU driver regression
(AMD-Vi: Completion-Wait loop timed out)
6) I tried to disable IOMMU, but this lead to problems with NIC and 
USB controller
7) I was forced to upgrade to newer kernel (I needed all new fixes for 
BTRFS file system)

8) I bought TBS6285 (Quad DVB-T/T2 PCIe receiver)
9) I upgraded to kernel 3.17.7
AMD IOMMU driver regression disappeared
but appeared two IOMMU related problems with TBS6981:

WARNING: CPU: 0 PID: 13204 at drivers/iommu/amd_iommu.c:2625 
dma_ops_domain_unmap.part.9+0x4d/0x56()


and

AMD-Vi: Event logged [IO_PAGE_FAULT device=08:00.0 domain=0x001c 
address=0x01355000 flags=0x]


As I understand first message mean "we tried to unmap same dma region 
twice"

and second mean "we tried to dma to/from region that do not exist"

IMHO this mean that cause for those messages can be single commit


I was naive... In reality it is not so simply.


Hypotheses:
1) Bug(s) in motherboard's hardware/BIOS (why it worked before?)

Disproved: card work rock solid with plain 3.13.10 kernel


2) TBS6981 conflicts with TBS6285

Disproved: card have same problems on new drivers,
  without TBS6285 in computer


3) Bug(s) in TBS6981 driver
Very likely: problems started from commit 
453afdd9ce33293f640e84dc17e5f366701516e8

 which changed cx23885 driver


4) Bug(s) in media subsystem (video buffer dma part)

Unlikely: only if cx23885 driver uses this part in specific way


5) Bug(s) in AMD IOMMU driver

Very unlikely: this would cause problems with other systems and drivers


Bisection plan:
0. take out from computer all unnecessary hardware (including TBS6285)
1. install latest known good kernel (3.13.something)
I will use this kernel because I want to rule out AMD IOMMU 
regression

2. cold reboot and test everything is working

Every thing was working... almost: card lost one receiver
I take card from second PCIe slot and put in third:
first receiver appeared but card lost second receiver.
I put card in fourth slot and both receivers reappeared.
(I need to investigate this deeper)


3. take linux-media tree and compile drivers from HEAD

It took several hours to make linux-media build system to work


4. cold reboot and test
if everything is working, then
a) problem is fixed in HEAD
or
b) compatibility problem with TBS6285
or
c) problem is related to AMD IOMMU driver 
regression in

newer kernels
to distinguish between this cases I should build
newest kernel with HEAD media drivers
if everything is working then case a) or b)
and I must put TBS6285 back and test again
else this is case c) and I should bisect 
linux-kernel tree for this problem
(git bisect start; git bisect bad v3.14; 
git bisect good v3.13)


end of testing

if TBS6981 driver misbehaves, then I should git bisect linux-media 
tree

Driver misbehaved


5. bisect linux-media tree
(git bisect start -- drivers/media; git bisect bad v3.17; git 
bisect good v3.13)


if I find single commit that is cause for both messages then stop

if at some commit only one message appear, then I should write down
good/bad region and continue with first message and then do
new bisection for other message but on reduced region

Soon appeared new bug:
kernel BUG at mm/slub.c:1394!

Main problem was that this bug appeared much faster than first two bugs
and often caused computer lock up.
I decided to treat this error same way as previous two:  git bisect bad

When I tested affecting commit I received  two errors: second & third



What now?

I see two ways:

1) investigate problem deeper and solve bug in current driver
it is perfect solution, but IMHO it is far beyond of my abilities.

2) Just revert affecting commit(s)
BTW can somebody show how to create new branch and revert
some commit with all depending commits



Raimonds Cicans
--
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  

[PATCH] drm/i915: fix inconsistent brightness after resume

[Jeremiah Mahler]

Commit 6dda730e55f4 introduced a bug which resulted in inconsistent
brightness levels on different machines. If a suspended was entered
with the screen off some machines would resume with the screen
at minimum brightness and others at maximum brightness.

The following commands can be used to produce this behavior.

  xset dpms force off
  sleep 1
  sudo systemctl suspend
  (resume ...)

The root cause of this problem is a comparison which checks to see if
the backlight level is zero when the panel is enabled.  If it is zero,
it is set to the maximum level.  Unfortunately, not all machines have a
minimum level of zero. On those machines the level is left at the
minimum instead of begin set to the maximum.

Fix the bug by updating the comparison to check for the minimum
backlight level instead of zero.

Fixes: 6dda730e55f4 ("respect the VBT minimum backlight brightness")
Signed-off-by: Jeremiah Mahler 
---
 drivers/gpu/drm/i915/intel_panel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 4d63839..4ef4d66 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -962,7 +962,7 @@ void intel_panel_enable_backlight(struct intel_connector 
*connector)
 
WARN_ON(panel->backlight.max == 0);
 
-   if (panel->backlight.level == 0) {
+   if (panel->backlight.level == panel->backlight.min) {
panel->backlight.level = panel->backlight.max;
if (panel->backlight.device)
panel->backlight.device->props.brightness =
-- 
2.1.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 3/4] x86: open-code register save/restore in trace_hardirqs thunks

[Linus Torvalds]

On Sat, Jan 10, 2015 at 1:09 PM, Denys Vlasenko
 wrote:
>
> I think using push/pop is okay. In the very hottest code paths
> you may want to prefer mov's.

For kernel entrypoints in particular, the code sequence is quite
possibly constrained by the decoder and instruction fetch rather than
the execution engine. Even if the entrypoint were to be in the L1 I$
(which is not generally the case except in microbenchmarks), I am
pretty sure that even Intel doesn't actually speculatively decode
across system call boundaries, so unlike normal nice code, you don't
have the front end running ahead of the execution engine.

Looking at the system call hotpath, for example, it looks like we
save/restore 8 registers. So 16 instructions or about 80 bytes of
code. I could easily imagine us avoiding one cacheline access by using
shorter 1- and 2-byte push/pop instructions (depending a bit on how
the cacheline alignment works out, of course).

Depending on how well it prefetches from L2 and/or exact decoder
details, that kind of issue *can* overshadow the actual execution
costs. Of course, on microbenchmarks (eg some system call benchmark
that does "getppid()" in a loop), even the kernel side stays in the
L1, so those might show possible execution issues more. And
macrobenchmarks probably won't show a cycle or two in the system call
or fault path anyway.

Linus
--
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/4] x86: open-code register save/restore in trace_hardirqs thunks

[Borislav Petkov]

On Sat, Jan 10, 2015 at 01:08:33PM -0800, Linus Torvalds wrote:
> It was true for some AMD CPU's in particular. One insn/cycle vs two.

Probably on K8: Agner Fog's insn tables show reciprocal throughput of
1/2 for MOV r64/m64 vs 1 for PUSH/POP.

> I personally would be very happy to go back to push/pop sequences.
> Even without a fancy stack engine like Intel has done for a while,
> even *simple* cores can generally pair pushes and pops. I think the

I think all the modern x86 machines have stack engines now :-)

> original Pentium already had a special magic pairing logic to pair
> pushes and pops despite both instructions using %esp. It's a common
> and fairly trivial special case, and the fact that a few AMD
> microarchitectures didn't do it is likely not really a good reason to
> avoid repeated push/pop instructions.

Well, according to the optimization manual, on F15h (Bulldozer and
later) PUSH/POP are faster than MOVs and on F16h (Jaguar and later) both
MOV and PUSH/POP have latency of 1, with MOV having a 1/2 throughput vs
PUSH/POP throughput of 1. So theoretically we can do 2 MOVs per cycle
there vs 1 PUSH/POP.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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: Getting new udev to run with 2.6.28

[Al Viro]

On Sat, Jan 10, 2015 at 10:17:10AM -0800, Greg KH wrote:
> > > Yes, 3.18, please use that instead.
> > 
> > Can't, sorry. My goal is to get 3.18/3.19 working, but I really need
> > working kernel to debug userland (and then use that userland to debug 
> > kernel).
> > 
> > > Seriously, lots of things have changed, if you want to run a "new"
> > > version of udev with an old kernel, try eudev, they have been attempting
> > > to keep "legacy" support around in it, don't know how well it has been
> > > working though, you really are on your own.
> > 
> > I was hoping someone has devtmpfs patches I could just apply over
> > 2.6.28 and get a working system?
> 
> If you want such a crazy thing, you have all of the source to do it
> yourself, good luck.

... and this, boys and girls, is why quite a few of us have loathed udev
way before it got merged into even nastier shitpile.  Still do, for that
matter.
--
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/