Re: CVE-2016-10229 in 4.4.x series

[Steven Pease]

Is there any particular reason that the CVE appears to be filed
against 4.4.60? Or is this just a mistake?

http://www.cvedetails.com/cve/CVE-2016-10229/

- Steven

On Mon, May 15, 2017 at 10:20 PM, Willy Tarreau  wrote:
> On Mon, May 15, 2017 at 06:09:53PM -0700, Steven Pease wrote:
>> Hi,
>>
>> This is my first post - not currently subscribed so please CC me. :) I
>> searched a bit for this question, but couldn't find an answer (Googled
>> '2016-10229 site:lkml.org').
>>
>> Does CVE-2016-10229 affect the newest version of the 4.4.x kernel
>> series (currently 4.4.68) and are there any plans to fix this in the
>> 4.4 kernel series?
>
> This one was fixed by upstream commit 197c949 ("udp: properly support
> MSG_PEEK with truncated buffers"), which was backported in 4.4 as
> commit dfe2042d96 in 4.4.21. So in short, 4.4.68 is safe.
>
> Willy



-- 
- Steven

Re: CVE-2016-10229 in 4.4.x series

[Steven Pease]

Is there any particular reason that the CVE appears to be filed
against 4.4.60? Or is this just a mistake?

http://www.cvedetails.com/cve/CVE-2016-10229/

- Steven

On Mon, May 15, 2017 at 10:20 PM, Willy Tarreau  wrote:
> On Mon, May 15, 2017 at 06:09:53PM -0700, Steven Pease wrote:
>> Hi,
>>
>> This is my first post - not currently subscribed so please CC me. :) I
>> searched a bit for this question, but couldn't find an answer (Googled
>> '2016-10229 site:lkml.org').
>>
>> Does CVE-2016-10229 affect the newest version of the 4.4.x kernel
>> series (currently 4.4.68) and are there any plans to fix this in the
>> 4.4 kernel series?
>
> This one was fixed by upstream commit 197c949 ("udp: properly support
> MSG_PEEK with truncated buffers"), which was backported in 4.4 as
> commit dfe2042d96 in 4.4.21. So in short, 4.4.68 is safe.
>
> Willy



-- 
- Steven

[RESEND PATCH] iio: adc: bcm_iproc_adc: swap primary and secondary isr handler's

[Raveendra Padasalagi]

The third argument of devm_request_threaded_irq() is the primary
handler. It is called in hardirq context and checks whether the
interrupt is relevant to the device. If the primary handler returns
IRQ_WAKE_THREAD, the secondary handler (a.k.a. handler thread) is
scheduled to run in process context.

bcm_iproc_adc.c uses the secondary handler as the primary one
and the other way around. So this patch fixes the same, along with
re-naming the secondary handler and primary handler names properly.

Tested on the BCM9583XX iProc SoC based boards.

Reported-by: Pavel Roskin 
Fixes: 4324c97ecedc("iio: Add driver for Broadcom iproc-static-adc")
Signed-off-by: Raveendra Padasalagi 
---
 drivers/iio/adc/bcm_iproc_adc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/iio/adc/bcm_iproc_adc.c b/drivers/iio/adc/bcm_iproc_adc.c
index 21d38c8..7f4f9c4 100644
--- a/drivers/iio/adc/bcm_iproc_adc.c
+++ b/drivers/iio/adc/bcm_iproc_adc.c
@@ -143,7 +143,7 @@ static void iproc_adc_reg_dump(struct iio_dev *indio_dev)
iproc_adc_dbg_reg(dev, adc_priv, IPROC_SOFT_BYPASS_DATA);
 }
 
-static irqreturn_t iproc_adc_interrupt_handler(int irq, void *data)
+static irqreturn_t iproc_adc_interrupt_thread(int irq, void *data)
 {
u32 channel_intr_status;
u32 intr_status;
@@ -167,7 +167,7 @@ static irqreturn_t iproc_adc_interrupt_handler(int irq, 
void *data)
return IRQ_NONE;
 }
 
-static irqreturn_t iproc_adc_interrupt_thread(int irq, void *data)
+static irqreturn_t iproc_adc_interrupt_handler(int irq, void *data)
 {
irqreturn_t retval = IRQ_NONE;
struct iproc_adc_priv *adc_priv;
@@ -181,7 +181,7 @@ static irqreturn_t iproc_adc_interrupt_thread(int irq, void 
*data)
adc_priv = iio_priv(indio_dev);
 
regmap_read(adc_priv->regmap, IPROC_INTERRUPT_STATUS, _status);
-   dev_dbg(_dev->dev, "iproc_adc_interrupt_thread(),INTRPT_STS:%x\n",
+   dev_dbg(_dev->dev, 
"iproc_adc_interrupt_handler(),INTRPT_STS:%x\n",
intr_status);
 
intr_channels = (intr_status & IPROC_ADC_INTR_MASK) >> IPROC_ADC_INTR;
@@ -566,8 +566,8 @@ static int iproc_adc_probe(struct platform_device *pdev)
}
 
ret = devm_request_threaded_irq(>dev, adc_priv->irqno,
-   iproc_adc_interrupt_thread,
iproc_adc_interrupt_handler,
+   iproc_adc_interrupt_thread,
IRQF_SHARED, "iproc-adc", indio_dev);
if (ret) {
dev_err(>dev, "request_irq error %d\n", ret);
-- 
1.9.1

[RESEND PATCH] iio: adc: bcm_iproc_adc: swap primary and secondary isr handler's

[Raveendra Padasalagi]

The third argument of devm_request_threaded_irq() is the primary
handler. It is called in hardirq context and checks whether the
interrupt is relevant to the device. If the primary handler returns
IRQ_WAKE_THREAD, the secondary handler (a.k.a. handler thread) is
scheduled to run in process context.

bcm_iproc_adc.c uses the secondary handler as the primary one
and the other way around. So this patch fixes the same, along with
re-naming the secondary handler and primary handler names properly.

Tested on the BCM9583XX iProc SoC based boards.

Reported-by: Pavel Roskin 
Fixes: 4324c97ecedc("iio: Add driver for Broadcom iproc-static-adc")
Signed-off-by: Raveendra Padasalagi 
---
 drivers/iio/adc/bcm_iproc_adc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/iio/adc/bcm_iproc_adc.c b/drivers/iio/adc/bcm_iproc_adc.c
index 21d38c8..7f4f9c4 100644
--- a/drivers/iio/adc/bcm_iproc_adc.c
+++ b/drivers/iio/adc/bcm_iproc_adc.c
@@ -143,7 +143,7 @@ static void iproc_adc_reg_dump(struct iio_dev *indio_dev)
iproc_adc_dbg_reg(dev, adc_priv, IPROC_SOFT_BYPASS_DATA);
 }
 
-static irqreturn_t iproc_adc_interrupt_handler(int irq, void *data)
+static irqreturn_t iproc_adc_interrupt_thread(int irq, void *data)
 {
u32 channel_intr_status;
u32 intr_status;
@@ -167,7 +167,7 @@ static irqreturn_t iproc_adc_interrupt_handler(int irq, 
void *data)
return IRQ_NONE;
 }
 
-static irqreturn_t iproc_adc_interrupt_thread(int irq, void *data)
+static irqreturn_t iproc_adc_interrupt_handler(int irq, void *data)
 {
irqreturn_t retval = IRQ_NONE;
struct iproc_adc_priv *adc_priv;
@@ -181,7 +181,7 @@ static irqreturn_t iproc_adc_interrupt_thread(int irq, void 
*data)
adc_priv = iio_priv(indio_dev);
 
regmap_read(adc_priv->regmap, IPROC_INTERRUPT_STATUS, _status);
-   dev_dbg(_dev->dev, "iproc_adc_interrupt_thread(),INTRPT_STS:%x\n",
+   dev_dbg(_dev->dev, 
"iproc_adc_interrupt_handler(),INTRPT_STS:%x\n",
intr_status);
 
intr_channels = (intr_status & IPROC_ADC_INTR_MASK) >> IPROC_ADC_INTR;
@@ -566,8 +566,8 @@ static int iproc_adc_probe(struct platform_device *pdev)
}
 
ret = devm_request_threaded_irq(>dev, adc_priv->irqno,
-   iproc_adc_interrupt_thread,
iproc_adc_interrupt_handler,
+   iproc_adc_interrupt_thread,
IRQF_SHARED, "iproc-adc", indio_dev);
if (ret) {
dev_err(>dev, "request_irq error %d\n", ret);
-- 
1.9.1

RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

[Zheng, Lv]

Hi,

> From: linux-acpi-ow...@vger.kernel.org 
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Zheng,
> Lv
> Subject: RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to 
> lid_init_state=open"
> 
> Hi, Guys
> 
> > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> > Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to 
> > lid_init_state=open"
> >
> > On May 15 2017 or thereabouts, Rafael J. Wysocki wrote:
> > > On Mon, May 15, 2017 at 11:37 AM, Benjamin Tissoires
> > >  wrote:
> > > > On May 15 2017 or thereabouts, Rafael J. Wysocki wrote:
> > > >> On Mon, May 15, 2017 at 9:45 AM, Benjamin Tissoires
> > > >>  wrote:
> > > >> > On May 12 2017 or thereabouts, Rafael J. Wysocki wrote:
> > > >> >> On Friday, May 12, 2017 02:36:20 AM Zheng, Lv wrote:
> > > >> >> > Hi,
> > > >> >> >
> > > >> >> > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> > > >> >> > > Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default 
> > > >> >> > > behavior to
> > lid_init_state=open"
> > > >> >> > >
> > > >> >> > > On May 11 2017 or thereabouts, Zheng, Lv wrote:
> > > >> >> > > > Hi,
> > > >> >> > > >
> > > >> >> > > > > From: Benjamin Tissoires 
> > > >> >> > > > > [mailto:benjamin.tissoi...@redhat.com]
> > > >> >> > > > > Subject: [PATCH 2/2] Revert "ACPI / button: Change default 
> > > >> >> > > > > behavior to
> > lid_init_state=open"
> > > >> >> > > > >
> > > >> >> > > > > This reverts commit 
> > > >> >> > > > > 77e9a4aa9de10cc1418bf9a892366988802a8025.
> > > >> >> > > > >
> > > >> >> > > > > Even if the method implementation can be buggy on some 
> > > >> >> > > > > platform,
> > > >> >> > > > > the "open" choice is worse. It breaks docking stations 
> > > >> >> > > > > basically
> > > >> >> > > > > and there is no way to have a user-space hwdb to fix that.
> > > >> >> > > > >
> > > >> >> > > > > On the contrary, it's rather easy in user-space to have a 
> > > >> >> > > > > hwdb
> > > >> >> > > > > with the problematic platforms. Then, libinput (1.7.0+) can 
> > > >> >> > > > > fix
> > > >> >> > > > > the state of the LID switch for us: you need to set the udev
> > > >> >> > > > > property LIBINPUT_ATTR_LID_SWITCH_RELIABILITY to 
> > > >> >> > > > > 'write_open'.
> > > >> >> > > > >
> > > >> >> > > > > When libinput detects internal keyboard events, it will
> > > >> >> > > > > overwrite the state of the switch to open, making it 
> > > >> >> > > > > reliable
> > > >> >> > > > > again. Given that logind only checks the LID switch value 
> > > >> >> > > > > after
> > > >> >> > > > > a timeout, we can assume the user will use the internal 
> > > >> >> > > > > keyboard
> > > >> >> > > > > before this timeout expires.
> > > >> >> > > > >
> > > >> >> > > > > For example, such a hwdb entry is:
> > > >> >> > > > >
> > > >> >> > > > > libinput:name:*Lid 
> > > >> >> > > > > Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:*
> > > >> >> > > > >  LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open
> > > >> >> > > >
> > > >> >
> > > >> > [...]
> > > >> >
> > > >> >>
> > > >> >> Well, if it worked in a specific way that users depended on before 
> > > >> >> the commit in
> > > >> >> question and now it works differently, then it does break things.
> > > >> >>
> > > >> >> Benjamin, my understanding is that this is the case, is it correct?
> > > >> >
> > > >> > That is correct. This patch I reverted introduces regression for 
> > > >> > professional
> > > >> > laptops that expect the LID switch to be reported accurately.
> > > >>
> > > >> And from a user's perspective, what does not work any more?
> > > >
> > > > If you boot or resume your laptop with the lid closed on a docking
> > > > station while using an external monitor connected to it, both internal
> > > > and external displays will light on, while only the external should.
> > > >
> > > > There is a design choice in gdm to only provide the greater on the
> > > > internal display when lit on, so users only see a gray area on the
> > > > external monitor. Also, the cursor will not show up as it's by default
> > > > on the internal display too.
> > > >
> > > > To "fix" that, users have to open the laptop once and close it once
> > > > again to sync the state of the switch with the hardware state.
> > >
> > > OK
> > >
> > > Yeah, that sucks.
> > >
> > > So without the Lv's patch the behavior (on the systems in question) is
> > > as expected, right?
> > >
> >
> > Yes, reverting these 2 patches restores the pre v4.11 kernel behavior.
> 
> I would make an argument that:
> A. Is this necessarily a button driver regression?
> 1. Users already configured to not using internal display, why gdm need to 
> determine it again instead
> of users choice?
> 2. Can gdm/graphics driver saves state before suspend, and restores saved 
> state after resume?
>If users didn't change state during suspend, then everything should be 
> correct.
>If users 

RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

[Zheng, Lv]

Hi,

> From: linux-acpi-ow...@vger.kernel.org 
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Zheng,
> Lv
> Subject: RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to 
> lid_init_state=open"
> 
> Hi, Guys
> 
> > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> > Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to 
> > lid_init_state=open"
> >
> > On May 15 2017 or thereabouts, Rafael J. Wysocki wrote:
> > > On Mon, May 15, 2017 at 11:37 AM, Benjamin Tissoires
> > >  wrote:
> > > > On May 15 2017 or thereabouts, Rafael J. Wysocki wrote:
> > > >> On Mon, May 15, 2017 at 9:45 AM, Benjamin Tissoires
> > > >>  wrote:
> > > >> > On May 12 2017 or thereabouts, Rafael J. Wysocki wrote:
> > > >> >> On Friday, May 12, 2017 02:36:20 AM Zheng, Lv wrote:
> > > >> >> > Hi,
> > > >> >> >
> > > >> >> > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> > > >> >> > > Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default 
> > > >> >> > > behavior to
> > lid_init_state=open"
> > > >> >> > >
> > > >> >> > > On May 11 2017 or thereabouts, Zheng, Lv wrote:
> > > >> >> > > > Hi,
> > > >> >> > > >
> > > >> >> > > > > From: Benjamin Tissoires 
> > > >> >> > > > > [mailto:benjamin.tissoi...@redhat.com]
> > > >> >> > > > > Subject: [PATCH 2/2] Revert "ACPI / button: Change default 
> > > >> >> > > > > behavior to
> > lid_init_state=open"
> > > >> >> > > > >
> > > >> >> > > > > This reverts commit 
> > > >> >> > > > > 77e9a4aa9de10cc1418bf9a892366988802a8025.
> > > >> >> > > > >
> > > >> >> > > > > Even if the method implementation can be buggy on some 
> > > >> >> > > > > platform,
> > > >> >> > > > > the "open" choice is worse. It breaks docking stations 
> > > >> >> > > > > basically
> > > >> >> > > > > and there is no way to have a user-space hwdb to fix that.
> > > >> >> > > > >
> > > >> >> > > > > On the contrary, it's rather easy in user-space to have a 
> > > >> >> > > > > hwdb
> > > >> >> > > > > with the problematic platforms. Then, libinput (1.7.0+) can 
> > > >> >> > > > > fix
> > > >> >> > > > > the state of the LID switch for us: you need to set the udev
> > > >> >> > > > > property LIBINPUT_ATTR_LID_SWITCH_RELIABILITY to 
> > > >> >> > > > > 'write_open'.
> > > >> >> > > > >
> > > >> >> > > > > When libinput detects internal keyboard events, it will
> > > >> >> > > > > overwrite the state of the switch to open, making it 
> > > >> >> > > > > reliable
> > > >> >> > > > > again. Given that logind only checks the LID switch value 
> > > >> >> > > > > after
> > > >> >> > > > > a timeout, we can assume the user will use the internal 
> > > >> >> > > > > keyboard
> > > >> >> > > > > before this timeout expires.
> > > >> >> > > > >
> > > >> >> > > > > For example, such a hwdb entry is:
> > > >> >> > > > >
> > > >> >> > > > > libinput:name:*Lid 
> > > >> >> > > > > Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:*
> > > >> >> > > > >  LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open
> > > >> >> > > >
> > > >> >
> > > >> > [...]
> > > >> >
> > > >> >>
> > > >> >> Well, if it worked in a specific way that users depended on before 
> > > >> >> the commit in
> > > >> >> question and now it works differently, then it does break things.
> > > >> >>
> > > >> >> Benjamin, my understanding is that this is the case, is it correct?
> > > >> >
> > > >> > That is correct. This patch I reverted introduces regression for 
> > > >> > professional
> > > >> > laptops that expect the LID switch to be reported accurately.
> > > >>
> > > >> And from a user's perspective, what does not work any more?
> > > >
> > > > If you boot or resume your laptop with the lid closed on a docking
> > > > station while using an external monitor connected to it, both internal
> > > > and external displays will light on, while only the external should.
> > > >
> > > > There is a design choice in gdm to only provide the greater on the
> > > > internal display when lit on, so users only see a gray area on the
> > > > external monitor. Also, the cursor will not show up as it's by default
> > > > on the internal display too.
> > > >
> > > > To "fix" that, users have to open the laptop once and close it once
> > > > again to sync the state of the switch with the hardware state.
> > >
> > > OK
> > >
> > > Yeah, that sucks.
> > >
> > > So without the Lv's patch the behavior (on the systems in question) is
> > > as expected, right?
> > >
> >
> > Yes, reverting these 2 patches restores the pre v4.11 kernel behavior.
> 
> I would make an argument that:
> A. Is this necessarily a button driver regression?
> 1. Users already configured to not using internal display, why gdm need to 
> determine it again instead
> of users choice?
> 2. Can gdm/graphics driver saves state before suspend, and restores saved 
> state after resume?
>If users didn't change state during suspend, then everything should be 
> correct.
>If users changed state during suspend, it should be acceptable for 

Re: [PATCH 1/3] ipc/sem.c: remove sem_base, embed struct sem

[Christoph Hellwig]

> + struct sem  sems[0];

I can't contribute much to the code itself, but [0] is an old
GCC extension, for modern code sems[] should do the same things
but is standard C.

Re: [PATCH 1/3] ipc/sem.c: remove sem_base, embed struct sem

[Christoph Hellwig]

> + struct sem  sems[0];

I can't contribute much to the code itself, but [0] is an old
GCC extension, for modern code sems[] should do the same things
but is standard C.

Re: [PATCH 2/2] zram: do not count duplicated pages as compressed

[Sergey Senozhatsky]

On (05/16/17 14:26), Minchan Kim wrote:
[..]
> > +   /*
> > +* Free memory associated with this sector
> > +* before overwriting unused sectors.
> > +*/
> > +   zram_slot_lock(zram, index);
> > +   zram_free_page(zram, index);
> 
> Hmm, zram_free should happen only if the write is done successfully.
> Otherwise, we lose the valid data although write IO was fail.

but would this be correct? the data is not valid - we failed to store
the valid one. but instead we assure application that read()/swapin/etc.,
depending on the usage scenario, is successful (even though the data is
not what application really expects to see), application tries to use the
data from that page and probably crashes (dunno, for example page contained
hash tables with pointers that are not valid anymore, etc. etc.).

I'm not optimistic about stale data reads; it basically will look like
data corruption to the application.

> > +
> > if (zram_same_page_write(zram, index, page))
> > -   return 0;
> > +   goto out_unlock;
> >  
> > entry = zram_dedup_find(zram, page, );
> > if (entry) {
> > comp_len = entry->len;
> > +   zram_set_flag(zram, index, ZRAM_DUP);
>
> In case of hitting dedup, we shouldn't increase compr_data_size.

no, we should not. you are right. my "... patch" is incomplete and
wrong. please don't pay too much attention to it.


> If we fix above two problems, do you think it's still cleaner?
> (I don't mean to be reluctant with your suggestion. Just a
>  real question to know your thought.:)

do you mean code duplication and stale data read?

I'd probably prefer to address stale data reads separately.
but it seems that stale reads fix will re-do parts of your
0002 patch and, at least potentially, reduce code duplication.

so we can go with your 0002 and then stale reads fix will try
to reduce code duplication (unless we want to have 4 places doing
the same thing :) )

-ss

Re: [PATCH 2/2] zram: do not count duplicated pages as compressed

[Sergey Senozhatsky]

On (05/16/17 14:26), Minchan Kim wrote:
[..]
> > +   /*
> > +* Free memory associated with this sector
> > +* before overwriting unused sectors.
> > +*/
> > +   zram_slot_lock(zram, index);
> > +   zram_free_page(zram, index);
> 
> Hmm, zram_free should happen only if the write is done successfully.
> Otherwise, we lose the valid data although write IO was fail.

but would this be correct? the data is not valid - we failed to store
the valid one. but instead we assure application that read()/swapin/etc.,
depending on the usage scenario, is successful (even though the data is
not what application really expects to see), application tries to use the
data from that page and probably crashes (dunno, for example page contained
hash tables with pointers that are not valid anymore, etc. etc.).

I'm not optimistic about stale data reads; it basically will look like
data corruption to the application.

> > +
> > if (zram_same_page_write(zram, index, page))
> > -   return 0;
> > +   goto out_unlock;
> >  
> > entry = zram_dedup_find(zram, page, );
> > if (entry) {
> > comp_len = entry->len;
> > +   zram_set_flag(zram, index, ZRAM_DUP);
>
> In case of hitting dedup, we shouldn't increase compr_data_size.

no, we should not. you are right. my "... patch" is incomplete and
wrong. please don't pay too much attention to it.


> If we fix above two problems, do you think it's still cleaner?
> (I don't mean to be reluctant with your suggestion. Just a
>  real question to know your thought.:)

do you mean code duplication and stale data read?

I'd probably prefer to address stale data reads separately.
but it seems that stale reads fix will re-do parts of your
0002 patch and, at least potentially, reduce code duplication.

so we can go with your 0002 and then stale reads fix will try
to reduce code duplication (unless we want to have 4 places doing
the same thing :) )

-ss

Re: [PATCH] usb: class: usblp: Fixed assignments inside if conditions

[kbuild test robot]

Hi Alberto,

[auto build test ERROR on usb/usb-testing]
[also build test ERROR on v4.12-rc1 next-20170515]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Alberto-Ladron/usb-class-usblp-Fixed-assignments-inside-if-conditions/20170513-140010
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers//usb/class/usblp.c: In function 'usblp_submit_read':
>> drivers//usb/class/usblp.c:1021:6: error: 'rv' undeclared (first use in this 
>> function)
 if (rv < 0) {
 ^~
   drivers//usb/class/usblp.c:1021:6: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/rv +1021 drivers//usb/class/usblp.c

  1005  urb = usb_alloc_urb(0, GFP_KERNEL);
  1006  if (urb == NULL)
  1007  goto raise_urb;
  1008  
  1009  usb_fill_bulk_urb(urb, usblp->dev,
  1010  usb_rcvbulkpipe(usblp->dev,
  1011
usblp->protocol[usblp->current_protocol].epread->bEndpointAddress),
  1012  usblp->readbuf, USBLP_BUF_SIZE_IN,
  1013  usblp_bulk_read, usblp);
  1014  usb_anchor_urb(urb, >urbs);
  1015  
  1016  spin_lock_irqsave(>lock, flags);
  1017  usblp->readcount = 0; /* XXX Why here? */
  1018  usblp->rcomplete = 0;
  1019  spin_unlock_irqrestore(>lock, flags);
  1020  rc = usb_submit_urb(urb, GFP_KERNEL);
> 1021  if (rv < 0) {
  1022  dev_dbg(>intf->dev, "error submitting urb 
(%d)\n", rc);
  1023  spin_lock_irqsave(>lock, flags);
  1024  usblp->rstatus = rc;
  1025  usblp->rcomplete = 1;
  1026  spin_unlock_irqrestore(>lock, flags);
  1027  goto raise_submit;
  1028  }
  1029  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH] usb: class: usblp: Fixed assignments inside if conditions

[kbuild test robot]

Hi Alberto,

[auto build test ERROR on usb/usb-testing]
[also build test ERROR on v4.12-rc1 next-20170515]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Alberto-Ladron/usb-class-usblp-Fixed-assignments-inside-if-conditions/20170513-140010
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers//usb/class/usblp.c: In function 'usblp_submit_read':
>> drivers//usb/class/usblp.c:1021:6: error: 'rv' undeclared (first use in this 
>> function)
 if (rv < 0) {
 ^~
   drivers//usb/class/usblp.c:1021:6: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/rv +1021 drivers//usb/class/usblp.c

  1005  urb = usb_alloc_urb(0, GFP_KERNEL);
  1006  if (urb == NULL)
  1007  goto raise_urb;
  1008  
  1009  usb_fill_bulk_urb(urb, usblp->dev,
  1010  usb_rcvbulkpipe(usblp->dev,
  1011
usblp->protocol[usblp->current_protocol].epread->bEndpointAddress),
  1012  usblp->readbuf, USBLP_BUF_SIZE_IN,
  1013  usblp_bulk_read, usblp);
  1014  usb_anchor_urb(urb, >urbs);
  1015  
  1016  spin_lock_irqsave(>lock, flags);
  1017  usblp->readcount = 0; /* XXX Why here? */
  1018  usblp->rcomplete = 0;
  1019  spin_unlock_irqrestore(>lock, flags);
  1020  rc = usb_submit_urb(urb, GFP_KERNEL);
> 1021  if (rv < 0) {
  1022  dev_dbg(>intf->dev, "error submitting urb 
(%d)\n", rc);
  1023  spin_lock_irqsave(>lock, flags);
  1024  usblp->rstatus = rc;
  1025  usblp->rcomplete = 1;
  1026  spin_unlock_irqrestore(>lock, flags);
  1027  goto raise_submit;
  1028  }
  1029  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[GIT PULL] s390 patches for 4.12-rc2

[Martin Schwidefsky]

Hi Linus,

please pull from the 'for-linus' branch of

git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus

to receive the following updates:

 * Convert the debug feature to refcount_t

 * Reduce the copy size for strncpy_from_user

 * 8 bug fixes

Elena Reshetova (1):
  s390: convert debug_info.ref_count from atomic_t to refcount_t

Heiko Carstens (8):
  s390/ftrace: fix compile for !MODULES
  s390/uprobes: fix compile for !KPROBES
  s390/uaccess: use sane length for __strncpy_from_user()
  s390/topology: let topology_mnest_limit() return unsigned char
  s390/ccwgroup: increase string buffer size
  s390/qdio: increase string buffer size
  s390: move _text symbol to address higher than zero
  s390/virtio: change virtio_feature_desc:features type to __le32

Martin Schwidefsky (1):
  s390/cputime: fix incorrect system time

 arch/s390/include/asm/debug.h|  3 ++-
 arch/s390/include/asm/dis.h  |  2 ++
 arch/s390/include/asm/kprobes.h  | 20 ++--
 arch/s390/include/asm/sysinfo.h  |  2 +-
 arch/s390/kernel/debug.c |  8 
 arch/s390/kernel/entry.S | 21 ++---
 arch/s390/kernel/ftrace.c|  4 
 arch/s390/kernel/vmlinux.lds.S   |  8 +++-
 arch/s390/lib/probes.c   |  1 +
 arch/s390/lib/uaccess.c  |  4 ++--
 drivers/s390/cio/ccwgroup.c  |  4 ++--
 drivers/s390/cio/qdio_debug.h|  2 +-
 drivers/s390/virtio/virtio_ccw.c |  2 +-
 13 files changed, 55 insertions(+), 26 deletions(-)

diff --git a/arch/s390/include/asm/debug.h b/arch/s390/include/asm/debug.h
index 0206c80..df7b54e 100644
--- a/arch/s390/include/asm/debug.h
+++ b/arch/s390/include/asm/debug.h
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define DEBUG_MAX_LEVEL6  /* debug levels range from 0 to 6 */
@@ -31,7 +32,7 @@ struct debug_view;
 typedef struct debug_info {
struct debug_info* next;
struct debug_info* prev;
-   atomic_t ref_count;
+   refcount_t ref_count;
spinlock_t lock;
int level;
int nr_areas;
diff --git a/arch/s390/include/asm/dis.h b/arch/s390/include/asm/dis.h
index 60323c2..37f617d 100644
--- a/arch/s390/include/asm/dis.h
+++ b/arch/s390/include/asm/dis.h
@@ -40,6 +40,8 @@ static inline int insn_length(unsigned char code)
return int) code + 64) >> 7) + 1) << 1;
 }
 
+struct pt_regs;
+
 void show_code(struct pt_regs *regs);
 void print_fn_code(unsigned char *code, unsigned long len);
 int insn_to_mnemonic(unsigned char *instruction, char *buf, unsigned int len);
diff --git a/arch/s390/include/asm/kprobes.h b/arch/s390/include/asm/kprobes.h
index 1293c40..28792ef 100644
--- a/arch/s390/include/asm/kprobes.h
+++ b/arch/s390/include/asm/kprobes.h
@@ -27,12 +27,21 @@
  * 2005-DecUsed as a template for s390 by Mike Grundy
  * 
  */
+#include 
 #include 
 
 #define BREAKPOINT_INSTRUCTION 0x0002
 
+#define FIXUP_PSW_NORMAL   0x08
+#define FIXUP_BRANCH_NOT_TAKEN 0x04
+#define FIXUP_RETURN_REGISTER  0x02
+#define FIXUP_NOT_REQUIRED 0x01
+
+int probe_is_prohibited_opcode(u16 *insn);
+int probe_get_fixup_type(u16 *insn);
+int probe_is_insn_relative_long(u16 *insn);
+
 #ifdef CONFIG_KPROBES
-#include 
 #include 
 #include 
 #include 
@@ -56,11 +65,6 @@ typedef u16 kprobe_opcode_t;
 
 #define KPROBE_SWAP_INST   0x10
 
-#define FIXUP_PSW_NORMAL   0x08
-#define FIXUP_BRANCH_NOT_TAKEN 0x04
-#define FIXUP_RETURN_REGISTER  0x02
-#define FIXUP_NOT_REQUIRED 0x01
-
 /* Architecture specific copy of original instruction */
 struct arch_specific_insn {
/* copy of original instruction */
@@ -90,10 +94,6 @@ int kprobe_fault_handler(struct pt_regs *regs, int trapnr);
 int kprobe_exceptions_notify(struct notifier_block *self,
unsigned long val, void *data);
 
-int probe_is_prohibited_opcode(u16 *insn);
-int probe_get_fixup_type(u16 *insn);
-int probe_is_insn_relative_long(u16 *insn);
-
 #define flush_insn_slot(p) do { } while (0)
 
 #endif /* CONFIG_KPROBES */
diff --git a/arch/s390/include/asm/sysinfo.h b/arch/s390/include/asm/sysinfo.h
index 73bff45..e784bed 100644
--- a/arch/s390/include/asm/sysinfo.h
+++ b/arch/s390/include/asm/sysinfo.h
@@ -146,7 +146,7 @@ extern int topology_max_mnest;
  * Returns the maximum nesting level supported by the cpu topology code.
  * The current maximum level is 4 which is the drawer level.
  */
-static inline int topology_mnest_limit(void)
+static inline unsigned char topology_mnest_limit(void)
 {
return min(topology_max_mnest, 4);
 }
diff --git a/arch/s390/kernel/debug.c b/arch/s390/kernel/debug.c
index 530226b..86b3e74 100644
--- a/arch/s390/kernel/debug.c
+++ b/arch/s390/kernel/debug.c
@@ -277,7 +277,7 @@ debug_info_alloc(const char *name, int pages_per_area, int 
nr_areas,
memset(rc->views, 0, DEBUG_MAX_VIEWS * sizeof(struct debug_view *));

[GIT PULL] s390 patches for 4.12-rc2

[Martin Schwidefsky]

Hi Linus,

please pull from the 'for-linus' branch of

git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus

to receive the following updates:

 * Convert the debug feature to refcount_t

 * Reduce the copy size for strncpy_from_user

 * 8 bug fixes

Elena Reshetova (1):
  s390: convert debug_info.ref_count from atomic_t to refcount_t

Heiko Carstens (8):
  s390/ftrace: fix compile for !MODULES
  s390/uprobes: fix compile for !KPROBES
  s390/uaccess: use sane length for __strncpy_from_user()
  s390/topology: let topology_mnest_limit() return unsigned char
  s390/ccwgroup: increase string buffer size
  s390/qdio: increase string buffer size
  s390: move _text symbol to address higher than zero
  s390/virtio: change virtio_feature_desc:features type to __le32

Martin Schwidefsky (1):
  s390/cputime: fix incorrect system time

 arch/s390/include/asm/debug.h|  3 ++-
 arch/s390/include/asm/dis.h  |  2 ++
 arch/s390/include/asm/kprobes.h  | 20 ++--
 arch/s390/include/asm/sysinfo.h  |  2 +-
 arch/s390/kernel/debug.c |  8 
 arch/s390/kernel/entry.S | 21 ++---
 arch/s390/kernel/ftrace.c|  4 
 arch/s390/kernel/vmlinux.lds.S   |  8 +++-
 arch/s390/lib/probes.c   |  1 +
 arch/s390/lib/uaccess.c  |  4 ++--
 drivers/s390/cio/ccwgroup.c  |  4 ++--
 drivers/s390/cio/qdio_debug.h|  2 +-
 drivers/s390/virtio/virtio_ccw.c |  2 +-
 13 files changed, 55 insertions(+), 26 deletions(-)

diff --git a/arch/s390/include/asm/debug.h b/arch/s390/include/asm/debug.h
index 0206c80..df7b54e 100644
--- a/arch/s390/include/asm/debug.h
+++ b/arch/s390/include/asm/debug.h
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define DEBUG_MAX_LEVEL6  /* debug levels range from 0 to 6 */
@@ -31,7 +32,7 @@ struct debug_view;
 typedef struct debug_info {
struct debug_info* next;
struct debug_info* prev;
-   atomic_t ref_count;
+   refcount_t ref_count;
spinlock_t lock;
int level;
int nr_areas;
diff --git a/arch/s390/include/asm/dis.h b/arch/s390/include/asm/dis.h
index 60323c2..37f617d 100644
--- a/arch/s390/include/asm/dis.h
+++ b/arch/s390/include/asm/dis.h
@@ -40,6 +40,8 @@ static inline int insn_length(unsigned char code)
return int) code + 64) >> 7) + 1) << 1;
 }
 
+struct pt_regs;
+
 void show_code(struct pt_regs *regs);
 void print_fn_code(unsigned char *code, unsigned long len);
 int insn_to_mnemonic(unsigned char *instruction, char *buf, unsigned int len);
diff --git a/arch/s390/include/asm/kprobes.h b/arch/s390/include/asm/kprobes.h
index 1293c40..28792ef 100644
--- a/arch/s390/include/asm/kprobes.h
+++ b/arch/s390/include/asm/kprobes.h
@@ -27,12 +27,21 @@
  * 2005-DecUsed as a template for s390 by Mike Grundy
  * 
  */
+#include 
 #include 
 
 #define BREAKPOINT_INSTRUCTION 0x0002
 
+#define FIXUP_PSW_NORMAL   0x08
+#define FIXUP_BRANCH_NOT_TAKEN 0x04
+#define FIXUP_RETURN_REGISTER  0x02
+#define FIXUP_NOT_REQUIRED 0x01
+
+int probe_is_prohibited_opcode(u16 *insn);
+int probe_get_fixup_type(u16 *insn);
+int probe_is_insn_relative_long(u16 *insn);
+
 #ifdef CONFIG_KPROBES
-#include 
 #include 
 #include 
 #include 
@@ -56,11 +65,6 @@ typedef u16 kprobe_opcode_t;
 
 #define KPROBE_SWAP_INST   0x10
 
-#define FIXUP_PSW_NORMAL   0x08
-#define FIXUP_BRANCH_NOT_TAKEN 0x04
-#define FIXUP_RETURN_REGISTER  0x02
-#define FIXUP_NOT_REQUIRED 0x01
-
 /* Architecture specific copy of original instruction */
 struct arch_specific_insn {
/* copy of original instruction */
@@ -90,10 +94,6 @@ int kprobe_fault_handler(struct pt_regs *regs, int trapnr);
 int kprobe_exceptions_notify(struct notifier_block *self,
unsigned long val, void *data);
 
-int probe_is_prohibited_opcode(u16 *insn);
-int probe_get_fixup_type(u16 *insn);
-int probe_is_insn_relative_long(u16 *insn);
-
 #define flush_insn_slot(p) do { } while (0)
 
 #endif /* CONFIG_KPROBES */
diff --git a/arch/s390/include/asm/sysinfo.h b/arch/s390/include/asm/sysinfo.h
index 73bff45..e784bed 100644
--- a/arch/s390/include/asm/sysinfo.h
+++ b/arch/s390/include/asm/sysinfo.h
@@ -146,7 +146,7 @@ extern int topology_max_mnest;
  * Returns the maximum nesting level supported by the cpu topology code.
  * The current maximum level is 4 which is the drawer level.
  */
-static inline int topology_mnest_limit(void)
+static inline unsigned char topology_mnest_limit(void)
 {
return min(topology_max_mnest, 4);
 }
diff --git a/arch/s390/kernel/debug.c b/arch/s390/kernel/debug.c
index 530226b..86b3e74 100644
--- a/arch/s390/kernel/debug.c
+++ b/arch/s390/kernel/debug.c
@@ -277,7 +277,7 @@ debug_info_alloc(const char *name, int pages_per_area, int 
nr_areas,
memset(rc->views, 0, DEBUG_MAX_VIEWS * sizeof(struct debug_view *));

[PATCH] test: check a case when a mount is propagated between exiting mounts

[Andrei Vagin]

This test checks two behaviour cases:

When a mount is propagated to a place which is already busy, the new
mount is inserted between parent and old mount.

When a mount that is being unmounted due to propagation has another
mount on top of it, it is replaced by the top mount.

Cc: Shuah Khan 
Signed-off-by: Andrei Vagin 
---
 tools/testing/selftests/mount/Makefile | 19 +++--
 tools/testing/selftests/mount/test-reparent-mounts | 92 ++
 2 files changed, 105 insertions(+), 6 deletions(-)
 create mode 100755 tools/testing/selftests/mount/test-reparent-mounts

diff --git a/tools/testing/selftests/mount/Makefile 
b/tools/testing/selftests/mount/Makefile
index 9093d7f..5927230 100644
--- a/tools/testing/selftests/mount/Makefile
+++ b/tools/testing/selftests/mount/Makefile
@@ -6,11 +6,18 @@ TEST_GEN_PROGS := unprivileged-remount-test
 
 include ../lib.mk
 
-override RUN_TESTS := if [ -f /proc/self/uid_map ] ; \
- then  \
-   ./unprivileged-remount-test ; \
- else  \
-   echo "WARN: No /proc/self/uid_map exist, test 
skipped." ; \
- fi
+override define RUN_TESTS
+   if [ -f /proc/self/uid_map ] ; \
+   then\
+   ./unprivileged-remount-test ; \
+   else\
+   echo "WARN: No /proc/self/uid_map exist, test skipped." ; \
+   fi
+   unshare -Urm ./test-reparent-mounts
+   unshare -Urm ./test-reparent-mounts -c
+   unshare -Urm ./test-reparent-mounts -s
+   unshare -Urm ./test-reparent-mounts -s -S
+endef
+
 override EMIT_TESTS := echo "$(RUN_TESTS)"
 
diff --git a/tools/testing/selftests/mount/test-reparent-mounts 
b/tools/testing/selftests/mount/test-reparent-mounts
new file mode 100755
index 000..57ae300
--- /dev/null
+++ b/tools/testing/selftests/mount/test-reparent-mounts
@@ -0,0 +1,92 @@
+#!/bin/sh
+
+# This test checks two following behaviour cases:
+#
+# When a mount is propagated to a place which is already busy, the new mount is
+# inserted between parent and old mount.
+#
+# When a mount that is being unmounted due to propagation has another mount on
+# top of it, it is replaced by the top mount.
+
+ITER=3
+
+set -e
+
+usage()
+{
+   echo " ./$0 [OPTIONS]
+This test checks a case when a mount has to be propagated under another mount.
+   -c - create a mount which is visible only from the second tree
+   -s - make a second tree as a slave to the first one
+   -S - create a sub-mount when the send tree is a slave to the first one
+   -i - how many times to call mount
+"
+}
+
+while getopts "csi:hS" opt; do
+   case $opt in
+   c )  with_child=1;;
+   s )  make_slave=1;;
+   S )  slave_child=1;;
+   i )  ITER=$OPTARG;;
+   h )  usage; exit 0 ;;
+   esac
+done
+
+shift $(($OPTIND - 1))
+
+if [ -n "$1" ]; then
+   usage
+   exit 1
+fi
+
+mount -t tmpfs test /mnt
+mkdir /mnt/main
+mkdir /mnt/second
+mount --bind /mnt/main /mnt/main
+mount --make-shared /mnt/main
+mount --bind /mnt/main /mnt/second
+mkdir -p /mnt/main/sub
+
+if [ -n "$make_slave" ]; then
+   mount --make-slave /mnt/second
+   if [ -n "slave_child" ]; then
+   mount -t tmpfs slave_child /mnt/second/sub/
+   touch /mnt/second/sub/slave_child
+   fi
+fi
+
+if [ -n "$make_slave" ]; then
+   mount --make-slave /mnt/second
+   if [ -n "$slave_child" ]; then
+   mount -t tmpfs test_slave /mnt/second/sub/
+   touch /mnt/second/sub/slave_child
+   fi
+fi
+
+for i in `seq $ITER`; do
+   mount --bind /mnt/main/sub /mnt/main/sub
+done
+
+if [ -n "$with_child" ]; then
+   mkdir /mnt/second/sub/child
+   mount --make-private /mnt/second/sub
+   mount --bind /mnt/second/sub/child /mnt/second/sub/child
+fi
+if [ -n "$slave_child" ]; then
+   test -f /mnt/second/sub/slave_child
+fi
+
+umount /mnt/main/sub
+
+if [ -n "$with_child" ]; then
+   umount /mnt/second/sub/child
+   umount /mnt/second/sub
+fi
+if [ -n "$slave_child" ]; then
+   test -f /mnt/second/sub/slave_child
+   umount /mnt/second/sub
+fi
+
+umount /mnt/second
+umount /mnt/main
-- 
2.9.3

[PATCH] test: check a case when a mount is propagated between exiting mounts

[Andrei Vagin]

This test checks two behaviour cases:

When a mount is propagated to a place which is already busy, the new
mount is inserted between parent and old mount.

When a mount that is being unmounted due to propagation has another
mount on top of it, it is replaced by the top mount.

Cc: Shuah Khan 
Signed-off-by: Andrei Vagin 
---
 tools/testing/selftests/mount/Makefile | 19 +++--
 tools/testing/selftests/mount/test-reparent-mounts | 92 ++
 2 files changed, 105 insertions(+), 6 deletions(-)
 create mode 100755 tools/testing/selftests/mount/test-reparent-mounts

diff --git a/tools/testing/selftests/mount/Makefile 
b/tools/testing/selftests/mount/Makefile
index 9093d7f..5927230 100644
--- a/tools/testing/selftests/mount/Makefile
+++ b/tools/testing/selftests/mount/Makefile
@@ -6,11 +6,18 @@ TEST_GEN_PROGS := unprivileged-remount-test
 
 include ../lib.mk
 
-override RUN_TESTS := if [ -f /proc/self/uid_map ] ; \
- then  \
-   ./unprivileged-remount-test ; \
- else  \
-   echo "WARN: No /proc/self/uid_map exist, test 
skipped." ; \
- fi
+override define RUN_TESTS
+   if [ -f /proc/self/uid_map ] ; \
+   then\
+   ./unprivileged-remount-test ; \
+   else\
+   echo "WARN: No /proc/self/uid_map exist, test skipped." ; \
+   fi
+   unshare -Urm ./test-reparent-mounts
+   unshare -Urm ./test-reparent-mounts -c
+   unshare -Urm ./test-reparent-mounts -s
+   unshare -Urm ./test-reparent-mounts -s -S
+endef
+
 override EMIT_TESTS := echo "$(RUN_TESTS)"
 
diff --git a/tools/testing/selftests/mount/test-reparent-mounts 
b/tools/testing/selftests/mount/test-reparent-mounts
new file mode 100755
index 000..57ae300
--- /dev/null
+++ b/tools/testing/selftests/mount/test-reparent-mounts
@@ -0,0 +1,92 @@
+#!/bin/sh
+
+# This test checks two following behaviour cases:
+#
+# When a mount is propagated to a place which is already busy, the new mount is
+# inserted between parent and old mount.
+#
+# When a mount that is being unmounted due to propagation has another mount on
+# top of it, it is replaced by the top mount.
+
+ITER=3
+
+set -e
+
+usage()
+{
+   echo " ./$0 [OPTIONS]
+This test checks a case when a mount has to be propagated under another mount.
+   -c - create a mount which is visible only from the second tree
+   -s - make a second tree as a slave to the first one
+   -S - create a sub-mount when the send tree is a slave to the first one
+   -i - how many times to call mount
+"
+}
+
+while getopts "csi:hS" opt; do
+   case $opt in
+   c )  with_child=1;;
+   s )  make_slave=1;;
+   S )  slave_child=1;;
+   i )  ITER=$OPTARG;;
+   h )  usage; exit 0 ;;
+   esac
+done
+
+shift $(($OPTIND - 1))
+
+if [ -n "$1" ]; then
+   usage
+   exit 1
+fi
+
+mount -t tmpfs test /mnt
+mkdir /mnt/main
+mkdir /mnt/second
+mount --bind /mnt/main /mnt/main
+mount --make-shared /mnt/main
+mount --bind /mnt/main /mnt/second
+mkdir -p /mnt/main/sub
+
+if [ -n "$make_slave" ]; then
+   mount --make-slave /mnt/second
+   if [ -n "slave_child" ]; then
+   mount -t tmpfs slave_child /mnt/second/sub/
+   touch /mnt/second/sub/slave_child
+   fi
+fi
+
+if [ -n "$make_slave" ]; then
+   mount --make-slave /mnt/second
+   if [ -n "$slave_child" ]; then
+   mount -t tmpfs test_slave /mnt/second/sub/
+   touch /mnt/second/sub/slave_child
+   fi
+fi
+
+for i in `seq $ITER`; do
+   mount --bind /mnt/main/sub /mnt/main/sub
+done
+
+if [ -n "$with_child" ]; then
+   mkdir /mnt/second/sub/child
+   mount --make-private /mnt/second/sub
+   mount --bind /mnt/second/sub/child /mnt/second/sub/child
+fi
+if [ -n "$slave_child" ]; then
+   test -f /mnt/second/sub/slave_child
+fi
+
+umount /mnt/main/sub
+
+if [ -n "$with_child" ]; then
+   umount /mnt/second/sub/child
+   umount /mnt/second/sub
+fi
+if [ -n "$slave_child" ]; then
+   test -f /mnt/second/sub/slave_child
+   umount /mnt/second/sub
+fi
+
+umount /mnt/second
+umount /mnt/main
-- 
2.9.3

Re: [PATCH v3 00/11] soc/fsl/qbman: Enable QBMan on ARM Platforms

[Scott Wood]

On Mon, 2017-05-01 at 17:30 -0400, Roy Pledge wrote:
> This patch series enables DPAA1 QBMan devices for ARM and
> ARM64 architectures. This allows the LS1043A and LS1046A to use
> QBMan functionality.
> 
> Changes since v2:
> Fixed some misspellings
> Added 'no-map' constraint to device tree bindings
> Described ordering contraint on regions in the device tree
> Removed confusing comment regarding non-shareable mappings
> Added warning if old reserved-memory technique is used on ARM
> 
> Changes since v1:
> Reworked private memory allocations to use shared-dma-pool on ARM platforms
> 
> Claudiu Manoil (2):
>   soc/fsl/qbman: Drop L1_CACHE_BYTES compile time check
>   soc/fsl/qbman: Add missing headers on ARM
> 
> Madalin Bucur (4):
>   soc/fsl/qbman: Drop set/clear_bits usage
>   soc/fsl/qbman: add QMAN_REV32
>   soc/fsl/qbman: different register offsets on ARM
>   fsl/soc/qbman: Enable FSL_LAYERSCAPE config on ARM
> 
> Roy Pledge (4):
>   soc/fsl/qbman: Use shared-dma-pool for BMan private memory allocations
>   soc/fsl/qbman: Use shared-dma-pool for QMan private memory allocations
>   dt-bindings: soc/fsl: Update reserved memory binding for QBMan
>   soc/fsl/qbman: Rework ioremap() calls for ARM/PPC
> 
> Valentin Rothberg (1):
>   soc/fsl/qbman: Fix ARM32 typo

Acked-by: Scott Wood 

-Scott

Re: [PATCH v3 00/11] soc/fsl/qbman: Enable QBMan on ARM Platforms

[Scott Wood]

On Mon, 2017-05-01 at 17:30 -0400, Roy Pledge wrote:
> This patch series enables DPAA1 QBMan devices for ARM and
> ARM64 architectures. This allows the LS1043A and LS1046A to use
> QBMan functionality.
> 
> Changes since v2:
> Fixed some misspellings
> Added 'no-map' constraint to device tree bindings
> Described ordering contraint on regions in the device tree
> Removed confusing comment regarding non-shareable mappings
> Added warning if old reserved-memory technique is used on ARM
> 
> Changes since v1:
> Reworked private memory allocations to use shared-dma-pool on ARM platforms
> 
> Claudiu Manoil (2):
>   soc/fsl/qbman: Drop L1_CACHE_BYTES compile time check
>   soc/fsl/qbman: Add missing headers on ARM
> 
> Madalin Bucur (4):
>   soc/fsl/qbman: Drop set/clear_bits usage
>   soc/fsl/qbman: add QMAN_REV32
>   soc/fsl/qbman: different register offsets on ARM
>   fsl/soc/qbman: Enable FSL_LAYERSCAPE config on ARM
> 
> Roy Pledge (4):
>   soc/fsl/qbman: Use shared-dma-pool for BMan private memory allocations
>   soc/fsl/qbman: Use shared-dma-pool for QMan private memory allocations
>   dt-bindings: soc/fsl: Update reserved memory binding for QBMan
>   soc/fsl/qbman: Rework ioremap() calls for ARM/PPC
> 
> Valentin Rothberg (1):
>   soc/fsl/qbman: Fix ARM32 typo

Acked-by: Scott Wood 

-Scott

RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

[Zheng, Lv]

Hi, Guys

> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to 
> lid_init_state=open"
> 
> On May 15 2017 or thereabouts, Rafael J. Wysocki wrote:
> > On Mon, May 15, 2017 at 11:37 AM, Benjamin Tissoires
> >  wrote:
> > > On May 15 2017 or thereabouts, Rafael J. Wysocki wrote:
> > >> On Mon, May 15, 2017 at 9:45 AM, Benjamin Tissoires
> > >>  wrote:
> > >> > On May 12 2017 or thereabouts, Rafael J. Wysocki wrote:
> > >> >> On Friday, May 12, 2017 02:36:20 AM Zheng, Lv wrote:
> > >> >> > Hi,
> > >> >> >
> > >> >> > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> > >> >> > > Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default 
> > >> >> > > behavior to
> lid_init_state=open"
> > >> >> > >
> > >> >> > > On May 11 2017 or thereabouts, Zheng, Lv wrote:
> > >> >> > > > Hi,
> > >> >> > > >
> > >> >> > > > > From: Benjamin Tissoires 
> > >> >> > > > > [mailto:benjamin.tissoi...@redhat.com]
> > >> >> > > > > Subject: [PATCH 2/2] Revert "ACPI / button: Change default 
> > >> >> > > > > behavior to
> lid_init_state=open"
> > >> >> > > > >
> > >> >> > > > > This reverts commit 77e9a4aa9de10cc1418bf9a892366988802a8025.
> > >> >> > > > >
> > >> >> > > > > Even if the method implementation can be buggy on some 
> > >> >> > > > > platform,
> > >> >> > > > > the "open" choice is worse. It breaks docking stations 
> > >> >> > > > > basically
> > >> >> > > > > and there is no way to have a user-space hwdb to fix that.
> > >> >> > > > >
> > >> >> > > > > On the contrary, it's rather easy in user-space to have a hwdb
> > >> >> > > > > with the problematic platforms. Then, libinput (1.7.0+) can 
> > >> >> > > > > fix
> > >> >> > > > > the state of the LID switch for us: you need to set the udev
> > >> >> > > > > property LIBINPUT_ATTR_LID_SWITCH_RELIABILITY to 'write_open'.
> > >> >> > > > >
> > >> >> > > > > When libinput detects internal keyboard events, it will
> > >> >> > > > > overwrite the state of the switch to open, making it reliable
> > >> >> > > > > again. Given that logind only checks the LID switch value 
> > >> >> > > > > after
> > >> >> > > > > a timeout, we can assume the user will use the internal 
> > >> >> > > > > keyboard
> > >> >> > > > > before this timeout expires.
> > >> >> > > > >
> > >> >> > > > > For example, such a hwdb entry is:
> > >> >> > > > >
> > >> >> > > > > libinput:name:*Lid 
> > >> >> > > > > Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:*
> > >> >> > > > >  LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open
> > >> >> > > >
> > >> >
> > >> > [...]
> > >> >
> > >> >>
> > >> >> Well, if it worked in a specific way that users depended on before 
> > >> >> the commit in
> > >> >> question and now it works differently, then it does break things.
> > >> >>
> > >> >> Benjamin, my understanding is that this is the case, is it correct?
> > >> >
> > >> > That is correct. This patch I reverted introduces regression for 
> > >> > professional
> > >> > laptops that expect the LID switch to be reported accurately.
> > >>
> > >> And from a user's perspective, what does not work any more?
> > >
> > > If you boot or resume your laptop with the lid closed on a docking
> > > station while using an external monitor connected to it, both internal
> > > and external displays will light on, while only the external should.
> > >
> > > There is a design choice in gdm to only provide the greater on the
> > > internal display when lit on, so users only see a gray area on the
> > > external monitor. Also, the cursor will not show up as it's by default
> > > on the internal display too.
> > >
> > > To "fix" that, users have to open the laptop once and close it once
> > > again to sync the state of the switch with the hardware state.
> >
> > OK
> >
> > Yeah, that sucks.
> >
> > So without the Lv's patch the behavior (on the systems in question) is
> > as expected, right?
> >
> 
> Yes, reverting these 2 patches restores the pre v4.11 kernel behavior.

I would make an argument that:
A. Is this necessarily a button driver regression?
1. Users already configured to not using internal display, why gdm need to 
determine it again instead of users choice?
2. Can gdm/graphics driver saves state before suspend, and restores saved state 
after resume?
   If users didn't change state during suspend, then everything should be 
correct.
   If users changed state during suspend, it should be acceptable for users to 
change it again to make the state correct.
See, this is obviously a case that is not so strictly related to ACPI button 
driver.
Why do we need to force button driver to marry external monitors.
B. Bug reporters are all ok with using quirk modes as boot parameters to work 
this around.
Why should we change our default behavior aimlessly?

Thanks and best regards
Lv

RE: [PATCH 2/2] Revert "ACPI / button: Change default behavior to lid_init_state=open"

[Zheng, Lv]

Hi, Guys

> From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default behavior to 
> lid_init_state=open"
> 
> On May 15 2017 or thereabouts, Rafael J. Wysocki wrote:
> > On Mon, May 15, 2017 at 11:37 AM, Benjamin Tissoires
> >  wrote:
> > > On May 15 2017 or thereabouts, Rafael J. Wysocki wrote:
> > >> On Mon, May 15, 2017 at 9:45 AM, Benjamin Tissoires
> > >>  wrote:
> > >> > On May 12 2017 or thereabouts, Rafael J. Wysocki wrote:
> > >> >> On Friday, May 12, 2017 02:36:20 AM Zheng, Lv wrote:
> > >> >> > Hi,
> > >> >> >
> > >> >> > > From: Benjamin Tissoires [mailto:benjamin.tissoi...@redhat.com]
> > >> >> > > Subject: Re: [PATCH 2/2] Revert "ACPI / button: Change default 
> > >> >> > > behavior to
> lid_init_state=open"
> > >> >> > >
> > >> >> > > On May 11 2017 or thereabouts, Zheng, Lv wrote:
> > >> >> > > > Hi,
> > >> >> > > >
> > >> >> > > > > From: Benjamin Tissoires 
> > >> >> > > > > [mailto:benjamin.tissoi...@redhat.com]
> > >> >> > > > > Subject: [PATCH 2/2] Revert "ACPI / button: Change default 
> > >> >> > > > > behavior to
> lid_init_state=open"
> > >> >> > > > >
> > >> >> > > > > This reverts commit 77e9a4aa9de10cc1418bf9a892366988802a8025.
> > >> >> > > > >
> > >> >> > > > > Even if the method implementation can be buggy on some 
> > >> >> > > > > platform,
> > >> >> > > > > the "open" choice is worse. It breaks docking stations 
> > >> >> > > > > basically
> > >> >> > > > > and there is no way to have a user-space hwdb to fix that.
> > >> >> > > > >
> > >> >> > > > > On the contrary, it's rather easy in user-space to have a hwdb
> > >> >> > > > > with the problematic platforms. Then, libinput (1.7.0+) can 
> > >> >> > > > > fix
> > >> >> > > > > the state of the LID switch for us: you need to set the udev
> > >> >> > > > > property LIBINPUT_ATTR_LID_SWITCH_RELIABILITY to 'write_open'.
> > >> >> > > > >
> > >> >> > > > > When libinput detects internal keyboard events, it will
> > >> >> > > > > overwrite the state of the switch to open, making it reliable
> > >> >> > > > > again. Given that logind only checks the LID switch value 
> > >> >> > > > > after
> > >> >> > > > > a timeout, we can assume the user will use the internal 
> > >> >> > > > > keyboard
> > >> >> > > > > before this timeout expires.
> > >> >> > > > >
> > >> >> > > > > For example, such a hwdb entry is:
> > >> >> > > > >
> > >> >> > > > > libinput:name:*Lid 
> > >> >> > > > > Switch*:dmi:*svnMicrosoftCorporation:pnSurface3:*
> > >> >> > > > >  LIBINPUT_ATTR_LID_SWITCH_RELIABILITY=write_open
> > >> >> > > >
> > >> >
> > >> > [...]
> > >> >
> > >> >>
> > >> >> Well, if it worked in a specific way that users depended on before 
> > >> >> the commit in
> > >> >> question and now it works differently, then it does break things.
> > >> >>
> > >> >> Benjamin, my understanding is that this is the case, is it correct?
> > >> >
> > >> > That is correct. This patch I reverted introduces regression for 
> > >> > professional
> > >> > laptops that expect the LID switch to be reported accurately.
> > >>
> > >> And from a user's perspective, what does not work any more?
> > >
> > > If you boot or resume your laptop with the lid closed on a docking
> > > station while using an external monitor connected to it, both internal
> > > and external displays will light on, while only the external should.
> > >
> > > There is a design choice in gdm to only provide the greater on the
> > > internal display when lit on, so users only see a gray area on the
> > > external monitor. Also, the cursor will not show up as it's by default
> > > on the internal display too.
> > >
> > > To "fix" that, users have to open the laptop once and close it once
> > > again to sync the state of the switch with the hardware state.
> >
> > OK
> >
> > Yeah, that sucks.
> >
> > So without the Lv's patch the behavior (on the systems in question) is
> > as expected, right?
> >
> 
> Yes, reverting these 2 patches restores the pre v4.11 kernel behavior.

I would make an argument that:
A. Is this necessarily a button driver regression?
1. Users already configured to not using internal display, why gdm need to 
determine it again instead of users choice?
2. Can gdm/graphics driver saves state before suspend, and restores saved state 
after resume?
   If users didn't change state during suspend, then everything should be 
correct.
   If users changed state during suspend, it should be acceptable for users to 
change it again to make the state correct.
See, this is obviously a case that is not so strictly related to ACPI button 
driver.
Why do we need to force button driver to marry external monitors.
B. Bug reporters are all ok with using quirk modes as boot parameters to work 
this around.
Why should we change our default behavior aimlessly?

Thanks and best regards
Lv

Re: [PATCH 1/2] ASoC: sun8i-codec: Add ADC support for a33

[Chen-Yu Tsai]

Hi,

On Wed, May 10, 2017 at 2:58 PM, Mylene Josserand
 wrote:
> Hi Chen-Yu,
>
> Thank you for the review!
>
>
> On 03/05/2017 19:13, Chen-Yu Tsai wrote:
>>
>> Hi,
>>
>> On Wed, May 3, 2017 at 9:56 PM, Mylène Josserand
>>  wrote:
>>>
>>> Add ADC support for the sun8i-codec driver.
>>>
>>> This driver uses all the microphones widgets and routes provided by the
>>> analog part (sun8i-codec-analog).
>>> Some digital configurations are needed by creating new ADC widgets
>>> and routes.
>>>
>>> Signed-off-by: Mylène Josserand 
>>> ---
>>>  sound/soc/sunxi/sun8i-codec.c | 80
>>> +--
>>>  1 file changed, 78 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/sound/soc/sunxi/sun8i-codec.c
>>> b/sound/soc/sunxi/sun8i-codec.c
>>> index 5723c3404f6b..b4938b06acec 100644
>>> --- a/sound/soc/sunxi/sun8i-codec.c
>>> +++ b/sound/soc/sunxi/sun8i-codec.c
>>> @@ -37,9 +37,11 @@
>>>  #define SUN8I_SYSCLK_CTL_SYSCLK_SRC0
>>>  #define SUN8I_MOD_CLK_ENA  0x010
>>>  #define SUN8I_MOD_CLK_ENA_AIF1 15
>>> +#define SUN8I_MOD_CLK_ENA_ADC  3
>>>  #define SUN8I_MOD_CLK_ENA_DAC  2
>>>  #define SUN8I_MOD_RST_CTL  0x014
>>>  #define SUN8I_MOD_RST_CTL_AIF1 15
>>> +#define SUN8I_MOD_RST_CTL_ADC  3
>>>  #define SUN8I_MOD_RST_CTL_DAC  2
>>>  #define SUN8I_SYS_SR_CTRL  0x018
>>>  #define SUN8I_SYS_SR_CTRL_AIF1_FS  12
>>> @@ -54,9 +56,25 @@
>>>  #define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ   4
>>>  #define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ_16(1 << 4)
>>>  #define SUN8I_AIF1CLK_CTRL_AIF1_DATA_FMT   2
>>> +#define SUN8I_AIF1_ADCDAT_CTRL 0x044
>>> +#define SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0L_ENA   15
>>> +#define SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0R_ENA   14
>>>  #define SUN8I_AIF1_DACDAT_CTRL 0x048
>>>  #define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0L_ENA   15
>>>  #define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA   14
>>> +#define SUN8I_AIF1_MXR_SRC 0x04c
>>> +#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF1DA0L   15
>>> +#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACL   14
>>> +#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_ADCL   13
>>> +#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACR   12
>>> +#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF1DA0R   11
>>> +#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACR   10
>>> +#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_ADCR   9
>>> +#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACL   8
>>> +#define SUN8I_ADC_DIG_CTRL 0x100
>>> +#define SUN8I_ADC_DIG_CTRL_ENDA15
>>
>>
>> The register bit name in the manual is ENAD, as in ENable ADc.
>
>
> Okay, I did not know that, thanks.
>
>
>>
>>> +#define SUN8I_ADC_DIG_CTRL_ADOUT_DTS   2
>>> +#define SUN8I_ADC_DIG_CTRL_ADOUT_DLY   1
>>>  #define SUN8I_DAC_DIG_CTRL 0x120
>>>  #define SUN8I_DAC_DIG_CTRL_ENDA15
>>>  #define SUN8I_DAC_MXR_SRC  0x130
>>> @@ -276,10 +294,28 @@ static const struct snd_kcontrol_new
>>> sun8i_dac_mixer_controls[] = {
>>> SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_ADCR, 1, 0),
>>>  };
>>>
>>> +static const struct snd_kcontrol_new sun8i_input_mixer_controls[] = {
>>> +   SOC_DAPM_DOUBLE("AIF1 Slot 0 Digital ADC Capture Switch",
>>> +   SUN8I_AIF1_MXR_SRC,
>>> +   SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF1DA0L,
>>> +   SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF1DA0R, 1, 0),
>>> +   SOC_DAPM_DOUBLE("AIF2 Digital ADC Capture Switch",
>>> SUN8I_AIF1_MXR_SRC,
>>> +   SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACL,
>>> +   SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACR, 1, 0),
>>> +   SOC_DAPM_DOUBLE("AIF1 Data Digital ADC Capture Switch",
>>> SUN8I_AIF1_MXR_SRC,
>>> +   SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_ADCL,
>>> +   SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_ADCR, 1, 0),
>>> +   SOC_DAPM_DOUBLE("AIF2 Inv Digital ADC Capture Switch",
>>> SUN8I_AIF1_MXR_SRC,
>>> +   SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACR,
>>> +   SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACL, 1, 0),
>>> +};
>>
>>
>> This group of mixer controls is only for AIF1 slot 0 capture.
>> So in fact they should all read "AIF1 Slot 0 Mixer X Capture Switch",
>> with X replaced by "AIF1 Slot 0", "AIF2", "ADC", and "AIF2 Inv".
>>
>> This hopefully informs the user that these controls are for the AIF1
>> slot 0 mixer, and 

Re: [PATCH 1/2] ASoC: sun8i-codec: Add ADC support for a33

[Chen-Yu Tsai]

Hi,

On Wed, May 10, 2017 at 2:58 PM, Mylene Josserand
 wrote:
> Hi Chen-Yu,
>
> Thank you for the review!
>
>
> On 03/05/2017 19:13, Chen-Yu Tsai wrote:
>>
>> Hi,
>>
>> On Wed, May 3, 2017 at 9:56 PM, Mylène Josserand
>>  wrote:
>>>
>>> Add ADC support for the sun8i-codec driver.
>>>
>>> This driver uses all the microphones widgets and routes provided by the
>>> analog part (sun8i-codec-analog).
>>> Some digital configurations are needed by creating new ADC widgets
>>> and routes.
>>>
>>> Signed-off-by: Mylène Josserand 
>>> ---
>>>  sound/soc/sunxi/sun8i-codec.c | 80
>>> +--
>>>  1 file changed, 78 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/sound/soc/sunxi/sun8i-codec.c
>>> b/sound/soc/sunxi/sun8i-codec.c
>>> index 5723c3404f6b..b4938b06acec 100644
>>> --- a/sound/soc/sunxi/sun8i-codec.c
>>> +++ b/sound/soc/sunxi/sun8i-codec.c
>>> @@ -37,9 +37,11 @@
>>>  #define SUN8I_SYSCLK_CTL_SYSCLK_SRC0
>>>  #define SUN8I_MOD_CLK_ENA  0x010
>>>  #define SUN8I_MOD_CLK_ENA_AIF1 15
>>> +#define SUN8I_MOD_CLK_ENA_ADC  3
>>>  #define SUN8I_MOD_CLK_ENA_DAC  2
>>>  #define SUN8I_MOD_RST_CTL  0x014
>>>  #define SUN8I_MOD_RST_CTL_AIF1 15
>>> +#define SUN8I_MOD_RST_CTL_ADC  3
>>>  #define SUN8I_MOD_RST_CTL_DAC  2
>>>  #define SUN8I_SYS_SR_CTRL  0x018
>>>  #define SUN8I_SYS_SR_CTRL_AIF1_FS  12
>>> @@ -54,9 +56,25 @@
>>>  #define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ   4
>>>  #define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ_16(1 << 4)
>>>  #define SUN8I_AIF1CLK_CTRL_AIF1_DATA_FMT   2
>>> +#define SUN8I_AIF1_ADCDAT_CTRL 0x044
>>> +#define SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0L_ENA   15
>>> +#define SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0R_ENA   14
>>>  #define SUN8I_AIF1_DACDAT_CTRL 0x048
>>>  #define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0L_ENA   15
>>>  #define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA   14
>>> +#define SUN8I_AIF1_MXR_SRC 0x04c
>>> +#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF1DA0L   15
>>> +#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACL   14
>>> +#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_ADCL   13
>>> +#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACR   12
>>> +#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF1DA0R   11
>>> +#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACR   10
>>> +#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_ADCR   9
>>> +#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACL   8
>>> +#define SUN8I_ADC_DIG_CTRL 0x100
>>> +#define SUN8I_ADC_DIG_CTRL_ENDA15
>>
>>
>> The register bit name in the manual is ENAD, as in ENable ADc.
>
>
> Okay, I did not know that, thanks.
>
>
>>
>>> +#define SUN8I_ADC_DIG_CTRL_ADOUT_DTS   2
>>> +#define SUN8I_ADC_DIG_CTRL_ADOUT_DLY   1
>>>  #define SUN8I_DAC_DIG_CTRL 0x120
>>>  #define SUN8I_DAC_DIG_CTRL_ENDA15
>>>  #define SUN8I_DAC_MXR_SRC  0x130
>>> @@ -276,10 +294,28 @@ static const struct snd_kcontrol_new
>>> sun8i_dac_mixer_controls[] = {
>>> SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_ADCR, 1, 0),
>>>  };
>>>
>>> +static const struct snd_kcontrol_new sun8i_input_mixer_controls[] = {
>>> +   SOC_DAPM_DOUBLE("AIF1 Slot 0 Digital ADC Capture Switch",
>>> +   SUN8I_AIF1_MXR_SRC,
>>> +   SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF1DA0L,
>>> +   SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF1DA0R, 1, 0),
>>> +   SOC_DAPM_DOUBLE("AIF2 Digital ADC Capture Switch",
>>> SUN8I_AIF1_MXR_SRC,
>>> +   SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACL,
>>> +   SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACR, 1, 0),
>>> +   SOC_DAPM_DOUBLE("AIF1 Data Digital ADC Capture Switch",
>>> SUN8I_AIF1_MXR_SRC,
>>> +   SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_ADCL,
>>> +   SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_ADCR, 1, 0),
>>> +   SOC_DAPM_DOUBLE("AIF2 Inv Digital ADC Capture Switch",
>>> SUN8I_AIF1_MXR_SRC,
>>> +   SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACR,
>>> +   SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACL, 1, 0),
>>> +};
>>
>>
>> This group of mixer controls is only for AIF1 slot 0 capture.
>> So in fact they should all read "AIF1 Slot 0 Mixer X Capture Switch",
>> with X replaced by "AIF1 Slot 0", "AIF2", "ADC", and "AIF2 Inv".
>>
>> This hopefully informs the user that these controls are for the AIF1
>> slot 0 mixer, and are capture switch from the various sources listed
>> above.
>
>
> Sounds good.
>
>>
>>> +
>>>  static const 

Re: [PATCH 2/2] zram: do not count duplicated pages as compressed

[Minchan Kim]

On Tue, May 16, 2017 at 11:36:15AM +0900, Sergey Senozhatsky wrote:
> > > > @@ -794,7 +801,15 @@ static int __zram_bvec_write(struct zram *zram, 
> > > > struct bio_vec *bvec, u32 index)
> > > > entry = zram_dedup_find(zram, page, );
> > > > if (entry) {
> > > > comp_len = entry->len;
> > > > -   goto found_dup;
> > > > +   zram_slot_lock(zram, index);
> > > > +   zram_free_page(zram, index);
> > > > +   zram_set_flag(zram, index, ZRAM_DUP);
> > > > +   zram_set_entry(zram, index, entry);
> > > > +   zram_set_obj_size(zram, index, comp_len);
> > > > +   zram_slot_unlock(zram, index);
> > > > +   atomic64_add(comp_len, >stats.dup_data_size);
> > > > +   atomic64_inc(>stats.pages_stored);
> > > > +   return 0;
> > > 
> > > hm. that's a somewhat big code duplication. isn't it?
> > 
> > Yub. 3 parts. above part,  zram_same_page_write and tail of 
> > __zram_bvec_write.
> 
> hmm... good question... hardly can think of anything significantly
> better, zram object handling is now a mix of flags, entries,
> ref_counters, etc. etc. may be we can merge some of those ops, if we
> would keep slot locked through the entire __zram_bvec_write(), but
> that does not look attractive.
> 
> something ABSOLUTELY untested and incomplete. not even compile tested (!).
> 99% broken and stupid (!). but there is one thing that it has revealed, so
> thus incomplete. see below:
> 
> ---
> 
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 372602c7da49..b31543c40d54 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -509,11 +509,8 @@ static bool zram_same_page_write(struct zram *zram, u32 
> index,
> if (page_same_filled(mem, )) {
> kunmap_atomic(mem);
> /* Free memory associated with this sector now. */
> -   zram_slot_lock(zram, index);
> -   zram_free_page(zram, index);
> zram_set_flag(zram, index, ZRAM_SAME);
> zram_set_element(zram, index, element);
> -   zram_slot_unlock(zram, index);
>  
> atomic64_inc(>stats.same_pages);
> return true;
> @@ -778,7 +775,7 @@ static int zram_compress(struct zram *zram, struct 
> zcomp_strm **zstrm,
>  
>  static int __zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 
> index)
>  {
> -   int ret;
> +   int ret = 0;
> struct zram_entry *entry;
> unsigned int comp_len;
> void *src, *dst;
> @@ -786,12 +783,20 @@ static int __zram_bvec_write(struct zram *zram, struct 
> bio_vec *bvec, u32 index)
> struct page *page = bvec->bv_page;
> u32 checksum;
>  
> +   /*
> +* Free memory associated with this sector
> +* before overwriting unused sectors.
> +*/
> +   zram_slot_lock(zram, index);
> +   zram_free_page(zram, index);

Hmm, zram_free should happen only if the write is done successfully.
Otherwise, we lose the valid data although write IO was fail.

> +
> if (zram_same_page_write(zram, index, page))
> -   return 0;
> +   goto out_unlock;
>  
> entry = zram_dedup_find(zram, page, );
> if (entry) {
> comp_len = entry->len;
> +   zram_set_flag(zram, index, ZRAM_DUP);

In case of hitting dedup, we shouldn't increase compr_data_size.
If we fix above two problems, do you think it's still cleaner?
(I don't mean to be reluctant with your suggestion. Just a
 real question to know your thought.:)


> goto found_dup;
> }
>  
> @@ -799,7 +804,7 @@ static int __zram_bvec_write(struct zram *zram, struct 
> bio_vec *bvec, u32 index)
> ret = zram_compress(zram, , page, , _len);
> if (ret) {
> zcomp_stream_put(zram->comp);
> -   return ret;
> +   goto out_unlock;
> }
>  
> dst = zs_map_object(zram->mem_pool,
> @@ -817,20 +822,16 @@ static int __zram_bvec_write(struct zram *zram, struct 
> bio_vec *bvec, u32 index)
> zram_dedup_insert(zram, entry, checksum);
>  
>  found_dup:
> -   /*
> -* Free memory associated with this sector
> -* before overwriting unused sectors.
> -*/
> -   zram_slot_lock(zram, index);
> -   zram_free_page(zram, index);
> zram_set_entry(zram, index, entry);
> zram_set_obj_size(zram, index, comp_len);
> -   zram_slot_unlock(zram, index);
>  
> /* Update stats */
> atomic64_add(comp_len, >stats.compr_data_size);
> atomic64_inc(>stats.pages_stored);
> -   return 0;
> +
> +out_unlock:
> +   zram_slot_unlock(zram, index);
> +   return ret;
>  }
> 
> ---
> 
> 
> namely,
> that zram_compress() error return path from __zram_bvec_write().
> 
> currently, we touch the existing compressed 

Re: [PATCH 2/2] zram: do not count duplicated pages as compressed

[Minchan Kim]

On Tue, May 16, 2017 at 11:36:15AM +0900, Sergey Senozhatsky wrote:
> > > > @@ -794,7 +801,15 @@ static int __zram_bvec_write(struct zram *zram, 
> > > > struct bio_vec *bvec, u32 index)
> > > > entry = zram_dedup_find(zram, page, );
> > > > if (entry) {
> > > > comp_len = entry->len;
> > > > -   goto found_dup;
> > > > +   zram_slot_lock(zram, index);
> > > > +   zram_free_page(zram, index);
> > > > +   zram_set_flag(zram, index, ZRAM_DUP);
> > > > +   zram_set_entry(zram, index, entry);
> > > > +   zram_set_obj_size(zram, index, comp_len);
> > > > +   zram_slot_unlock(zram, index);
> > > > +   atomic64_add(comp_len, >stats.dup_data_size);
> > > > +   atomic64_inc(>stats.pages_stored);
> > > > +   return 0;
> > > 
> > > hm. that's a somewhat big code duplication. isn't it?
> > 
> > Yub. 3 parts. above part,  zram_same_page_write and tail of 
> > __zram_bvec_write.
> 
> hmm... good question... hardly can think of anything significantly
> better, zram object handling is now a mix of flags, entries,
> ref_counters, etc. etc. may be we can merge some of those ops, if we
> would keep slot locked through the entire __zram_bvec_write(), but
> that does not look attractive.
> 
> something ABSOLUTELY untested and incomplete. not even compile tested (!).
> 99% broken and stupid (!). but there is one thing that it has revealed, so
> thus incomplete. see below:
> 
> ---
> 
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 372602c7da49..b31543c40d54 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -509,11 +509,8 @@ static bool zram_same_page_write(struct zram *zram, u32 
> index,
> if (page_same_filled(mem, )) {
> kunmap_atomic(mem);
> /* Free memory associated with this sector now. */
> -   zram_slot_lock(zram, index);
> -   zram_free_page(zram, index);
> zram_set_flag(zram, index, ZRAM_SAME);
> zram_set_element(zram, index, element);
> -   zram_slot_unlock(zram, index);
>  
> atomic64_inc(>stats.same_pages);
> return true;
> @@ -778,7 +775,7 @@ static int zram_compress(struct zram *zram, struct 
> zcomp_strm **zstrm,
>  
>  static int __zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 
> index)
>  {
> -   int ret;
> +   int ret = 0;
> struct zram_entry *entry;
> unsigned int comp_len;
> void *src, *dst;
> @@ -786,12 +783,20 @@ static int __zram_bvec_write(struct zram *zram, struct 
> bio_vec *bvec, u32 index)
> struct page *page = bvec->bv_page;
> u32 checksum;
>  
> +   /*
> +* Free memory associated with this sector
> +* before overwriting unused sectors.
> +*/
> +   zram_slot_lock(zram, index);
> +   zram_free_page(zram, index);

Hmm, zram_free should happen only if the write is done successfully.
Otherwise, we lose the valid data although write IO was fail.

> +
> if (zram_same_page_write(zram, index, page))
> -   return 0;
> +   goto out_unlock;
>  
> entry = zram_dedup_find(zram, page, );
> if (entry) {
> comp_len = entry->len;
> +   zram_set_flag(zram, index, ZRAM_DUP);

In case of hitting dedup, we shouldn't increase compr_data_size.
If we fix above two problems, do you think it's still cleaner?
(I don't mean to be reluctant with your suggestion. Just a
 real question to know your thought.:)


> goto found_dup;
> }
>  
> @@ -799,7 +804,7 @@ static int __zram_bvec_write(struct zram *zram, struct 
> bio_vec *bvec, u32 index)
> ret = zram_compress(zram, , page, , _len);
> if (ret) {
> zcomp_stream_put(zram->comp);
> -   return ret;
> +   goto out_unlock;
> }
>  
> dst = zs_map_object(zram->mem_pool,
> @@ -817,20 +822,16 @@ static int __zram_bvec_write(struct zram *zram, struct 
> bio_vec *bvec, u32 index)
> zram_dedup_insert(zram, entry, checksum);
>  
>  found_dup:
> -   /*
> -* Free memory associated with this sector
> -* before overwriting unused sectors.
> -*/
> -   zram_slot_lock(zram, index);
> -   zram_free_page(zram, index);
> zram_set_entry(zram, index, entry);
> zram_set_obj_size(zram, index, comp_len);
> -   zram_slot_unlock(zram, index);
>  
> /* Update stats */
> atomic64_add(comp_len, >stats.compr_data_size);
> atomic64_inc(>stats.pages_stored);
> -   return 0;
> +
> +out_unlock:
> +   zram_slot_unlock(zram, index);
> +   return ret;
>  }
> 
> ---
> 
> 
> namely,
> that zram_compress() error return path from __zram_bvec_write().
> 
> currently, we touch the existing compressed 

[PATCH] iommu: of: Fix check for returning EPROBE_DEFER

[Sricharan R]

While returning EPROBE_DEFER for iommu masters
take in to account of iommu nodes that could be
marked in DT as 'status=disabled', in which case
simply return NULL and let the master's probe
continue rather than deferring.

Signed-off-by: Sricharan R 
Tested-by: Will Deacon 
Acked-by: Will Deacon 
---
 drivers/iommu/of_iommu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 9f44ee8..e6e9bec 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -118,6 +118,7 @@ static bool of_iommu_driver_present(struct device_node *np)
 
ops = iommu_ops_from_fwnode(fwnode);
if ((ops && !ops->of_xlate) ||
+   !of_device_is_available(iommu_spec->np) ||
(!ops && !of_iommu_driver_present(iommu_spec->np)))
return NULL;
 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH] iommu: of: Fix check for returning EPROBE_DEFER

[Sricharan R]

While returning EPROBE_DEFER for iommu masters
take in to account of iommu nodes that could be
marked in DT as 'status=disabled', in which case
simply return NULL and let the master's probe
continue rather than deferring.

Signed-off-by: Sricharan R 
Tested-by: Will Deacon 
Acked-by: Will Deacon 
---
 drivers/iommu/of_iommu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 9f44ee8..e6e9bec 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -118,6 +118,7 @@ static bool of_iommu_driver_present(struct device_node *np)
 
ops = iommu_ops_from_fwnode(fwnode);
if ((ops && !ops->of_xlate) ||
+   !of_device_is_available(iommu_spec->np) ||
(!ops && !of_iommu_driver_present(iommu_spec->np)))
return NULL;
 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters

[Oza Oza]

On Sat, May 6, 2017 at 11:00 AM, Oza Oza  wrote:
> On Fri, May 5, 2017 at 8:55 PM, Robin Murphy  wrote:
>> On 04/05/17 19:41, Oza Oza wrote:
>> [...]
> 5) leaves scope of adding PCI flag handling for inbound memory
> by the new function.

 Which flags would ever actually matter? DMA windows aren't going to be
 to config or I/O space, so the memory type can be assumed, and the
 32/64-bit distinction is irrelevant as it's not a relocatable BAR;
 DMA-able system memory isn't going to be read-sensitive, so the
 prefetchable flag shouldn't matter; and not being a BAR none of the
 others would be relevant either.

>>>
>>> Thanks Robin; for your reply and attention:
>>>
>>> agree with you, at present it would not matter,
>>> but it does not mean that we do not scope it to make it matter in future.
>>>
>>> now where it could matter:
>>> there is Relaxed Ordering for inbound memory for PCI.
>>> According to standard, Relaxed Ordering (RO) bit can be set only for
>>> Memory requests and completions (if present in the original request).
>>> Also, according to transaction ordering rules, I/O and configuration
>>> requests can still be re-ordered ahead of each other.
>>> and we would like to make use of it.
>>> for e.g. lets say we mark memory as Relaxed Ordered with flag.
>>> the special about this memory is incoming PCI transactions can be
>>> reordered and rest memory has to be strongly ordered.
>>
>> Please look at "PCI Bus Binding to: IEEE Std 1275-1994 Standard for Boot
>> (Initialization Configuration) Firmware" (as referenced in DTSpec) and
>> explain how PCIe Relaxed Order has anything to do with the DT binding.
>>
>>> how it our SOC would make use of this is out of scope for the
>>> discussion at this point of time, but I am just bringing in the
>>> idea/point how flags could be useful
>>> for inbound memory, since we would not like throw-away flags completely.
>>
>> The premise for implementing a PCI-specific parser is that you claim we
>> need to do something with the phys.hi cell of a DT PCI address, rather
>> than just taking the numerical part out of the phys.mid and phys.lo
>> cells. Please make that argument in reference to the flags which that
>> upper cell actually encodes, not unrelated things.
>>
>
> I think, the whole discussion around inbound flags is not what I
> intended to bring.
> this patch does nothing about inbound flag and never intends to solve
> anything regarding inbound flags.
> infact I would like to remove point 5 form the commit message. which
> should keep it out of discussion completely.
>
> let met tell what this patch is trying to address/solve 2 BUGs
> 1) fix wrong size return from of_dma_configure for PCI masters. (which
> is right now BUG)
>
> 2) handles multiple dma-ranges cleanly
>
> 3) It takes care of dma-ranges being optional.
>
> 4) following is the comment on function of_dma_get_range (which is also a BUG)
> "It returns -ENODEV if "dma-ranges" property was not found
>  * for this device in DT."
> which I think is wrong for PCI device, because if dma-ranges are
> absent then instead of returning  -ENODEV,
> it should return 0 with largest possible host memory.
>
> it solves all the above 4 problems.
>
>> [...]
> +int of_pci_get_dma_ranges(struct device_node *np, struct list_head 
> *resources)
> +{
> + struct device_node *node = of_node_get(np);
> + int rlen;
> + int ret = 0;
> + const int na = 3, ns = 2;
> + struct resource *res;
> + struct of_pci_range_parser parser;
> + struct of_pci_range range;
> +
> + if (!node)
> + return -EINVAL;
> +
> + parser.node = node;
> + parser.pna = of_n_addr_cells(node);
> + parser.np = parser.pna + na + ns;
> +
> + parser.range = of_get_property(node, "dma-ranges", );
> +
> + if (!parser.range) {
> + pr_debug("pcie device has no dma-ranges defined for 
> node(%s)\n",
> +   np->full_name);
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + parser.end = parser.range + rlen / sizeof(__be32);
> +
> + for_each_of_pci_range(, ) {

 This is plain wrong - of_pci_range_parser_one() will translate upwards
 through parent "ranges" properties, which is completely backwards for
 DMA addresses.

 Robin.

>>>
>>> No it does not, this patch is thoroughly tested on our SOC and it works.
>>> of_pci_range_parser_one does not translate upwards through parent. it
>>> just sticks to given PCI parser.
>>
>> Frankly, I'm losing patience with this attitude. Please look at the code
>> you call:
>>
>> #define for_each_of_pci_range(parser, range) \
>> for (; of_pci_range_parser_one(parser, range);)
>>
>>
>> struct of_pci_range *of_pci_range_parser_one(struct 

Re: [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters

[Oza Oza]

On Sat, May 6, 2017 at 11:00 AM, Oza Oza  wrote:
> On Fri, May 5, 2017 at 8:55 PM, Robin Murphy  wrote:
>> On 04/05/17 19:41, Oza Oza wrote:
>> [...]
> 5) leaves scope of adding PCI flag handling for inbound memory
> by the new function.

 Which flags would ever actually matter? DMA windows aren't going to be
 to config or I/O space, so the memory type can be assumed, and the
 32/64-bit distinction is irrelevant as it's not a relocatable BAR;
 DMA-able system memory isn't going to be read-sensitive, so the
 prefetchable flag shouldn't matter; and not being a BAR none of the
 others would be relevant either.

>>>
>>> Thanks Robin; for your reply and attention:
>>>
>>> agree with you, at present it would not matter,
>>> but it does not mean that we do not scope it to make it matter in future.
>>>
>>> now where it could matter:
>>> there is Relaxed Ordering for inbound memory for PCI.
>>> According to standard, Relaxed Ordering (RO) bit can be set only for
>>> Memory requests and completions (if present in the original request).
>>> Also, according to transaction ordering rules, I/O and configuration
>>> requests can still be re-ordered ahead of each other.
>>> and we would like to make use of it.
>>> for e.g. lets say we mark memory as Relaxed Ordered with flag.
>>> the special about this memory is incoming PCI transactions can be
>>> reordered and rest memory has to be strongly ordered.
>>
>> Please look at "PCI Bus Binding to: IEEE Std 1275-1994 Standard for Boot
>> (Initialization Configuration) Firmware" (as referenced in DTSpec) and
>> explain how PCIe Relaxed Order has anything to do with the DT binding.
>>
>>> how it our SOC would make use of this is out of scope for the
>>> discussion at this point of time, but I am just bringing in the
>>> idea/point how flags could be useful
>>> for inbound memory, since we would not like throw-away flags completely.
>>
>> The premise for implementing a PCI-specific parser is that you claim we
>> need to do something with the phys.hi cell of a DT PCI address, rather
>> than just taking the numerical part out of the phys.mid and phys.lo
>> cells. Please make that argument in reference to the flags which that
>> upper cell actually encodes, not unrelated things.
>>
>
> I think, the whole discussion around inbound flags is not what I
> intended to bring.
> this patch does nothing about inbound flag and never intends to solve
> anything regarding inbound flags.
> infact I would like to remove point 5 form the commit message. which
> should keep it out of discussion completely.
>
> let met tell what this patch is trying to address/solve 2 BUGs
> 1) fix wrong size return from of_dma_configure for PCI masters. (which
> is right now BUG)
>
> 2) handles multiple dma-ranges cleanly
>
> 3) It takes care of dma-ranges being optional.
>
> 4) following is the comment on function of_dma_get_range (which is also a BUG)
> "It returns -ENODEV if "dma-ranges" property was not found
>  * for this device in DT."
> which I think is wrong for PCI device, because if dma-ranges are
> absent then instead of returning  -ENODEV,
> it should return 0 with largest possible host memory.
>
> it solves all the above 4 problems.
>
>> [...]
> +int of_pci_get_dma_ranges(struct device_node *np, struct list_head 
> *resources)
> +{
> + struct device_node *node = of_node_get(np);
> + int rlen;
> + int ret = 0;
> + const int na = 3, ns = 2;
> + struct resource *res;
> + struct of_pci_range_parser parser;
> + struct of_pci_range range;
> +
> + if (!node)
> + return -EINVAL;
> +
> + parser.node = node;
> + parser.pna = of_n_addr_cells(node);
> + parser.np = parser.pna + na + ns;
> +
> + parser.range = of_get_property(node, "dma-ranges", );
> +
> + if (!parser.range) {
> + pr_debug("pcie device has no dma-ranges defined for 
> node(%s)\n",
> +   np->full_name);
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + parser.end = parser.range + rlen / sizeof(__be32);
> +
> + for_each_of_pci_range(, ) {

 This is plain wrong - of_pci_range_parser_one() will translate upwards
 through parent "ranges" properties, which is completely backwards for
 DMA addresses.

 Robin.

>>>
>>> No it does not, this patch is thoroughly tested on our SOC and it works.
>>> of_pci_range_parser_one does not translate upwards through parent. it
>>> just sticks to given PCI parser.
>>
>> Frankly, I'm losing patience with this attitude. Please look at the code
>> you call:
>>
>> #define for_each_of_pci_range(parser, range) \
>> for (; of_pci_range_parser_one(parser, range);)
>>
>>
>> struct of_pci_range *of_pci_range_parser_one(struct of_pci_range_parser
>> *parser,
>> 

[PATCH v6 2/3] iommu/pci: reserve IOVA for PCI masters

[Oza Pawandeep]

this patch reserves the IOVA for PCI masters.
ARM64 based SOCs may have scattered memory banks.
such as iproc based SOC has

<0x 0x8000 0x0 0x8000>, /* 2G @ 2G */
<0x0008 0x8000 0x3 0x8000>, /* 14G @ 34G */
<0x0090 0x 0x4 0x>, /* 16G @ 576G */
<0x00a0 0x 0x4 0x>; /* 16G @ 640G */

but incoming PCI transcation addressing capability is limited
by host bridge, for example if max incoming window capability
is 512 GB, then 0x0090 and 0x00a0 will fall beyond it.

to address this problem, iommu has to avoid allocating IOVA which
are reserved. which inturn does not allocate IOVA if it falls into hole.

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 48d36ce..08764b0 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -171,8 +172,12 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
struct iova_domain *iovad)
 {
struct pci_host_bridge *bridge = pci_find_host_bridge(dev->bus);
+   struct device_node *np = bridge->dev.parent->of_node;
struct resource_entry *window;
unsigned long lo, hi;
+   int ret;
+   dma_addr_t tmp_dma_addr = 0, dma_addr;
+   LIST_HEAD(res);
 
resource_list_for_each_entry(window, >windows) {
if (resource_type(window->res) != IORESOURCE_MEM &&
@@ -183,6 +188,36 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
hi = iova_pfn(iovad, window->res->end - window->offset);
reserve_iova(iovad, lo, hi);
}
+
+   /* PCI inbound memory reservation. */
+   ret = of_pci_get_dma_ranges(np, );
+   if (!ret) {
+   resource_list_for_each_entry(window, ) {
+   struct resource *res_dma = window->res;
+
+   dma_addr = res_dma->start - window->offset;
+   if (tmp_dma_addr > dma_addr) {
+   pr_warn("PCI: failed to reserve iovas; ranges 
should be sorted\n");
+   return;
+   }
+   if (tmp_dma_addr != dma_addr) {
+   lo = iova_pfn(iovad, tmp_dma_addr);
+   hi = iova_pfn(iovad, dma_addr - 1);
+   reserve_iova(iovad, lo, hi);
+   }
+   tmp_dma_addr = window->res->end - window->offset;
+   }
+   /*
+* the last dma-range should honour based on the
+* 32/64-bit dma addresses.
+*/
+   if (tmp_dma_addr < DMA_BIT_MASK(sizeof(dma_addr_t) * 8)) {
+   lo = iova_pfn(iovad, tmp_dma_addr);
+   hi = iova_pfn(iovad,
+ DMA_BIT_MASK(sizeof(dma_addr_t) * 8) - 1);
+   reserve_iova(iovad, lo, hi);
+   }
+   }
 }
 
 /**
-- 
1.9.1

[PATCH] PM / Domains: pdd->dev can't be NULL in genpd_dev_pm_qos_notifier()

[Viresh Kumar]

The pm_domain_data (pdd) pointer is set from genpd_alloc_dev_data() and
pdd->dev is guaranteed to be valid. There is no need to check pdd and
pdd->dev in rest of the code as pdd->dev will always be valid for a non
NULL pdd pointer.

Signed-off-by: Viresh Kumar 
---
 drivers/base/power/domain.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index da49a8383dc3..71c95ad808d5 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -443,7 +443,7 @@ static int genpd_dev_pm_qos_notifier(struct notifier_block 
*nb,
 
pdd = dev->power.subsys_data ?
dev->power.subsys_data->domain_data : NULL;
-   if (pdd && pdd->dev) {
+   if (pdd) {
to_gpd_data(pdd)->td.constraint_changed = true;
genpd = dev_to_genpd(dev);
} else {
-- 
2.13.0.303.g4ebf3021692d

[PATCH v6 2/3] iommu/pci: reserve IOVA for PCI masters

[Oza Pawandeep]

this patch reserves the IOVA for PCI masters.
ARM64 based SOCs may have scattered memory banks.
such as iproc based SOC has

<0x 0x8000 0x0 0x8000>, /* 2G @ 2G */
<0x0008 0x8000 0x3 0x8000>, /* 14G @ 34G */
<0x0090 0x 0x4 0x>, /* 16G @ 576G */
<0x00a0 0x 0x4 0x>; /* 16G @ 640G */

but incoming PCI transcation addressing capability is limited
by host bridge, for example if max incoming window capability
is 512 GB, then 0x0090 and 0x00a0 will fall beyond it.

to address this problem, iommu has to avoid allocating IOVA which
are reserved. which inturn does not allocate IOVA if it falls into hole.

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 48d36ce..08764b0 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -171,8 +172,12 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
struct iova_domain *iovad)
 {
struct pci_host_bridge *bridge = pci_find_host_bridge(dev->bus);
+   struct device_node *np = bridge->dev.parent->of_node;
struct resource_entry *window;
unsigned long lo, hi;
+   int ret;
+   dma_addr_t tmp_dma_addr = 0, dma_addr;
+   LIST_HEAD(res);
 
resource_list_for_each_entry(window, >windows) {
if (resource_type(window->res) != IORESOURCE_MEM &&
@@ -183,6 +188,36 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
hi = iova_pfn(iovad, window->res->end - window->offset);
reserve_iova(iovad, lo, hi);
}
+
+   /* PCI inbound memory reservation. */
+   ret = of_pci_get_dma_ranges(np, );
+   if (!ret) {
+   resource_list_for_each_entry(window, ) {
+   struct resource *res_dma = window->res;
+
+   dma_addr = res_dma->start - window->offset;
+   if (tmp_dma_addr > dma_addr) {
+   pr_warn("PCI: failed to reserve iovas; ranges 
should be sorted\n");
+   return;
+   }
+   if (tmp_dma_addr != dma_addr) {
+   lo = iova_pfn(iovad, tmp_dma_addr);
+   hi = iova_pfn(iovad, dma_addr - 1);
+   reserve_iova(iovad, lo, hi);
+   }
+   tmp_dma_addr = window->res->end - window->offset;
+   }
+   /*
+* the last dma-range should honour based on the
+* 32/64-bit dma addresses.
+*/
+   if (tmp_dma_addr < DMA_BIT_MASK(sizeof(dma_addr_t) * 8)) {
+   lo = iova_pfn(iovad, tmp_dma_addr);
+   hi = iova_pfn(iovad,
+ DMA_BIT_MASK(sizeof(dma_addr_t) * 8) - 1);
+   reserve_iova(iovad, lo, hi);
+   }
+   }
 }
 
 /**
-- 
1.9.1

[PATCH] PM / Domains: pdd->dev can't be NULL in genpd_dev_pm_qos_notifier()

[Viresh Kumar]

The pm_domain_data (pdd) pointer is set from genpd_alloc_dev_data() and
pdd->dev is guaranteed to be valid. There is no need to check pdd and
pdd->dev in rest of the code as pdd->dev will always be valid for a non
NULL pdd pointer.

Signed-off-by: Viresh Kumar 
---
 drivers/base/power/domain.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index da49a8383dc3..71c95ad808d5 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -443,7 +443,7 @@ static int genpd_dev_pm_qos_notifier(struct notifier_block 
*nb,
 
pdd = dev->power.subsys_data ?
dev->power.subsys_data->domain_data : NULL;
-   if (pdd && pdd->dev) {
+   if (pdd) {
to_gpd_data(pdd)->td.constraint_changed = true;
genpd = dev_to_genpd(dev);
} else {
-- 
2.13.0.303.g4ebf3021692d

[PATCH v6 0/3] OF/PCI address PCI inbound memory limitations

[Oza Pawandeep]

It is possible that PCI device supports 64-bit DMA addressing,
and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64),
however PCI host bridge may have limitations on the inbound 
transaction addressing.

This is particularly problematic on ARM/ARM64 SOCs where the 
IOMMU (i.e. SMMU) translates IOVA to PA for in-bound transactions
only after PCI Host has forwarded these transactions on SOC IO bus. 

This means, on such ARM/ARM64 SOCs the IOVA of in-bound transactions
has to honor the addressing restrictions of the PCI Host.

Current device framework and OF framework integration assumes
dma-ranges in a way where memory-mapped devices define their
dma-ranges. (child-bus-address, parent-bus-address, length).

of_dma_configure is specifically written to take care of memory
mapped devices but no implementation exists for pci devices.

For e.g. iproc based SOCs and other SOCs (such as rcar) have
PCI world dma-ranges.
dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;

This patchset
reserves the IOVA ranges for PCI masters based
on the PCI world dma-ranges.
fix of_dma_get_range to cater to PCI dma-ranges.
fix of_dma_get_range which currently returns size 0 for PCI devices.

IOVA allocation patch:
[PATCH 2/3] iommu/pci: reserve iova for PCI masters

Fix of_dma_get_range bug and address PCI master.
[PATCH 3/3] PCI/of fix of_dma_get_range; get PCI specific
this patch fixes the following problems of_dma_get_range.
1) return of wrong size as 0.
2) not handling absence of dma-ranges, which is valid for PCI master.
3) not handling multipe inbound windows.
4) in order to get largest possible dma_mask. this patch also
retuns the largest possible size based on dma-ranges,

Base patch for both of the above patches:
[PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters

Changes since v6:
- Robin's comments addressed.
Changes since v5:
Changes since v4:
Changes since v3:
Changes since v2:
- minor changes, redudant checkes removed
- removed internal review
Changes since v1:
- address Rob's comments.
- Add a get_dma_ranges() function to of_bus struct..
- Convert existing contents of of_dma_get_range function to
  of_bus_default_dma_get_ranges and adding that to the
  default of_bus struct.
- Make of_dma_get_range call of_bus_match() and then bus->get_dma_ranges.

Oza Pawandeep (3):
  of/pci/dma: fix DMA configuration for PCI masters
  iommu/pci: reserve IOVA for PCI masters
  PCI/of fix of_dma_get_range; get PCI specific dma-ranges

 drivers/iommu/dma-iommu.c |  35 
 drivers/of/address.c  | 215 --
 drivers/of/of_pci.c   |  95 
 include/linux/of_pci.h|   7 ++
 4 files changed, 288 insertions(+), 64 deletions(-)

-- 
1.9.1

[PATCH v6 0/3] OF/PCI address PCI inbound memory limitations

[Oza Pawandeep]

It is possible that PCI device supports 64-bit DMA addressing,
and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64),
however PCI host bridge may have limitations on the inbound 
transaction addressing.

This is particularly problematic on ARM/ARM64 SOCs where the 
IOMMU (i.e. SMMU) translates IOVA to PA for in-bound transactions
only after PCI Host has forwarded these transactions on SOC IO bus. 

This means, on such ARM/ARM64 SOCs the IOVA of in-bound transactions
has to honor the addressing restrictions of the PCI Host.

Current device framework and OF framework integration assumes
dma-ranges in a way where memory-mapped devices define their
dma-ranges. (child-bus-address, parent-bus-address, length).

of_dma_configure is specifically written to take care of memory
mapped devices but no implementation exists for pci devices.

For e.g. iproc based SOCs and other SOCs (such as rcar) have
PCI world dma-ranges.
dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;

This patchset
reserves the IOVA ranges for PCI masters based
on the PCI world dma-ranges.
fix of_dma_get_range to cater to PCI dma-ranges.
fix of_dma_get_range which currently returns size 0 for PCI devices.

IOVA allocation patch:
[PATCH 2/3] iommu/pci: reserve iova for PCI masters

Fix of_dma_get_range bug and address PCI master.
[PATCH 3/3] PCI/of fix of_dma_get_range; get PCI specific
this patch fixes the following problems of_dma_get_range.
1) return of wrong size as 0.
2) not handling absence of dma-ranges, which is valid for PCI master.
3) not handling multipe inbound windows.
4) in order to get largest possible dma_mask. this patch also
retuns the largest possible size based on dma-ranges,

Base patch for both of the above patches:
[PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters

Changes since v6:
- Robin's comments addressed.
Changes since v5:
Changes since v4:
Changes since v3:
Changes since v2:
- minor changes, redudant checkes removed
- removed internal review
Changes since v1:
- address Rob's comments.
- Add a get_dma_ranges() function to of_bus struct..
- Convert existing contents of of_dma_get_range function to
  of_bus_default_dma_get_ranges and adding that to the
  default of_bus struct.
- Make of_dma_get_range call of_bus_match() and then bus->get_dma_ranges.

Oza Pawandeep (3):
  of/pci/dma: fix DMA configuration for PCI masters
  iommu/pci: reserve IOVA for PCI masters
  PCI/of fix of_dma_get_range; get PCI specific dma-ranges

 drivers/iommu/dma-iommu.c |  35 
 drivers/of/address.c  | 215 --
 drivers/of/of_pci.c   |  95 
 include/linux/of_pci.h|   7 ++
 4 files changed, 288 insertions(+), 64 deletions(-)

-- 
1.9.1

[PATCH v6 1/3] of/pci/dma: fix DMA configuration for PCI masters

[Oza Pawandeep]

current device framework and OF framework integration assumes
dma-ranges in a way where memory-mapped devices define their
dma-ranges. (child-bus-address, parent-bus-address, length).

of_dma_configure is specifically written to take care of memory
mapped devices. but no implementation exists for pci to take
care of pcie based memory ranges.

for e.g. iproc based SOCs and other SOCs(suc as rcar) have PCI
world dma-ranges.
dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;

this patch serves following:

1) exposes interface to the pci host driver for their
inbound memory ranges

2) provide an interface to callers such as of_dma_get_ranges.
so then the returned size get best possible (largest) dma_mask.
because PCI RC drivers do not call APIs such as
dma_set_coherent_mask() and hence rather it shows its addressing
capabilities based on dma-ranges.
for e.g.
dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
we should get dev->coherent_dma_mask=0x7f.

3) this patch handles multiple inbound windows and dma-ranges.
it is left to the caller, how it wants to use them.
the new function returns the resources in a standard and unform way

4) this way the callers of for e.g. of_dma_get_ranges
does not need to change.

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 0ee42c3..4005ed3 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -283,6 +283,101 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
return err;
 }
 EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
+
+/**
+ * of_pci_get_dma_ranges - Parse PCI host bridge inbound resources from DT
+ * @np: device node of the host bridge having the dma-ranges property
+ * @resources: list where the range of resources will be added after DT parsing
+ *
+ * It is the caller's job to free the @resources list.
+ *
+ * This function will parse the "dma-ranges" property of a
+ * PCI host bridge device node and setup the resource mapping based
+ * on its content.
+ *
+ * It returns zero if the range parsing has been successful or a standard error
+ * value if it failed.
+ */
+
+int of_pci_get_dma_ranges(struct device_node *dn, struct list_head *resources)
+{
+   struct device_node *node = of_node_get(dn);
+   int rlen;
+   int pna = of_n_addr_cells(node);
+   const int na = 3, ns = 2;
+   int np = pna + na + ns;
+   int ret = 0;
+   struct resource *res;
+   const u32 *dma_ranges;
+   struct of_pci_range range;
+
+   if (!node)
+   return -EINVAL;
+
+   while (1) {
+   dma_ranges = of_get_property(node, "dma-ranges", );
+
+   /* Ignore empty ranges, they imply no translation required. */
+   if (dma_ranges && rlen > 0)
+   break;
+
+   /* no dma-ranges, they imply no translation required. */
+   if (!dma_ranges)
+   break;
+
+   node = of_get_next_parent(node);
+
+   if (!node)
+   break;
+   }
+
+   if (!dma_ranges) {
+   pr_debug("pcie device has no dma-ranges defined for node(%s)\n",
+ dn->full_name);
+   ret = -EINVAL;
+   goto out;
+   }
+
+   while ((rlen -= np * 4) >= 0) {
+   range.pci_space = dma_ranges[0];
+   range.pci_addr = of_read_number(dma_ranges + 1, ns);
+   range.cpu_addr = of_translate_dma_address(node,
+   dma_ranges + na);
+   range.size = of_read_number(dma_ranges + pna + na, ns);
+
+   dma_ranges += np;
+
+   /*
+* If we failed translation or got a zero-sized region
+* then skip this range.
+*/
+   if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
+   continue;
+
+   res = kzalloc(sizeof(struct resource), GFP_KERNEL);
+   if (!res) {
+   ret = -ENOMEM;
+   goto parse_failed;
+   }
+
+   ret = of_pci_range_to_resource(, dn, res);
+   if (ret) {
+   kfree(res);
+   continue;
+   }
+
+   pci_add_resource_offset(resources, res,
+   res->start - range.pci_addr);
+   }
+   return ret;
+
+parse_failed:
+   pci_free_resource_list(resources);
+out:
+   of_node_put(node);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(of_pci_get_dma_ranges);
 #endif /* CONFIG_OF_ADDRESS */
 
 #ifdef CONFIG_PCI_MSI
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 0e0974e..617b90d 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -76,6 +76,7 @@ static inline void of_pci_check_probe_only(void) { }
 int of_pci_get_host_bridge_resources(struct 

[PATCH v6 1/3] of/pci/dma: fix DMA configuration for PCI masters

[Oza Pawandeep]

current device framework and OF framework integration assumes
dma-ranges in a way where memory-mapped devices define their
dma-ranges. (child-bus-address, parent-bus-address, length).

of_dma_configure is specifically written to take care of memory
mapped devices. but no implementation exists for pci to take
care of pcie based memory ranges.

for e.g. iproc based SOCs and other SOCs(suc as rcar) have PCI
world dma-ranges.
dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;

this patch serves following:

1) exposes interface to the pci host driver for their
inbound memory ranges

2) provide an interface to callers such as of_dma_get_ranges.
so then the returned size get best possible (largest) dma_mask.
because PCI RC drivers do not call APIs such as
dma_set_coherent_mask() and hence rather it shows its addressing
capabilities based on dma-ranges.
for e.g.
dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
we should get dev->coherent_dma_mask=0x7f.

3) this patch handles multiple inbound windows and dma-ranges.
it is left to the caller, how it wants to use them.
the new function returns the resources in a standard and unform way

4) this way the callers of for e.g. of_dma_get_ranges
does not need to change.

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 0ee42c3..4005ed3 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -283,6 +283,101 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
return err;
 }
 EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
+
+/**
+ * of_pci_get_dma_ranges - Parse PCI host bridge inbound resources from DT
+ * @np: device node of the host bridge having the dma-ranges property
+ * @resources: list where the range of resources will be added after DT parsing
+ *
+ * It is the caller's job to free the @resources list.
+ *
+ * This function will parse the "dma-ranges" property of a
+ * PCI host bridge device node and setup the resource mapping based
+ * on its content.
+ *
+ * It returns zero if the range parsing has been successful or a standard error
+ * value if it failed.
+ */
+
+int of_pci_get_dma_ranges(struct device_node *dn, struct list_head *resources)
+{
+   struct device_node *node = of_node_get(dn);
+   int rlen;
+   int pna = of_n_addr_cells(node);
+   const int na = 3, ns = 2;
+   int np = pna + na + ns;
+   int ret = 0;
+   struct resource *res;
+   const u32 *dma_ranges;
+   struct of_pci_range range;
+
+   if (!node)
+   return -EINVAL;
+
+   while (1) {
+   dma_ranges = of_get_property(node, "dma-ranges", );
+
+   /* Ignore empty ranges, they imply no translation required. */
+   if (dma_ranges && rlen > 0)
+   break;
+
+   /* no dma-ranges, they imply no translation required. */
+   if (!dma_ranges)
+   break;
+
+   node = of_get_next_parent(node);
+
+   if (!node)
+   break;
+   }
+
+   if (!dma_ranges) {
+   pr_debug("pcie device has no dma-ranges defined for node(%s)\n",
+ dn->full_name);
+   ret = -EINVAL;
+   goto out;
+   }
+
+   while ((rlen -= np * 4) >= 0) {
+   range.pci_space = dma_ranges[0];
+   range.pci_addr = of_read_number(dma_ranges + 1, ns);
+   range.cpu_addr = of_translate_dma_address(node,
+   dma_ranges + na);
+   range.size = of_read_number(dma_ranges + pna + na, ns);
+
+   dma_ranges += np;
+
+   /*
+* If we failed translation or got a zero-sized region
+* then skip this range.
+*/
+   if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
+   continue;
+
+   res = kzalloc(sizeof(struct resource), GFP_KERNEL);
+   if (!res) {
+   ret = -ENOMEM;
+   goto parse_failed;
+   }
+
+   ret = of_pci_range_to_resource(, dn, res);
+   if (ret) {
+   kfree(res);
+   continue;
+   }
+
+   pci_add_resource_offset(resources, res,
+   res->start - range.pci_addr);
+   }
+   return ret;
+
+parse_failed:
+   pci_free_resource_list(resources);
+out:
+   of_node_put(node);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(of_pci_get_dma_ranges);
 #endif /* CONFIG_OF_ADDRESS */
 
 #ifdef CONFIG_PCI_MSI
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 0e0974e..617b90d 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -76,6 +76,7 @@ static inline void of_pci_check_probe_only(void) { }
 int of_pci_get_host_bridge_resources(struct device_node *dev,
  

[PATCH v6 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges

[Oza Pawandeep]

current device framework and OF framework integration assumes
dma-ranges in a way where memory-mapped devices define their
dma-ranges. (child-bus-address, parent-bus-address, length).

of_dma_configure is specifically written to take care of memory
mapped devices. but no implementation exists for pci to take
care of pcie based memory ranges.

for e.g. iproc based SOCs and other SOCs(suc as rcar) have PCI
world dma-ranges.
dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;

this patch fixes the following problems of_dma_get_range.
1) return of wrong size as 0.
2) not handling absence of dma-ranges which is valid for PCI master.
3) not handling multipe inbound windows.
4) in order to get largest possible dma_mask. this patch also
retuns the largest possible size based on dma-ranges,

for e.g.
dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
we should get dev->coherent_dma_mask=0x7f.

based on which IOVA allocation space will honour PCI host
bridge limitations.

the implementation hooks bus specific callbacks for getting
dma-ranges.

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 02b2903..800731c 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -46,6 +47,8 @@ struct of_bus {
int na, int ns, int pna);
int (*translate)(__be32 *addr, u64 offset, int na);
unsigned int(*get_flags)(const __be32 *addr);
+   int (*get_dma_ranges)(struct device_node *np,
+ u64 *dma_addr, u64 *paddr, u64 *size);
 };
 
 /*
@@ -171,6 +174,144 @@ static int of_bus_pci_translate(__be32 *addr, u64 offset, 
int na)
 {
return of_bus_default_translate(addr + 1, offset, na - 1);
 }
+
+static int of_bus_pci_get_dma_ranges(struct device_node *np, u64 *dma_addr,
+u64 *paddr, u64 *size)
+{
+   struct device_node *node = of_node_get(np);
+   int ret = 0;
+   struct resource_entry *window;
+   LIST_HEAD(res);
+
+   if (!node)
+   return -EINVAL;
+
+   *size = 0;
+   /*
+* PCI dma-ranges is not mandatory property.
+* many devices do no need to have it, since
+* host bridge does not require inbound memory
+* configuration or rather have design limitations.
+* so we look for dma-ranges, if missing we
+* just return the caller full size, and also
+* no dma-ranges suggests that, host bridge allows
+* whatever comes in, so we set dma_addr to 0.
+*/
+   ret = of_pci_get_dma_ranges(np, );
+   if (!ret) {
+   resource_list_for_each_entry(window, ) {
+   struct resource *res_dma = window->res;
+
+   if (*size < resource_size(res_dma)) {
+   *dma_addr = res_dma->start - window->offset;
+   *paddr = res_dma->start;
+   *size = resource_size(res_dma);
+   }
+   }
+   }
+   pci_free_resource_list();
+
+   /*
+* return the largest possible size,
+* since PCI master allows everything.
+*/
+   if (*size == 0) {
+   pr_debug("empty/zero size dma-ranges found for node(%s)\n",
+   np->full_name);
+   *size = DMA_BIT_MASK(sizeof(dma_addr_t) * 8) - 1;
+   *dma_addr = *paddr = 0;
+   ret = 0;
+   }
+
+   pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
+*dma_addr, *paddr, *size);
+
+   of_node_put(node);
+
+   return ret;
+}
+
+static int get_dma_ranges(struct device_node *np, u64 *dma_addr,
+   u64 *paddr, u64 *size)
+{
+   struct device_node *node = of_node_get(np);
+   const __be32 *ranges = NULL;
+   int len, naddr, nsize, pna;
+   int ret = 0;
+   u64 dmaaddr;
+
+   if (!node)
+   return -EINVAL;
+
+   while (1) {
+   naddr = of_n_addr_cells(node);
+   nsize = of_n_size_cells(node);
+   node = of_get_next_parent(node);
+   if (!node)
+   break;
+
+   ranges = of_get_property(node, "dma-ranges", );
+
+   /* Ignore empty ranges, they imply no translation required */
+   if (ranges && len > 0)
+   break;
+
+   /*
+* At least empty ranges has to be defined for parent node if
+* DMA is supported
+*/
+   if (!ranges)
+   break;
+   }
+
+   if (!ranges) {
+   pr_debug("no dma-ranges found for node(%s)\n", np->full_name);
+   ret = -ENODEV;
+   goto out;
+   }
+
+   len /= sizeof(u32);
+
+   pna = 

[PATCH v6 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges

[Oza Pawandeep]

current device framework and OF framework integration assumes
dma-ranges in a way where memory-mapped devices define their
dma-ranges. (child-bus-address, parent-bus-address, length).

of_dma_configure is specifically written to take care of memory
mapped devices. but no implementation exists for pci to take
care of pcie based memory ranges.

for e.g. iproc based SOCs and other SOCs(suc as rcar) have PCI
world dma-ranges.
dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;

this patch fixes the following problems of_dma_get_range.
1) return of wrong size as 0.
2) not handling absence of dma-ranges which is valid for PCI master.
3) not handling multipe inbound windows.
4) in order to get largest possible dma_mask. this patch also
retuns the largest possible size based on dma-ranges,

for e.g.
dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
we should get dev->coherent_dma_mask=0x7f.

based on which IOVA allocation space will honour PCI host
bridge limitations.

the implementation hooks bus specific callbacks for getting
dma-ranges.

Signed-off-by: Oza Pawandeep 

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 02b2903..800731c 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -46,6 +47,8 @@ struct of_bus {
int na, int ns, int pna);
int (*translate)(__be32 *addr, u64 offset, int na);
unsigned int(*get_flags)(const __be32 *addr);
+   int (*get_dma_ranges)(struct device_node *np,
+ u64 *dma_addr, u64 *paddr, u64 *size);
 };
 
 /*
@@ -171,6 +174,144 @@ static int of_bus_pci_translate(__be32 *addr, u64 offset, 
int na)
 {
return of_bus_default_translate(addr + 1, offset, na - 1);
 }
+
+static int of_bus_pci_get_dma_ranges(struct device_node *np, u64 *dma_addr,
+u64 *paddr, u64 *size)
+{
+   struct device_node *node = of_node_get(np);
+   int ret = 0;
+   struct resource_entry *window;
+   LIST_HEAD(res);
+
+   if (!node)
+   return -EINVAL;
+
+   *size = 0;
+   /*
+* PCI dma-ranges is not mandatory property.
+* many devices do no need to have it, since
+* host bridge does not require inbound memory
+* configuration or rather have design limitations.
+* so we look for dma-ranges, if missing we
+* just return the caller full size, and also
+* no dma-ranges suggests that, host bridge allows
+* whatever comes in, so we set dma_addr to 0.
+*/
+   ret = of_pci_get_dma_ranges(np, );
+   if (!ret) {
+   resource_list_for_each_entry(window, ) {
+   struct resource *res_dma = window->res;
+
+   if (*size < resource_size(res_dma)) {
+   *dma_addr = res_dma->start - window->offset;
+   *paddr = res_dma->start;
+   *size = resource_size(res_dma);
+   }
+   }
+   }
+   pci_free_resource_list();
+
+   /*
+* return the largest possible size,
+* since PCI master allows everything.
+*/
+   if (*size == 0) {
+   pr_debug("empty/zero size dma-ranges found for node(%s)\n",
+   np->full_name);
+   *size = DMA_BIT_MASK(sizeof(dma_addr_t) * 8) - 1;
+   *dma_addr = *paddr = 0;
+   ret = 0;
+   }
+
+   pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
+*dma_addr, *paddr, *size);
+
+   of_node_put(node);
+
+   return ret;
+}
+
+static int get_dma_ranges(struct device_node *np, u64 *dma_addr,
+   u64 *paddr, u64 *size)
+{
+   struct device_node *node = of_node_get(np);
+   const __be32 *ranges = NULL;
+   int len, naddr, nsize, pna;
+   int ret = 0;
+   u64 dmaaddr;
+
+   if (!node)
+   return -EINVAL;
+
+   while (1) {
+   naddr = of_n_addr_cells(node);
+   nsize = of_n_size_cells(node);
+   node = of_get_next_parent(node);
+   if (!node)
+   break;
+
+   ranges = of_get_property(node, "dma-ranges", );
+
+   /* Ignore empty ranges, they imply no translation required */
+   if (ranges && len > 0)
+   break;
+
+   /*
+* At least empty ranges has to be defined for parent node if
+* DMA is supported
+*/
+   if (!ranges)
+   break;
+   }
+
+   if (!ranges) {
+   pr_debug("no dma-ranges found for node(%s)\n", np->full_name);
+   ret = -ENODEV;
+   goto out;
+   }
+
+   len /= sizeof(u32);
+
+   pna = of_n_addr_cells(node);

Re: CVE-2016-10229 in 4.4.x series

[Willy Tarreau]

On Mon, May 15, 2017 at 06:09:53PM -0700, Steven Pease wrote:
> Hi,
> 
> This is my first post - not currently subscribed so please CC me. :) I
> searched a bit for this question, but couldn't find an answer (Googled
> '2016-10229 site:lkml.org').
> 
> Does CVE-2016-10229 affect the newest version of the 4.4.x kernel
> series (currently 4.4.68) and are there any plans to fix this in the
> 4.4 kernel series?

This one was fixed by upstream commit 197c949 ("udp: properly support
MSG_PEEK with truncated buffers"), which was backported in 4.4 as
commit dfe2042d96 in 4.4.21. So in short, 4.4.68 is safe.

Willy

Re: CVE-2016-10229 in 4.4.x series

[Willy Tarreau]

On Mon, May 15, 2017 at 06:09:53PM -0700, Steven Pease wrote:
> Hi,
> 
> This is my first post - not currently subscribed so please CC me. :) I
> searched a bit for this question, but couldn't find an answer (Googled
> '2016-10229 site:lkml.org').
> 
> Does CVE-2016-10229 affect the newest version of the 4.4.x kernel
> series (currently 4.4.68) and are there any plans to fix this in the
> 4.4 kernel series?

This one was fixed by upstream commit 197c949 ("udp: properly support
MSG_PEEK with truncated buffers"), which was backported in 4.4 as
commit dfe2042d96 in 4.4.21. So in short, 4.4.68 is safe.

Willy

Re: [PATCH 1/4] power: supply: axp20x_battery: add support for DT battery

[Chen-Yu Tsai]

On Thu, May 11, 2017 at 9:42 PM, Quentin Schulz
 wrote:
> This adds support in X-Powers AXP20X and AXP22X battery driver for a
> fixed battery in DT.
>
> It will take the minimum supported voltage by the battery as defined in
> the battery DT node and set the V_OFF register to this value, telling
> the system to shut down if the supplied power is below this value.
>
> Signed-off-by: Quentin Schulz 
> ---
>  drivers/power/supply/axp20x_battery.c | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/power/supply/axp20x_battery.c 
> b/drivers/power/supply/axp20x_battery.c
> index 5d29b2eab8fc..66f530541735 100644
> --- a/drivers/power/supply/axp20x_battery.c
> +++ b/drivers/power/supply/axp20x_battery.c
> @@ -433,6 +433,7 @@ static int axp20x_power_probe(struct platform_device 
> *pdev)
>  {
> struct axp20x_batt_ps *axp20x_batt;
> struct power_supply_config psy_cfg = {};
> +   struct power_supply_battery_info info;
>
> if (!of_device_is_available(pdev->dev.of_node))
> return -ENODEV;
> @@ -484,6 +485,15 @@ static int axp20x_power_probe(struct platform_device 
> *pdev)
> return PTR_ERR(axp20x_batt->batt);
> }
>
> +   if (!power_supply_get_battery_info(axp20x_batt->batt, )) {

This is not in -next. It would help if you mention any requisite patches.

ChenYu

> +   int vmin = info.voltage_min_design_uv;
> +
> +   if (vmin > 0 && axp20x_set_voltage_min_design(axp20x_batt,
> + vmin))
> +   dev_err(>dev,
> +   "couldn't set voltage_min_design\n");
> +   }
> +
> return 0;
>  }
>
> --
> 2.11.0
>

Re: [PATCH 1/4] power: supply: axp20x_battery: add support for DT battery

[Chen-Yu Tsai]

On Thu, May 11, 2017 at 9:42 PM, Quentin Schulz
 wrote:
> This adds support in X-Powers AXP20X and AXP22X battery driver for a
> fixed battery in DT.
>
> It will take the minimum supported voltage by the battery as defined in
> the battery DT node and set the V_OFF register to this value, telling
> the system to shut down if the supplied power is below this value.
>
> Signed-off-by: Quentin Schulz 
> ---
>  drivers/power/supply/axp20x_battery.c | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/power/supply/axp20x_battery.c 
> b/drivers/power/supply/axp20x_battery.c
> index 5d29b2eab8fc..66f530541735 100644
> --- a/drivers/power/supply/axp20x_battery.c
> +++ b/drivers/power/supply/axp20x_battery.c
> @@ -433,6 +433,7 @@ static int axp20x_power_probe(struct platform_device 
> *pdev)
>  {
> struct axp20x_batt_ps *axp20x_batt;
> struct power_supply_config psy_cfg = {};
> +   struct power_supply_battery_info info;
>
> if (!of_device_is_available(pdev->dev.of_node))
> return -ENODEV;
> @@ -484,6 +485,15 @@ static int axp20x_power_probe(struct platform_device 
> *pdev)
> return PTR_ERR(axp20x_batt->batt);
> }
>
> +   if (!power_supply_get_battery_info(axp20x_batt->batt, )) {

This is not in -next. It would help if you mention any requisite patches.

ChenYu

> +   int vmin = info.voltage_min_design_uv;
> +
> +   if (vmin > 0 && axp20x_set_voltage_min_design(axp20x_batt,
> + vmin))
> +   dev_err(>dev,
> +   "couldn't set voltage_min_design\n");
> +   }
> +
> return 0;
>  }
>
> --
> 2.11.0
>

[PATCH v2] kbuild: skip install/check of headers right under uapi directories

[Masahiro Yamada]

Since commit 61562f981e92 ("uapi: export all arch specifics
directories"), "make INSTALL_HDR_PATH=$root/usr headers_install"
deletes standard glibc headers and others in $root/usr/include.

The cause of the issue is that headers_install now starts descending
from arch/$(hdr-arch)/include/uapi with $root/usr/include for its
destination when installing asm headers.  So, headers already there
are assumed to be unwanted.

When headers_install starts descending from include/uapi with
$root/usr/include for its destination, it works around the problem
by creating an dummy destination $root/usr/include/uapi, but this
is tricky.

To fix the problem in a clean way is to skip headers install/check
in include/uapi or arch/$(hdr-arch)/include/uapi because we know
there are only sub-directories in uapi directories.  A good side
effect is the empty destination $root/usr/include/uapi will go
away.

I am also removing the trailing slash in the headers_check target to
skip checking in arch/$(hdr-arch)/include/uapi.

Fixes: 61562f981e92 ("uapi: export all arch specifics directories")
Reported-by: Dan Williams 
Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Remove trailing slash from $(hdr-inst)=... of headers_check

 Makefile |  2 +-
 scripts/Makefile.headersinst | 43 +++
 2 files changed, 28 insertions(+), 17 deletions(-)

diff --git a/Makefile b/Makefile
index b400c06..b1ee4a4 100644
--- a/Makefile
+++ b/Makefile
@@ -1172,7 +1172,7 @@ headers_check_all: headers_install_all
 PHONY += headers_check
 headers_check: headers_install
$(Q)$(MAKE) $(hdr-inst)=include/uapi HDRCHECK=1
-   $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/ $(hdr-dst) 
HDRCHECK=1
+   $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi $(hdr-dst) 
HDRCHECK=1
 
 # ---
 # Kernel selftest
diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst
index 6ba97a1..ce753a4 100644
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
@@ -8,6 +8,29 @@
 #
 # ==
 
+PHONY := __headers
+__headers:
+
+include scripts/Kbuild.include
+
+srcdir:= $(srctree)/$(obj)
+subdirs   := $(patsubst $(srcdir)/%/.,%,$(wildcard $(srcdir)/*/.))
+# caller may set destination dir (when installing to asm/)
+_dst  := $(if $(dst),$(dst),$(obj))
+
+# Recursion
+__headers: $(subdirs)
+
+.PHONY: $(subdirs)
+$(subdirs):
+   $(Q)$(MAKE) $(hdr-inst)=$(obj)/$@ dst=$(_dst)/$@
+
+# Skip header install/check for include/uapi and arch/$(hdr-arch)/include/uapi.
+# We have only sub-directories there.
+skip-inst := $(if $(filter %/uapi,$(obj)),1)
+
+ifeq ($(skip-inst),)
+
 # generated header directory
 gen := $(if $(gen),$(gen),$(subst include/,include/generated/,$(obj)))
 
@@ -15,21 +38,14 @@ gen := $(if $(gen),$(gen),$(subst 
include/,include/generated/,$(obj)))
 kbuild-file := $(srctree)/$(obj)/Kbuild
 -include $(kbuild-file)
 
-# called may set destination dir (when installing to asm/)
-_dst := $(if $(dst),$(dst),$(obj))
-
 old-kbuild-file := $(srctree)/$(subst uapi/,,$(obj))/Kbuild
 ifneq ($(wildcard $(old-kbuild-file)),)
 include $(old-kbuild-file)
 endif
 
-include scripts/Kbuild.include
-
 installdir:= $(INSTALL_HDR_PATH)/$(subst uapi/,,$(_dst))
 
-srcdir:= $(srctree)/$(obj)
 gendir:= $(objtree)/$(gen)
-subdirs   := $(patsubst $(srcdir)/%/.,%,$(wildcard $(srcdir)/*/.))
 header-files  := $(notdir $(wildcard $(srcdir)/*.h))
 header-files  += $(notdir $(wildcard $(srcdir)/*.agh))
 header-files  := $(filter-out $(no-export-headers), $(header-files))
@@ -88,11 +104,9 @@ quiet_cmd_check = CHECK   $(printdir) ($(words 
$(all-files)) files)
   $(PERL) $< $(INSTALL_HDR_PATH)/include $(SRCARCH); \
  touch $@
 
-PHONY += __headersinst __headerscheck
-
 ifndef HDRCHECK
 # Rules for installing headers
-__headersinst: $(subdirs) $(install-file)
+__headers: $(install-file)
@:
 
 targets += $(install-file)
@@ -104,7 +118,7 @@ $(install-file): scripts/headers_install.sh \
$(call if_changed,install)
 
 else
-__headerscheck: $(subdirs) $(check-file)
+__headers: $(check-file)
@:
 
 targets += $(check-file)
@@ -113,11 +127,6 @@ $(check-file): scripts/headers_check.pl $(output-files) 
FORCE
 
 endif
 
-# Recursion
-.PHONY: $(subdirs)
-$(subdirs):
-   $(Q)$(MAKE) $(hdr-inst)=$(obj)/$@ dst=$(_dst)/$@
-
 targets := $(wildcard $(sort $(targets)))
 cmd_files := $(wildcard \
  $(foreach f,$(targets),$(dir $(f)).$(notdir $(f)).cmd))
@@ -126,6 +135,8 @@ ifneq ($(cmd_files),)
include $(cmd_files)
 endif
 
+endif # skip-inst
+
 .PHONY: $(PHONY)
 PHONY += FORCE
 FORCE: ;
-- 
2.7.4

[PATCH v2] kbuild: skip install/check of headers right under uapi directories

[Masahiro Yamada]

Since commit 61562f981e92 ("uapi: export all arch specifics
directories"), "make INSTALL_HDR_PATH=$root/usr headers_install"
deletes standard glibc headers and others in $root/usr/include.

The cause of the issue is that headers_install now starts descending
from arch/$(hdr-arch)/include/uapi with $root/usr/include for its
destination when installing asm headers.  So, headers already there
are assumed to be unwanted.

When headers_install starts descending from include/uapi with
$root/usr/include for its destination, it works around the problem
by creating an dummy destination $root/usr/include/uapi, but this
is tricky.

To fix the problem in a clean way is to skip headers install/check
in include/uapi or arch/$(hdr-arch)/include/uapi because we know
there are only sub-directories in uapi directories.  A good side
effect is the empty destination $root/usr/include/uapi will go
away.

I am also removing the trailing slash in the headers_check target to
skip checking in arch/$(hdr-arch)/include/uapi.

Fixes: 61562f981e92 ("uapi: export all arch specifics directories")
Reported-by: Dan Williams 
Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Remove trailing slash from $(hdr-inst)=... of headers_check

 Makefile |  2 +-
 scripts/Makefile.headersinst | 43 +++
 2 files changed, 28 insertions(+), 17 deletions(-)

diff --git a/Makefile b/Makefile
index b400c06..b1ee4a4 100644
--- a/Makefile
+++ b/Makefile
@@ -1172,7 +1172,7 @@ headers_check_all: headers_install_all
 PHONY += headers_check
 headers_check: headers_install
$(Q)$(MAKE) $(hdr-inst)=include/uapi HDRCHECK=1
-   $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi/ $(hdr-dst) 
HDRCHECK=1
+   $(Q)$(MAKE) $(hdr-inst)=arch/$(hdr-arch)/include/uapi $(hdr-dst) 
HDRCHECK=1
 
 # ---
 # Kernel selftest
diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst
index 6ba97a1..ce753a4 100644
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
@@ -8,6 +8,29 @@
 #
 # ==
 
+PHONY := __headers
+__headers:
+
+include scripts/Kbuild.include
+
+srcdir:= $(srctree)/$(obj)
+subdirs   := $(patsubst $(srcdir)/%/.,%,$(wildcard $(srcdir)/*/.))
+# caller may set destination dir (when installing to asm/)
+_dst  := $(if $(dst),$(dst),$(obj))
+
+# Recursion
+__headers: $(subdirs)
+
+.PHONY: $(subdirs)
+$(subdirs):
+   $(Q)$(MAKE) $(hdr-inst)=$(obj)/$@ dst=$(_dst)/$@
+
+# Skip header install/check for include/uapi and arch/$(hdr-arch)/include/uapi.
+# We have only sub-directories there.
+skip-inst := $(if $(filter %/uapi,$(obj)),1)
+
+ifeq ($(skip-inst),)
+
 # generated header directory
 gen := $(if $(gen),$(gen),$(subst include/,include/generated/,$(obj)))
 
@@ -15,21 +38,14 @@ gen := $(if $(gen),$(gen),$(subst 
include/,include/generated/,$(obj)))
 kbuild-file := $(srctree)/$(obj)/Kbuild
 -include $(kbuild-file)
 
-# called may set destination dir (when installing to asm/)
-_dst := $(if $(dst),$(dst),$(obj))
-
 old-kbuild-file := $(srctree)/$(subst uapi/,,$(obj))/Kbuild
 ifneq ($(wildcard $(old-kbuild-file)),)
 include $(old-kbuild-file)
 endif
 
-include scripts/Kbuild.include
-
 installdir:= $(INSTALL_HDR_PATH)/$(subst uapi/,,$(_dst))
 
-srcdir:= $(srctree)/$(obj)
 gendir:= $(objtree)/$(gen)
-subdirs   := $(patsubst $(srcdir)/%/.,%,$(wildcard $(srcdir)/*/.))
 header-files  := $(notdir $(wildcard $(srcdir)/*.h))
 header-files  += $(notdir $(wildcard $(srcdir)/*.agh))
 header-files  := $(filter-out $(no-export-headers), $(header-files))
@@ -88,11 +104,9 @@ quiet_cmd_check = CHECK   $(printdir) ($(words 
$(all-files)) files)
   $(PERL) $< $(INSTALL_HDR_PATH)/include $(SRCARCH); \
  touch $@
 
-PHONY += __headersinst __headerscheck
-
 ifndef HDRCHECK
 # Rules for installing headers
-__headersinst: $(subdirs) $(install-file)
+__headers: $(install-file)
@:
 
 targets += $(install-file)
@@ -104,7 +118,7 @@ $(install-file): scripts/headers_install.sh \
$(call if_changed,install)
 
 else
-__headerscheck: $(subdirs) $(check-file)
+__headers: $(check-file)
@:
 
 targets += $(check-file)
@@ -113,11 +127,6 @@ $(check-file): scripts/headers_check.pl $(output-files) 
FORCE
 
 endif
 
-# Recursion
-.PHONY: $(subdirs)
-$(subdirs):
-   $(Q)$(MAKE) $(hdr-inst)=$(obj)/$@ dst=$(_dst)/$@
-
 targets := $(wildcard $(sort $(targets)))
 cmd_files := $(wildcard \
  $(foreach f,$(targets),$(dir $(f)).$(notdir $(f)).cmd))
@@ -126,6 +135,8 @@ ifneq ($(cmd_files),)
include $(cmd_files)
 endif
 
+endif # skip-inst
+
 .PHONY: $(PHONY)
 PHONY += FORCE
 FORCE: ;
-- 
2.7.4

Re: [PATCH v2 5/8] drm: Use new mode_valid() helpers in connector probe helper

[Jose Abreu]

Hi Laurent,


On 15-05-2017 08:05, Laurent Pinchart wrote:
> On Monday 15 May 2017 08:47:49 Daniel Vetter wrote:
>> On Sun, May 14, 2017 at 02:04:24PM +0300, Laurent Pinchart wrote:
>>> On Friday 12 May 2017 17:06:14 Jose Abreu wrote:
 On 12-05-2017 10:35, Laurent Pinchart wrote:
> On Tuesday 09 May 2017 18:00:12 Jose Abreu wrote:
>> +if (mode->status == MODE_OK)
>> +mode->status = 
> drm_mode_validate_connector(connector,
>> 
> mode);
> I would reverse the arguments order to match the style of the other
> validation functions.
 Hmm, I think it makes more sense to pass connector first and then
 mode ...
>>> I disagree, as this function validates a mode against a pipeline, the same
>>> way the other validation functions validate a mode against other
>>> parameters, but it's your patch :-)
>> Call it drm_connector_validate_mode, because the first argument is
>> generally the object we operate on :-)
> But the function doesn't validate a mode for a connector, it validates a mode 
> for a complete pipeline...
>

Hmm, but note that in the same function there is
drm_mode_validate_size() and drm_mode_validate_flag() calls,
which take as first argument the mode and then the object to
validate (I hadn't seen this). So, maybe leave it as
drm_mode_validate_connector() as it takes a connector as argument
or change to drm_mode_validate_pipeline() as you said, or even
drm_mode_validate_datapath(), drm_mode_validate_videopath(),
drm_mode_validate_components() ?

Best regards,
Jose Miguel Abreu

Re: [PATCH v2 5/8] drm: Use new mode_valid() helpers in connector probe helper

[Jose Abreu]

Hi Laurent,


On 15-05-2017 08:05, Laurent Pinchart wrote:
> On Monday 15 May 2017 08:47:49 Daniel Vetter wrote:
>> On Sun, May 14, 2017 at 02:04:24PM +0300, Laurent Pinchart wrote:
>>> On Friday 12 May 2017 17:06:14 Jose Abreu wrote:
 On 12-05-2017 10:35, Laurent Pinchart wrote:
> On Tuesday 09 May 2017 18:00:12 Jose Abreu wrote:
>> +if (mode->status == MODE_OK)
>> +mode->status = 
> drm_mode_validate_connector(connector,
>> 
> mode);
> I would reverse the arguments order to match the style of the other
> validation functions.
 Hmm, I think it makes more sense to pass connector first and then
 mode ...
>>> I disagree, as this function validates a mode against a pipeline, the same
>>> way the other validation functions validate a mode against other
>>> parameters, but it's your patch :-)
>> Call it drm_connector_validate_mode, because the first argument is
>> generally the object we operate on :-)
> But the function doesn't validate a mode for a connector, it validates a mode 
> for a complete pipeline...
>

Hmm, but note that in the same function there is
drm_mode_validate_size() and drm_mode_validate_flag() calls,
which take as first argument the mode and then the object to
validate (I hadn't seen this). So, maybe leave it as
drm_mode_validate_connector() as it takes a connector as argument
or change to drm_mode_validate_pipeline() as you said, or even
drm_mode_validate_datapath(), drm_mode_validate_videopath(),
drm_mode_validate_components() ?

Best regards,
Jose Miguel Abreu

RE: [PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method mode"

[Zheng, Lv]

Hi, Benjamin

I reordered the discussion to collect topics and delete things to make 
discussion shorter.

1. root caused issue:

> > It seems we just need to determine the following first:
> > 1. Who should be responsible for solving bugs triggered by the conflict 
> > between bios and linux user
> space expectations:
> >button driver? libinput? Some other user space programs? Users?
> Hopefully libinput or systemd (through a udev rule). If things gets
> worse a acpi/button quirk might be used, but in a second time.

I have concerns about what's in your mind. :)

So let me high light a root caused issue:
https://bugzilla.kernel.org/show_bug.cgi?id=106151
If we use any "open" modes, the suspend/resume loop can be fixed.
Both "ignore/method" modes cannot fix the problem.
In this bug, lid open event has a huge delay. But it can correctly arrive.
However systemd will force 2nd suspend if it cannot see "open" event instantly 
after resume.
So why don't systemd fix the issue (the enforcement) prior than letting us 
(input layer/button driver) to invent workarounds?
IMO, this is a root caused problem and should be the first priority.
Before seeing it is addressed in systemd, any changes made to libinput/button 
driver may not be proper.

So the order of fixing all troubles are the followings in my mind:
1. system -> should eliminate the enforcement first
2. libinput -> may change lid event type (see my reply below for topic 2)
3. button driver

> > > > > The issue we are fixing here is the fact that the switch state is 
> > > > > wrong,
> > > > > which makes user space assumptions wrong too (and users angry).
> > > > Considering no platform quirks.
> > > > If ACPI button driver sends SW_LID, users are likely angry.
> > > > Unless the user space programs are changed to "ignore open event".
> > > > If ACPI button driver doesn't send switch events, but key events.
> > > > The user space programs need to change to handle the new events.
> > > > So finally whatever we do, user space need to change a bit related to 
> > > > ACPI control method lid
> device.
> > > Or we fix the switch to report accurate events/state.
> > > You do realise that all the energy you are spending, answering to me,
> > > talking to user space maintainers, users, all comes down to the fact
> > > that you refuse to have hardware quirks?

Yes, as we have a root caused but unfixed issue in systemd first.
It's pointless to introduce hardware quirks at this point.

> > Thus there is no possible __FIX__ for acpi button driver and libinput.
> I never talked about a fix. I know the situation is unsolvable, which is
> why I talked about quirks or workarounds.
> > While user space programs can just fix their usage models.
> You can't expect user space to change anything from the kernel point of
> view without a long enough warning.

Why cannot we expect so?
The above issue has already been root caused.

> > > > > > However, is that possible to not introduce platform quirks?
> > > > > > For example, for systemd:
> > > > > > If it detected ACPI lid device, automatically switch to an 
> > > > > > "IgnoreLidOpenEvent" mode (like
> > > nouveau
> > > > > drivers' ignorelid=Y option).
> > > > > Well, given that 99.9% of laptops have this ACPI lid button, you'll 
> > > > > just
> > > > > remove the feature from all laptops.
> > > > No, I only removed the wrong usage models related to the strict "open" 
> > > > event.
> > > > All laptops are still capable of sending correct "close" event.
> > > My bad, I read too fast and missed the "...Open..." part of
> > > "IgnoreLidOpenEvent".
> > > Though I am not sure IgnoreLidOpenEvent is accurate.
> > > "OpenEventNeverSent" seems to reflect more the reality. But again,
> > > that's not of our (kernel developers) business.
> > IMO this is the only root cause fix. :)
> > It's the only way that the user can use without changing its quirk modes 
> > for different usage models.
> Yes and no. There is a design issue in logind, but this is based on the
> design choice made in acpi/button: we use an input switch. A switch has
> a state, and the kernel ought to report correct state. With this in
> mind, the design choice in logind is correct. But now we are
> seeing that some OEM are not providing everything we need, and we need
> to find the solution.

We can stop arguing this.
First of all, we just need to check if systemd can remove the enforcement 
mentioned above.
And what will happen next.
It's likely that there will be no user issues or button driver design issues 
then.
Thus finally we may needn't introduce any "hardware quirks".

2. keep "method" mode:

> > Button driver default behavior should be (not 100% sure if this is your 
> > opinion):
> button.lid_init_state=method
> 
> Yes, I'd like to revert to the old behavior (see below for a rationale).
...
> > 2. What should be the default button driver behavior?
> >button.lid_init_state=ignore? button.lid_init_state=method?
> button.lid_init_state=method:
> - this 

RE: [PATCH 1/2] Revert "ACPI / button: Remove lid_init_state=method mode"

[Zheng, Lv]

Hi, Benjamin

I reordered the discussion to collect topics and delete things to make 
discussion shorter.

1. root caused issue:

> > It seems we just need to determine the following first:
> > 1. Who should be responsible for solving bugs triggered by the conflict 
> > between bios and linux user
> space expectations:
> >button driver? libinput? Some other user space programs? Users?
> Hopefully libinput or systemd (through a udev rule). If things gets
> worse a acpi/button quirk might be used, but in a second time.

I have concerns about what's in your mind. :)

So let me high light a root caused issue:
https://bugzilla.kernel.org/show_bug.cgi?id=106151
If we use any "open" modes, the suspend/resume loop can be fixed.
Both "ignore/method" modes cannot fix the problem.
In this bug, lid open event has a huge delay. But it can correctly arrive.
However systemd will force 2nd suspend if it cannot see "open" event instantly 
after resume.
So why don't systemd fix the issue (the enforcement) prior than letting us 
(input layer/button driver) to invent workarounds?
IMO, this is a root caused problem and should be the first priority.
Before seeing it is addressed in systemd, any changes made to libinput/button 
driver may not be proper.

So the order of fixing all troubles are the followings in my mind:
1. system -> should eliminate the enforcement first
2. libinput -> may change lid event type (see my reply below for topic 2)
3. button driver

> > > > > The issue we are fixing here is the fact that the switch state is 
> > > > > wrong,
> > > > > which makes user space assumptions wrong too (and users angry).
> > > > Considering no platform quirks.
> > > > If ACPI button driver sends SW_LID, users are likely angry.
> > > > Unless the user space programs are changed to "ignore open event".
> > > > If ACPI button driver doesn't send switch events, but key events.
> > > > The user space programs need to change to handle the new events.
> > > > So finally whatever we do, user space need to change a bit related to 
> > > > ACPI control method lid
> device.
> > > Or we fix the switch to report accurate events/state.
> > > You do realise that all the energy you are spending, answering to me,
> > > talking to user space maintainers, users, all comes down to the fact
> > > that you refuse to have hardware quirks?

Yes, as we have a root caused but unfixed issue in systemd first.
It's pointless to introduce hardware quirks at this point.

> > Thus there is no possible __FIX__ for acpi button driver and libinput.
> I never talked about a fix. I know the situation is unsolvable, which is
> why I talked about quirks or workarounds.
> > While user space programs can just fix their usage models.
> You can't expect user space to change anything from the kernel point of
> view without a long enough warning.

Why cannot we expect so?
The above issue has already been root caused.

> > > > > > However, is that possible to not introduce platform quirks?
> > > > > > For example, for systemd:
> > > > > > If it detected ACPI lid device, automatically switch to an 
> > > > > > "IgnoreLidOpenEvent" mode (like
> > > nouveau
> > > > > drivers' ignorelid=Y option).
> > > > > Well, given that 99.9% of laptops have this ACPI lid button, you'll 
> > > > > just
> > > > > remove the feature from all laptops.
> > > > No, I only removed the wrong usage models related to the strict "open" 
> > > > event.
> > > > All laptops are still capable of sending correct "close" event.
> > > My bad, I read too fast and missed the "...Open..." part of
> > > "IgnoreLidOpenEvent".
> > > Though I am not sure IgnoreLidOpenEvent is accurate.
> > > "OpenEventNeverSent" seems to reflect more the reality. But again,
> > > that's not of our (kernel developers) business.
> > IMO this is the only root cause fix. :)
> > It's the only way that the user can use without changing its quirk modes 
> > for different usage models.
> Yes and no. There is a design issue in logind, but this is based on the
> design choice made in acpi/button: we use an input switch. A switch has
> a state, and the kernel ought to report correct state. With this in
> mind, the design choice in logind is correct. But now we are
> seeing that some OEM are not providing everything we need, and we need
> to find the solution.

We can stop arguing this.
First of all, we just need to check if systemd can remove the enforcement 
mentioned above.
And what will happen next.
It's likely that there will be no user issues or button driver design issues 
then.
Thus finally we may needn't introduce any "hardware quirks".

2. keep "method" mode:

> > Button driver default behavior should be (not 100% sure if this is your 
> > opinion):
> button.lid_init_state=method
> 
> Yes, I'd like to revert to the old behavior (see below for a rationale).
...
> > 2. What should be the default button driver behavior?
> >button.lid_init_state=ignore? button.lid_init_state=method?
> button.lid_init_state=method:
> - this 

Re: [PATCH] kbuild: skip header install/check for right under uapi directories

[Dan Williams]

On Mon, May 15, 2017 at 9:35 PM, Masahiro Yamada
 wrote:
> Since commit 61562f981e92 ("uapi: export all arch specifics
> directories"), "make INSTALL_HDR_PATH=${root}/usr headers_install"
> deletes standard glibc headers and others in ${root}/usr/include.
>
> The cause of the issue is that headers_install now starts descending
> from arch/$(hdr-arch)/include/uapi with ${root}/usr/include for its
> destination when installing asm headers.  So, headers already there
> are assumed to be unwanted.
>
> When headers_install starts descending from include/uapi with
> ${root}/usr/include for its destination, it works around the problem
> by creating an dummy destination ${root}/usr/include/uapi, but this
> is tricky.
>
> To fix the problem in a clean way is to skip header install/check in
> include/uapi or arch/$(hdr-arch)/include/uapi.  A good side-effect
> is the empty destination ${root}/usr/include/uapi will go away.
>
> Fixes: 61562f981e92 ("uapi: export all arch specifics directories")
> Reported-by: Dan Williams 
> Signed-off-by: Masahiro Yamada 

Works for me.

Tested-by: Dan Williams 

Re: [PATCH] kbuild: skip header install/check for right under uapi directories

[Dan Williams]

On Mon, May 15, 2017 at 9:35 PM, Masahiro Yamada
 wrote:
> Since commit 61562f981e92 ("uapi: export all arch specifics
> directories"), "make INSTALL_HDR_PATH=${root}/usr headers_install"
> deletes standard glibc headers and others in ${root}/usr/include.
>
> The cause of the issue is that headers_install now starts descending
> from arch/$(hdr-arch)/include/uapi with ${root}/usr/include for its
> destination when installing asm headers.  So, headers already there
> are assumed to be unwanted.
>
> When headers_install starts descending from include/uapi with
> ${root}/usr/include for its destination, it works around the problem
> by creating an dummy destination ${root}/usr/include/uapi, but this
> is tricky.
>
> To fix the problem in a clean way is to skip header install/check in
> include/uapi or arch/$(hdr-arch)/include/uapi.  A good side-effect
> is the empty destination ${root}/usr/include/uapi will go away.
>
> Fixes: 61562f981e92 ("uapi: export all arch specifics directories")
> Reported-by: Dan Williams 
> Signed-off-by: Masahiro Yamada 

Works for me.

Tested-by: Dan Williams 

[Qustion] vmalloc area overlap with another allocated vmalloc area

[zhong jiang]

Hi

I  hit the following issue by runing /proc/vmallocinfo.  The kernel is 4.1 
stable and
32 bit to be used.  after I expand the vamlloc area,  the issue is not occur 
again.
it is related to the overflow. but I do not see any problem so far.

cat /proc/vmallocinfo
0xf158-0xf160  524288 raw_dump_mem_write+0x10c/0x188 phys=8b901000 
ioremap
0xf1638000-0xf163a0008192 mcss_pou_queue_init+0xa0/0x13c [mcss] 
phys=fc614000 ioremap
0xf528e000-0xf5292000   16384 n_tty_open+0x10/0xd0 pages=3 vmalloc
0xf500-0xf9001000 67112960 devm_ioremap+0x38/0x70 phys=4000 ioremap
0xfe001000-0xfe0020004096 iotable_init+0x0/0xc phys=20001000 ioremap
0xfe20-0xfe2010004096 iotable_init+0x0/0xc phys=1a00 ioremap
0xff10-0xff1010004096 iotable_init+0x0/0xc phys=2000a000 ioremap

n_tty_open allocate the vmap area is surrounded by the devm_ioremap ioremap by 
above info.
I do not see also the race in the condition.

I have no idea to the issue.  Anyone has any suggestions will be appreicated.
The related config is attatched.

Thanks
zhongjiang
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 4.1.12 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_MIGHT_HAVE_PCI=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_IRQ_BYPASS is not set
# CONFIG_LIB_INTERRUPT is not set
# CONFIG_SET_IRQPRIORITY is not set
# CONFIG_SRE_PREHANDLER is not set
# CONFIG_IPI_COMBINE is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIQ=y
CONFIG_VECTORS_BASE=0x
CONFIG_NEED_MACH_MEMORY_H=y
CONFIG_PHYS_OFFSET=0x800
CONFIG_GENERIC_BUG=y
CONFIG_PGTABLE_LEVELS=2
# CONFIG_ARCH_AARCH32_ES_SUPPORT is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
CONFIG_KERNEL_LZMA=y
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SY SCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_FHANDLE is not set
# CONFIG_USELIB is not set
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_SHOW_LEVEL=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_HANDLE_DOMAIN_IRQ=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_ARCH_HAS_TICK_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y

#
# Timers subsystem
#
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
CONFIG_SRCU=y
# CONFIG_TASKS_RCU is not set
CONFIG_RCU_STALL_COMMON=y
# CONFIG_RCU_USER_QS is not set
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_RCU_KTHREAD_PRIO=0
# CONFIG_RCU_NOCB_CPU is not set
# CONFIG_RCU_EXPEDITE_BOOT is not set
# CONFIG_BUILD_BIN2C is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=14
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_GENERIC_SCHED_CLOCK=y
CONFIG_CGROUPS=y
CONFIG_CGROUP_DEBUG=y
# CONFIG_CGROUP_FREEZER is not set
# CONFIG_CGROUP_PIDS is not set
# CONFIG_CGROUP_DEVICE is not set
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
# CONFIG_MEMCG is not set
# CONFIG_CGROUP_HUGETLB is not set
# CONFIG_CGROUP_PERF is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
# CONFIG_RT_GROUP_SCHED is not set
# CONFIG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_RD_GZIP is not set
# CONFIG_RD_BZIP2 is not set
CONFIG_RD_LZMA=y
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_BPF=y
CONFIG_EXPERT=y

[Qustion] vmalloc area overlap with another allocated vmalloc area

[zhong jiang]

Hi

I  hit the following issue by runing /proc/vmallocinfo.  The kernel is 4.1 
stable and
32 bit to be used.  after I expand the vamlloc area,  the issue is not occur 
again.
it is related to the overflow. but I do not see any problem so far.

cat /proc/vmallocinfo
0xf158-0xf160  524288 raw_dump_mem_write+0x10c/0x188 phys=8b901000 
ioremap
0xf1638000-0xf163a0008192 mcss_pou_queue_init+0xa0/0x13c [mcss] 
phys=fc614000 ioremap
0xf528e000-0xf5292000   16384 n_tty_open+0x10/0xd0 pages=3 vmalloc
0xf500-0xf9001000 67112960 devm_ioremap+0x38/0x70 phys=4000 ioremap
0xfe001000-0xfe0020004096 iotable_init+0x0/0xc phys=20001000 ioremap
0xfe20-0xfe2010004096 iotable_init+0x0/0xc phys=1a00 ioremap
0xff10-0xff1010004096 iotable_init+0x0/0xc phys=2000a000 ioremap

n_tty_open allocate the vmap area is surrounded by the devm_ioremap ioremap by 
above info.
I do not see also the race in the condition.

I have no idea to the issue.  Anyone has any suggestions will be appreicated.
The related config is attatched.

Thanks
zhongjiang
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 4.1.12 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_MIGHT_HAVE_PCI=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_IRQ_BYPASS is not set
# CONFIG_LIB_INTERRUPT is not set
# CONFIG_SET_IRQPRIORITY is not set
# CONFIG_SRE_PREHANDLER is not set
# CONFIG_IPI_COMBINE is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIQ=y
CONFIG_VECTORS_BASE=0x
CONFIG_NEED_MACH_MEMORY_H=y
CONFIG_PHYS_OFFSET=0x800
CONFIG_GENERIC_BUG=y
CONFIG_PGTABLE_LEVELS=2
# CONFIG_ARCH_AARCH32_ES_SUPPORT is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
CONFIG_KERNEL_LZMA=y
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SY SCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_FHANDLE is not set
# CONFIG_USELIB is not set
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_SHOW_LEVEL=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_HANDLE_DOMAIN_IRQ=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_ARCH_HAS_TICK_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y

#
# Timers subsystem
#
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
CONFIG_SRCU=y
# CONFIG_TASKS_RCU is not set
CONFIG_RCU_STALL_COMMON=y
# CONFIG_RCU_USER_QS is not set
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_RCU_KTHREAD_PRIO=0
# CONFIG_RCU_NOCB_CPU is not set
# CONFIG_RCU_EXPEDITE_BOOT is not set
# CONFIG_BUILD_BIN2C is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=14
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_GENERIC_SCHED_CLOCK=y
CONFIG_CGROUPS=y
CONFIG_CGROUP_DEBUG=y
# CONFIG_CGROUP_FREEZER is not set
# CONFIG_CGROUP_PIDS is not set
# CONFIG_CGROUP_DEVICE is not set
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
# CONFIG_MEMCG is not set
# CONFIG_CGROUP_HUGETLB is not set
# CONFIG_CGROUP_PERF is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
# CONFIG_RT_GROUP_SCHED is not set
# CONFIG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_RD_GZIP is not set
# CONFIG_RD_BZIP2 is not set
CONFIG_RD_LZMA=y
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_BPF=y
CONFIG_EXPERT=y

Re: [lkp-robot] [asm] c1aad8dcc4: BUG:kernel_hang_in_boot_stage

[Ye Xiaolong]

On 05/16, Al Viro wrote:
>On Tue, May 16, 2017 at 09:19:57AM +0800, kernel test robot wrote:
>> 
>> FYI, we noticed the following commit:
>> 
>> commit: c1aad8dcc49382399f48541dc47b6e30b0ef1b62 ("asm-generic: zero in 
>> __get_user(), not __get_user_fn()")
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>> 
>> in testcase: trinity
>> with following parameters:
>> 
>>  runtime: 300s
>> 
>> test-description: Trinity is a linux system call fuzz tester.
>> test-url: http://codemonkey.org.uk/projects/trinity/
>> 
>> 
>> on test machine: qemu-system-x86_64 -enable-kvm -smp 2 -m 420M
>
>Huh?  That commit touches only include/asm-generic/uaccess.h and
>this file is not even looked at during x86 builds.

Just double checked, this error also showed in parent commit. So it's a false
positive. Sorry for the noise.

Thanks,
Xiaolong

Re: [lkp-robot] [asm] c1aad8dcc4: BUG:kernel_hang_in_boot_stage

[Ye Xiaolong]

On 05/16, Al Viro wrote:
>On Tue, May 16, 2017 at 09:19:57AM +0800, kernel test robot wrote:
>> 
>> FYI, we noticed the following commit:
>> 
>> commit: c1aad8dcc49382399f48541dc47b6e30b0ef1b62 ("asm-generic: zero in 
>> __get_user(), not __get_user_fn()")
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>> 
>> in testcase: trinity
>> with following parameters:
>> 
>>  runtime: 300s
>> 
>> test-description: Trinity is a linux system call fuzz tester.
>> test-url: http://codemonkey.org.uk/projects/trinity/
>> 
>> 
>> on test machine: qemu-system-x86_64 -enable-kvm -smp 2 -m 420M
>
>Huh?  That commit touches only include/asm-generic/uaccess.h and
>this file is not even looked at during x86 builds.

Just double checked, this error also showed in parent commit. So it's a false
positive. Sorry for the noise.

Thanks,
Xiaolong

Re: [PATCH v11 11/12] uapi: export all arch specifics directories

[Masahiro Yamada]

Hi Dan,


2017-05-16 10:15 GMT+09:00 Dan Williams :
> On Mon, May 15, 2017 at 6:02 PM, Dan Williams  
> wrote:
>> On Mon, Mar 27, 2017 at 5:20 AM, Nicolas Dichtel
>>  wrote:
>>> This patch removes the need of subdir-y. Now all files/directories under
>>> arch//include/uapi/ are exported.
>>>
>>> The only change for userland is the layout of the command 'make
>>> headers_install_all': directories asm- are replaced by arch-/.
>>> Those new directories contains all files/directories of the specified arch.
>>>
>>> Note that only cris and tile have more directories than only asm:
>>>  - arch-v[10|32] for cris;
>>>  - arch for tile.
>>>
>>> Signed-off-by: Nicolas Dichtel 
>>
>> Starting with commit 61562f981e92 "uapi: export all arch specifics
>> directories", a "make INSTALL_HDR_PATH=$root/usr headers_install"
>> operation will delete standard glibc headers and others in
>> $root/usr/include.
>
> Reverting commit 61562f981e92 fixes the problem for me.

Thank you for your bug report.

Could you check this?
https://patchwork.kernel.org/patch/9728323/



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v11 11/12] uapi: export all arch specifics directories

[Masahiro Yamada]

Hi Dan,


2017-05-16 10:15 GMT+09:00 Dan Williams :
> On Mon, May 15, 2017 at 6:02 PM, Dan Williams  
> wrote:
>> On Mon, Mar 27, 2017 at 5:20 AM, Nicolas Dichtel
>>  wrote:
>>> This patch removes the need of subdir-y. Now all files/directories under
>>> arch//include/uapi/ are exported.
>>>
>>> The only change for userland is the layout of the command 'make
>>> headers_install_all': directories asm- are replaced by arch-/.
>>> Those new directories contains all files/directories of the specified arch.
>>>
>>> Note that only cris and tile have more directories than only asm:
>>>  - arch-v[10|32] for cris;
>>>  - arch for tile.
>>>
>>> Signed-off-by: Nicolas Dichtel 
>>
>> Starting with commit 61562f981e92 "uapi: export all arch specifics
>> directories", a "make INSTALL_HDR_PATH=$root/usr headers_install"
>> operation will delete standard glibc headers and others in
>> $root/usr/include.
>
> Reverting commit 61562f981e92 fixes the problem for me.

Thank you for your bug report.

Could you check this?
https://patchwork.kernel.org/patch/9728323/



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption

[Dmitry Vyukov]

On Mon, May 15, 2017 at 9:34 PM, Dmitry Vyukov  wrote:
> On Mon, May 15, 2017 at 6:16 PM,   wrote:
>> From: Joonsoo Kim 
>>
>> Hello, all.
>>
>> This is an attempt to recude memory consumption of KASAN. Please see
>> following description to get the more information.
>>
>> 1. What is per-page shadow memory
>
> Hi Joonsoo,
>
> First I need to say that this is great work. I wanted KASAN to consume
> 1/8-th of _kernel_ memory rather than total physical memory for a long
> time.
>
> However, this implementation does not work inline instrumentation. And
> the inline instrumentation is the main mode for KASAN. Outline
> instrumentation is merely a rudiment to support gcc 4.9, and it needs
> to be removed as soon as we stop caring about gcc 4.9 (do we at all?
> is it the current compiler in any distro? Ubuntu 12 has 4.8, Ubuntu 14
> already has 5.4. And if you build gcc yourself or get a fresher
> compiler from somewhere else, you hopefully get something better than
> 4.9).
>
> Here is an example boot+scp log with inline instrumentation:
> https://gist.githubusercontent.com/dvyukov/dfdc8b6972ddd260b201a85d5d5cdb5d/raw/2a032cd5be371c7ad6cad8f14c0a0610e6fa772e/gistfile1.txt
>
> Joonsoo, can you think of a way to take advantages of your approach,
> but make it work with inline instrumentation?
>
> Will it work if we map a single zero page for whole shadow initially,
> and then lazily map real shadow pages only for kernel memory, and then
> remap it again to zero pages when the whole KASAN_SHADOW_SCALE_SHIFT
> range of pages becomes unused (similarly to what you do in
> kasan_unmap_shadow())?


Just in case, I've uploaded a squashed version of this to codereview
site, if somebody will find it useful:
https://codereview.appspot.com/325780043
(side-by-side diffs is what you want)

Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption

[Dmitry Vyukov]

On Mon, May 15, 2017 at 9:34 PM, Dmitry Vyukov  wrote:
> On Mon, May 15, 2017 at 6:16 PM,   wrote:
>> From: Joonsoo Kim 
>>
>> Hello, all.
>>
>> This is an attempt to recude memory consumption of KASAN. Please see
>> following description to get the more information.
>>
>> 1. What is per-page shadow memory
>
> Hi Joonsoo,
>
> First I need to say that this is great work. I wanted KASAN to consume
> 1/8-th of _kernel_ memory rather than total physical memory for a long
> time.
>
> However, this implementation does not work inline instrumentation. And
> the inline instrumentation is the main mode for KASAN. Outline
> instrumentation is merely a rudiment to support gcc 4.9, and it needs
> to be removed as soon as we stop caring about gcc 4.9 (do we at all?
> is it the current compiler in any distro? Ubuntu 12 has 4.8, Ubuntu 14
> already has 5.4. And if you build gcc yourself or get a fresher
> compiler from somewhere else, you hopefully get something better than
> 4.9).
>
> Here is an example boot+scp log with inline instrumentation:
> https://gist.githubusercontent.com/dvyukov/dfdc8b6972ddd260b201a85d5d5cdb5d/raw/2a032cd5be371c7ad6cad8f14c0a0610e6fa772e/gistfile1.txt
>
> Joonsoo, can you think of a way to take advantages of your approach,
> but make it work with inline instrumentation?
>
> Will it work if we map a single zero page for whole shadow initially,
> and then lazily map real shadow pages only for kernel memory, and then
> remap it again to zero pages when the whole KASAN_SHADOW_SCALE_SHIFT
> range of pages becomes unused (similarly to what you do in
> kasan_unmap_shadow())?


Just in case, I've uploaded a squashed version of this to codereview
site, if somebody will find it useful:
https://codereview.appspot.com/325780043
(side-by-side diffs is what you want)

Re: frv build failure in mainline kernel

[Guenter Roeck]

On 05/15/2017 12:13 PM, Matthias Kaehlcke wrote:

El Mon, May 15, 2017 at 10:02:15AM -0700 Guenter Roeck ha dit:


Hi all,

frv fails to build in mainline with the following build errors.

kernel/built-in.o: In function `__do_softirq':
(.text+0x6460): relocation truncated to fit: R_FRV_GPREL12 against symbol
`jiffies' defined in *ABS* section in .tmp_vmlinux1
kernel/built-in.o: In function `__do_softirq':
(.text+0x6574): relocation truncated to fit: R_FRV_GPREL12 against symbol
`jiffies' defined in *ABS* section in .tmp_vmlinux1
kernel/built-in.o: In function `pwq_activate_delayed_work':
workqueue.c:(.text+0x15b9c): relocation truncated to fit: R_FRV_GPREL12 against
symbol `jiffies' defined in *ABS* section in .tmp_vmlinux1
kernel/built-in.o: In function `worker_enter_idle':
workqueue.c:(.text+0x1612c): relocation truncated to fit: R_FRV_GPREL12 against
symbol `jiffies' defined in *ABS* section in .tmp_vmlinux1
workqueue.c:(.text+0x161f0): relocation truncated to fit: R_FRV_GPREL12 against
symbol `jiffies' defined in *ABS* section in .tmp_vmlinux1
kernel/built-in.o: In function `pool_mayday_timeout':
workqueue.c:(.text+0x1630c): relocation truncated to fit: R_FRV_GPREL12 against
symbol `jiffies' defined in *ABS* section in .tmp_vmlinux1
kernel/built-in.o: In function `idle_worker_timeout':
workqueue.c:(.text+0x1649c): relocation truncated to fit: R_FRV_GPREL12 against
symbol `jiffies' defined in *ABS* section in .tmp_vmlinux1
workqueue.c:(.text+0x164f8): relocation truncated to fit: R_FRV_GPREL12 against
symbol `jiffies' defined in *ABS* section in .tmp_vmlinux1
kernel/built-in.o: In function `__queue_work':
workqueue.c:(.text+0x170f4): relocation truncated to fit: R_FRV_GPREL12 against
symbol `jiffies' defined in *ABS* section in .tmp_vmlinux1
kernel/built-in.o: In function `__queue_delayed_work':
workqueue.c:(.text+0x1745c): relocation truncated to fit: R_FRV_GPREL12 against
symbol `jiffies' defined in *ABS* section in .tmp_vmlinux1
kernel/built-in.o: In function `worker_thread':
workqueue.c:(.text+0x182e4): additional relocation overflows omitted from the 
output

Bisect points to commit 7c30f352c852 ("jiffies.h: declare jiffies and jiffies_64
with cacheline_aligned_in_smp"). Bisect log is attached.

Guenter

---
# bad: [2ea659a9ef488125eb46da6eb571de5eae5c43f6] Linux 4.12-rc1
# good: [13e0988140374123bead1dd27c287354cb95108e] docs: complete bumping 
minimal GNU Make version to 3.81
git bisect start 'HEAD' '13e098814037'
# bad: [c6778ff813d2ca3e3c8733c87dc8b6831a64578b] Merge tag 'armsoc-dt64' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect bad c6778ff813d2ca3e3c8733c87dc8b6831a64578b
# bad: [11fbf53d66ec302fe50b06bd7cb4863dbb98775a] Merge branch 'work.misc' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
git bisect bad 11fbf53d66ec302fe50b06bd7cb4863dbb98775a
# good: [2d3e4866dea96b0506395b47bfefb234f2088dac] Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/virt/kvm/kvm
git bisect good 2d3e4866dea96b0506395b47bfefb234f2088dac
# bad: [8f3207c7eab9d885cc64c778416537034a7d9c5b] Merge tag 'tty-4.12-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
git bisect bad 8f3207c7eab9d885cc64c778416537034a7d9c5b
# bad: [063246641d4a9e9de84a2466fbad50112faf88dc] format-security: move static 
strings to const
git bisect bad 063246641d4a9e9de84a2466fbad50112faf88dc
# bad: [f61e869d519c0c11a8d80a503cfdfb4897df855a] kcov: simplify interrupt check
git bisect bad f61e869d519c0c11a8d80a503cfdfb4897df855a
# bad: [0b523769ebb9473c60df1b0f70615aa82ebac2c9] checkpatch: add ability to find bad 
uses of vsprintf %p extensions
git bisect bad 0b523769ebb9473c60df1b0f70615aa82ebac2c9
# good: [3d88936f35bc67f7bee2efd4eec69baf26c17a5a] 
drivers/virt/fsl_hypervisor.c: use get_user_pages_unlocked()
git bisect good 3d88936f35bc67f7bee2efd4eec69baf26c17a5a
# bad: [8128a31eaadbcdfa37774bbd28f3f00bac69996a] 
drivers/misc/c2port/c2port-duramar2150.c: checking for NULL instead of IS_ERR()
git bisect bad 8128a31eaadbcdfa37774bbd28f3f00bac69996a
# bad: [31b8cc80776c1b5a17abda6e0bbb5c615b9d90e4] make help: add tools help 
target
git bisect bad 31b8cc80776c1b5a17abda6e0bbb5c615b9d90e4
# bad: [7c30f352c852bae2715ad65ac4a38ca9af7d7696] jiffies.h: declare jiffies 
and jiffies_64 with cacheline_aligned_in_smp
git bisect bad 7c30f352c852bae2715ad65ac4a38ca9af7d7696
# first bad commit: [7c30f352c852bae2715ad65ac4a38ca9af7d7696]
jiffies.h: declare jiffies and jiffies_64 with
cacheline_aligned_in_smp


This is apparently related with the removal of the __jiffy_data
'attribute' by this patch:

-/* some arch's have a small-data section that can be accessed register-relative
- * but that can only take up to, say, 4-byte variables. jiffies being part of
- * an 8-byte variable may not be correctly accessed unless we force the issue
- */
-#define __jiffy_data  __attribute__((section(".data")))



Guess now we know which architecture that referred to.



On frv the 'jiffies' symbol isn't 

Re: frv build failure in mainline kernel

[Guenter Roeck]

On 05/15/2017 12:13 PM, Matthias Kaehlcke wrote:

El Mon, May 15, 2017 at 10:02:15AM -0700 Guenter Roeck ha dit:


Hi all,

frv fails to build in mainline with the following build errors.

kernel/built-in.o: In function `__do_softirq':
(.text+0x6460): relocation truncated to fit: R_FRV_GPREL12 against symbol
`jiffies' defined in *ABS* section in .tmp_vmlinux1
kernel/built-in.o: In function `__do_softirq':
(.text+0x6574): relocation truncated to fit: R_FRV_GPREL12 against symbol
`jiffies' defined in *ABS* section in .tmp_vmlinux1
kernel/built-in.o: In function `pwq_activate_delayed_work':
workqueue.c:(.text+0x15b9c): relocation truncated to fit: R_FRV_GPREL12 against
symbol `jiffies' defined in *ABS* section in .tmp_vmlinux1
kernel/built-in.o: In function `worker_enter_idle':
workqueue.c:(.text+0x1612c): relocation truncated to fit: R_FRV_GPREL12 against
symbol `jiffies' defined in *ABS* section in .tmp_vmlinux1
workqueue.c:(.text+0x161f0): relocation truncated to fit: R_FRV_GPREL12 against
symbol `jiffies' defined in *ABS* section in .tmp_vmlinux1
kernel/built-in.o: In function `pool_mayday_timeout':
workqueue.c:(.text+0x1630c): relocation truncated to fit: R_FRV_GPREL12 against
symbol `jiffies' defined in *ABS* section in .tmp_vmlinux1
kernel/built-in.o: In function `idle_worker_timeout':
workqueue.c:(.text+0x1649c): relocation truncated to fit: R_FRV_GPREL12 against
symbol `jiffies' defined in *ABS* section in .tmp_vmlinux1
workqueue.c:(.text+0x164f8): relocation truncated to fit: R_FRV_GPREL12 against
symbol `jiffies' defined in *ABS* section in .tmp_vmlinux1
kernel/built-in.o: In function `__queue_work':
workqueue.c:(.text+0x170f4): relocation truncated to fit: R_FRV_GPREL12 against
symbol `jiffies' defined in *ABS* section in .tmp_vmlinux1
kernel/built-in.o: In function `__queue_delayed_work':
workqueue.c:(.text+0x1745c): relocation truncated to fit: R_FRV_GPREL12 against
symbol `jiffies' defined in *ABS* section in .tmp_vmlinux1
kernel/built-in.o: In function `worker_thread':
workqueue.c:(.text+0x182e4): additional relocation overflows omitted from the 
output

Bisect points to commit 7c30f352c852 ("jiffies.h: declare jiffies and jiffies_64
with cacheline_aligned_in_smp"). Bisect log is attached.

Guenter

---
# bad: [2ea659a9ef488125eb46da6eb571de5eae5c43f6] Linux 4.12-rc1
# good: [13e0988140374123bead1dd27c287354cb95108e] docs: complete bumping 
minimal GNU Make version to 3.81
git bisect start 'HEAD' '13e098814037'
# bad: [c6778ff813d2ca3e3c8733c87dc8b6831a64578b] Merge tag 'armsoc-dt64' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect bad c6778ff813d2ca3e3c8733c87dc8b6831a64578b
# bad: [11fbf53d66ec302fe50b06bd7cb4863dbb98775a] Merge branch 'work.misc' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
git bisect bad 11fbf53d66ec302fe50b06bd7cb4863dbb98775a
# good: [2d3e4866dea96b0506395b47bfefb234f2088dac] Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/virt/kvm/kvm
git bisect good 2d3e4866dea96b0506395b47bfefb234f2088dac
# bad: [8f3207c7eab9d885cc64c778416537034a7d9c5b] Merge tag 'tty-4.12-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
git bisect bad 8f3207c7eab9d885cc64c778416537034a7d9c5b
# bad: [063246641d4a9e9de84a2466fbad50112faf88dc] format-security: move static 
strings to const
git bisect bad 063246641d4a9e9de84a2466fbad50112faf88dc
# bad: [f61e869d519c0c11a8d80a503cfdfb4897df855a] kcov: simplify interrupt check
git bisect bad f61e869d519c0c11a8d80a503cfdfb4897df855a
# bad: [0b523769ebb9473c60df1b0f70615aa82ebac2c9] checkpatch: add ability to find bad 
uses of vsprintf %p extensions
git bisect bad 0b523769ebb9473c60df1b0f70615aa82ebac2c9
# good: [3d88936f35bc67f7bee2efd4eec69baf26c17a5a] 
drivers/virt/fsl_hypervisor.c: use get_user_pages_unlocked()
git bisect good 3d88936f35bc67f7bee2efd4eec69baf26c17a5a
# bad: [8128a31eaadbcdfa37774bbd28f3f00bac69996a] 
drivers/misc/c2port/c2port-duramar2150.c: checking for NULL instead of IS_ERR()
git bisect bad 8128a31eaadbcdfa37774bbd28f3f00bac69996a
# bad: [31b8cc80776c1b5a17abda6e0bbb5c615b9d90e4] make help: add tools help 
target
git bisect bad 31b8cc80776c1b5a17abda6e0bbb5c615b9d90e4
# bad: [7c30f352c852bae2715ad65ac4a38ca9af7d7696] jiffies.h: declare jiffies 
and jiffies_64 with cacheline_aligned_in_smp
git bisect bad 7c30f352c852bae2715ad65ac4a38ca9af7d7696
# first bad commit: [7c30f352c852bae2715ad65ac4a38ca9af7d7696]
jiffies.h: declare jiffies and jiffies_64 with
cacheline_aligned_in_smp


This is apparently related with the removal of the __jiffy_data
'attribute' by this patch:

-/* some arch's have a small-data section that can be accessed register-relative
- * but that can only take up to, say, 4-byte variables. jiffies being part of
- * an 8-byte variable may not be correctly accessed unless we force the issue
- */
-#define __jiffy_data  __attribute__((section(".data")))



Guess now we know which architecture that referred to.



On frv the 'jiffies' symbol isn't 

[PATCH] kbuild: skip header install/check for right under uapi directories

[Masahiro Yamada]

Since commit 61562f981e92 ("uapi: export all arch specifics
directories"), "make INSTALL_HDR_PATH=${root}/usr headers_install"
deletes standard glibc headers and others in ${root}/usr/include.

The cause of the issue is that headers_install now starts descending
from arch/$(hdr-arch)/include/uapi with ${root}/usr/include for its
destination when installing asm headers.  So, headers already there
are assumed to be unwanted.

When headers_install starts descending from include/uapi with
${root}/usr/include for its destination, it works around the problem
by creating an dummy destination ${root}/usr/include/uapi, but this
is tricky.

To fix the problem in a clean way is to skip header install/check in
include/uapi or arch/$(hdr-arch)/include/uapi.  A good side-effect
is the empty destination ${root}/usr/include/uapi will go away.

Fixes: 61562f981e92 ("uapi: export all arch specifics directories")
Reported-by: Dan Williams 
Signed-off-by: Masahiro Yamada 
---

 scripts/Makefile.headersinst | 43 +++
 1 file changed, 27 insertions(+), 16 deletions(-)

diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst
index 6ba97a1..ce753a4 100644
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
@@ -8,6 +8,29 @@
 #
 # ==
 
+PHONY := __headers
+__headers:
+
+include scripts/Kbuild.include
+
+srcdir:= $(srctree)/$(obj)
+subdirs   := $(patsubst $(srcdir)/%/.,%,$(wildcard $(srcdir)/*/.))
+# caller may set destination dir (when installing to asm/)
+_dst  := $(if $(dst),$(dst),$(obj))
+
+# Recursion
+__headers: $(subdirs)
+
+.PHONY: $(subdirs)
+$(subdirs):
+   $(Q)$(MAKE) $(hdr-inst)=$(obj)/$@ dst=$(_dst)/$@
+
+# Skip header install/check for include/uapi and arch/$(hdr-arch)/include/uapi.
+# We have only sub-directories there.
+skip-inst := $(if $(filter %/uapi,$(obj)),1)
+
+ifeq ($(skip-inst),)
+
 # generated header directory
 gen := $(if $(gen),$(gen),$(subst include/,include/generated/,$(obj)))
 
@@ -15,21 +38,14 @@ gen := $(if $(gen),$(gen),$(subst 
include/,include/generated/,$(obj)))
 kbuild-file := $(srctree)/$(obj)/Kbuild
 -include $(kbuild-file)
 
-# called may set destination dir (when installing to asm/)
-_dst := $(if $(dst),$(dst),$(obj))
-
 old-kbuild-file := $(srctree)/$(subst uapi/,,$(obj))/Kbuild
 ifneq ($(wildcard $(old-kbuild-file)),)
 include $(old-kbuild-file)
 endif
 
-include scripts/Kbuild.include
-
 installdir:= $(INSTALL_HDR_PATH)/$(subst uapi/,,$(_dst))
 
-srcdir:= $(srctree)/$(obj)
 gendir:= $(objtree)/$(gen)
-subdirs   := $(patsubst $(srcdir)/%/.,%,$(wildcard $(srcdir)/*/.))
 header-files  := $(notdir $(wildcard $(srcdir)/*.h))
 header-files  += $(notdir $(wildcard $(srcdir)/*.agh))
 header-files  := $(filter-out $(no-export-headers), $(header-files))
@@ -88,11 +104,9 @@ quiet_cmd_check = CHECK   $(printdir) ($(words 
$(all-files)) files)
   $(PERL) $< $(INSTALL_HDR_PATH)/include $(SRCARCH); \
  touch $@
 
-PHONY += __headersinst __headerscheck
-
 ifndef HDRCHECK
 # Rules for installing headers
-__headersinst: $(subdirs) $(install-file)
+__headers: $(install-file)
@:
 
 targets += $(install-file)
@@ -104,7 +118,7 @@ $(install-file): scripts/headers_install.sh \
$(call if_changed,install)
 
 else
-__headerscheck: $(subdirs) $(check-file)
+__headers: $(check-file)
@:
 
 targets += $(check-file)
@@ -113,11 +127,6 @@ $(check-file): scripts/headers_check.pl $(output-files) 
FORCE
 
 endif
 
-# Recursion
-.PHONY: $(subdirs)
-$(subdirs):
-   $(Q)$(MAKE) $(hdr-inst)=$(obj)/$@ dst=$(_dst)/$@
-
 targets := $(wildcard $(sort $(targets)))
 cmd_files := $(wildcard \
  $(foreach f,$(targets),$(dir $(f)).$(notdir $(f)).cmd))
@@ -126,6 +135,8 @@ ifneq ($(cmd_files),)
include $(cmd_files)
 endif
 
+endif # skip-inst
+
 .PHONY: $(PHONY)
 PHONY += FORCE
 FORCE: ;
-- 
2.7.4

[PATCH] kbuild: skip header install/check for right under uapi directories

[Masahiro Yamada]

Since commit 61562f981e92 ("uapi: export all arch specifics
directories"), "make INSTALL_HDR_PATH=${root}/usr headers_install"
deletes standard glibc headers and others in ${root}/usr/include.

The cause of the issue is that headers_install now starts descending
from arch/$(hdr-arch)/include/uapi with ${root}/usr/include for its
destination when installing asm headers.  So, headers already there
are assumed to be unwanted.

When headers_install starts descending from include/uapi with
${root}/usr/include for its destination, it works around the problem
by creating an dummy destination ${root}/usr/include/uapi, but this
is tricky.

To fix the problem in a clean way is to skip header install/check in
include/uapi or arch/$(hdr-arch)/include/uapi.  A good side-effect
is the empty destination ${root}/usr/include/uapi will go away.

Fixes: 61562f981e92 ("uapi: export all arch specifics directories")
Reported-by: Dan Williams 
Signed-off-by: Masahiro Yamada 
---

 scripts/Makefile.headersinst | 43 +++
 1 file changed, 27 insertions(+), 16 deletions(-)

diff --git a/scripts/Makefile.headersinst b/scripts/Makefile.headersinst
index 6ba97a1..ce753a4 100644
--- a/scripts/Makefile.headersinst
+++ b/scripts/Makefile.headersinst
@@ -8,6 +8,29 @@
 #
 # ==
 
+PHONY := __headers
+__headers:
+
+include scripts/Kbuild.include
+
+srcdir:= $(srctree)/$(obj)
+subdirs   := $(patsubst $(srcdir)/%/.,%,$(wildcard $(srcdir)/*/.))
+# caller may set destination dir (when installing to asm/)
+_dst  := $(if $(dst),$(dst),$(obj))
+
+# Recursion
+__headers: $(subdirs)
+
+.PHONY: $(subdirs)
+$(subdirs):
+   $(Q)$(MAKE) $(hdr-inst)=$(obj)/$@ dst=$(_dst)/$@
+
+# Skip header install/check for include/uapi and arch/$(hdr-arch)/include/uapi.
+# We have only sub-directories there.
+skip-inst := $(if $(filter %/uapi,$(obj)),1)
+
+ifeq ($(skip-inst),)
+
 # generated header directory
 gen := $(if $(gen),$(gen),$(subst include/,include/generated/,$(obj)))
 
@@ -15,21 +38,14 @@ gen := $(if $(gen),$(gen),$(subst 
include/,include/generated/,$(obj)))
 kbuild-file := $(srctree)/$(obj)/Kbuild
 -include $(kbuild-file)
 
-# called may set destination dir (when installing to asm/)
-_dst := $(if $(dst),$(dst),$(obj))
-
 old-kbuild-file := $(srctree)/$(subst uapi/,,$(obj))/Kbuild
 ifneq ($(wildcard $(old-kbuild-file)),)
 include $(old-kbuild-file)
 endif
 
-include scripts/Kbuild.include
-
 installdir:= $(INSTALL_HDR_PATH)/$(subst uapi/,,$(_dst))
 
-srcdir:= $(srctree)/$(obj)
 gendir:= $(objtree)/$(gen)
-subdirs   := $(patsubst $(srcdir)/%/.,%,$(wildcard $(srcdir)/*/.))
 header-files  := $(notdir $(wildcard $(srcdir)/*.h))
 header-files  += $(notdir $(wildcard $(srcdir)/*.agh))
 header-files  := $(filter-out $(no-export-headers), $(header-files))
@@ -88,11 +104,9 @@ quiet_cmd_check = CHECK   $(printdir) ($(words 
$(all-files)) files)
   $(PERL) $< $(INSTALL_HDR_PATH)/include $(SRCARCH); \
  touch $@
 
-PHONY += __headersinst __headerscheck
-
 ifndef HDRCHECK
 # Rules for installing headers
-__headersinst: $(subdirs) $(install-file)
+__headers: $(install-file)
@:
 
 targets += $(install-file)
@@ -104,7 +118,7 @@ $(install-file): scripts/headers_install.sh \
$(call if_changed,install)
 
 else
-__headerscheck: $(subdirs) $(check-file)
+__headers: $(check-file)
@:
 
 targets += $(check-file)
@@ -113,11 +127,6 @@ $(check-file): scripts/headers_check.pl $(output-files) 
FORCE
 
 endif
 
-# Recursion
-.PHONY: $(subdirs)
-$(subdirs):
-   $(Q)$(MAKE) $(hdr-inst)=$(obj)/$@ dst=$(_dst)/$@
-
 targets := $(wildcard $(sort $(targets)))
 cmd_files := $(wildcard \
  $(foreach f,$(targets),$(dir $(f)).$(notdir $(f)).cmd))
@@ -126,6 +135,8 @@ ifneq ($(cmd_files),)
include $(cmd_files)
 endif
 
+endif # skip-inst
+
 .PHONY: $(PHONY)
 PHONY += FORCE
 FORCE: ;
-- 
2.7.4

Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption

[Dmitry Vyukov]

On Mon, May 15, 2017 at 6:16 PM,   wrote:
> From: Joonsoo Kim 
>
> Hello, all.
>
> This is an attempt to recude memory consumption of KASAN. Please see
> following description to get the more information.
>
> 1. What is per-page shadow memory

Hi Joonsoo,

First I need to say that this is great work. I wanted KASAN to consume
1/8-th of _kernel_ memory rather than total physical memory for a long
time.

However, this implementation does not work inline instrumentation. And
the inline instrumentation is the main mode for KASAN. Outline
instrumentation is merely a rudiment to support gcc 4.9, and it needs
to be removed as soon as we stop caring about gcc 4.9 (do we at all?
is it the current compiler in any distro? Ubuntu 12 has 4.8, Ubuntu 14
already has 5.4. And if you build gcc yourself or get a fresher
compiler from somewhere else, you hopefully get something better than
4.9).

Here is an example boot+scp log with inline instrumentation:
https://gist.githubusercontent.com/dvyukov/dfdc8b6972ddd260b201a85d5d5cdb5d/raw/2a032cd5be371c7ad6cad8f14c0a0610e6fa772e/gistfile1.txt

Joonsoo, can you think of a way to take advantages of your approach,
but make it work with inline instrumentation?

Will it work if we map a single zero page for whole shadow initially,
and then lazily map real shadow pages only for kernel memory, and then
remap it again to zero pages when the whole KASAN_SHADOW_SCALE_SHIFT
range of pages becomes unused (similarly to what you do in
kasan_unmap_shadow())?





> This patch introduces infrastructure to support per-page shadow memory.
> Per-page shadow memory is the same with original shadow memory except
> the granualarity. It's one byte shows the shadow value for the page.
> The purpose of introducing this new shadow memory is to save memory
> consumption.
>
> 2. Problem of current approach
>
> Until now, KASAN needs shadow memory for all the range of the memory
> so the amount of statically allocated memory is so large. It causes
> the problem that KASAN cannot run on the system with hard memory
> constraint. Even if KASAN can run, large memory consumption due to
> KASAN changes behaviour of the workload so we cannot validate
> the moment that we want to check.
>
> 3. How does this patch fix the problem
>
> This patch tries to fix the problem by reducing memory consumption for
> the shadow memory. There are two observations.
>
> 1) Type of memory usage can be distinguished well.
> 2) Shadow memory is manipulated/checked in byte unit only for slab,
> kernel stack and global variable. Shadow memory for other usecases
> just show KASAN_FREE_PAGE or 0 (means valid) in page unit.
>
> With these two observations, I think an optimized way to support
> KASAN feature.
>
> 1) Introduces per-page shadow that cover all the memory
> 2) Checks validity of the access through per-page shadow except
> that checking object is a slab, kernel stack, global variable
> 3) For those byte accessible types of object, allocate/map original
> shadow by on-demand and checks validity of the access through
> original shadow
>
> Instead original shadow statically consumes 1/8 bytes of the amount of
> total memory, per-page shadow statically consumes 1/PAGE_SIZE bytes of it.
> Extra memory is required for a slab, kernel stack and global variable by
> on-demand in runtime, however, it would not be larger than before.
>
> 4. Result
>
> Following is the result of the memory consumption on my QEMU system.
> 'runtime' shows the maximum memory usage for on-demand shadow allocation
> during the kernel build workload.
>
> base vs patched
>
> MemTotal: 858 MB vs 987 MB
> runtime: 0 MB vs 30MB
> Net Available: 858 MB vs 957 MB
>
> For 4096 MB QEMU system
>
> MemTotal: 3477 MB vs 4000 MB
> runtime: 0 MB vs 50MB
>
> base vs patched (2048 MB QEMU system)
> 204 s vs 224 s
> Net Available: 3477 MB vs 3950 MB
>
> Thanks.
>
> Joonsoo Kim (11):
>   mm/kasan: rename XXX_is_zero to XXX_is_nonzero
>   mm/kasan: don't fetch the next shadow value speculartively
>   mm/kasan: handle unaligned end address in zero_pte_populate
>   mm/kasan: extend kasan_populate_zero_shadow()
>   mm/kasan: introduce per-page shadow memory infrastructure
>   mm/kasan: mark/unmark the target range that is for original shadow
> memory
>   x86/kasan: use per-page shadow memory
>   mm/kasan: support on-demand shadow allocation/mapping
>   x86/kasan: support on-demand shadow mapping
>   mm/kasan: support dynamic shadow memory free
>   mm/kasan: change the order of shadow memory check
>
>  arch/arm64/mm/kasan_init.c   |  17 +-
>  arch/x86/include/asm/kasan.h |   8 +
>  arch/x86/include/asm/processor.h |   4 +
>  arch/x86/kernel/cpu/common.c |   4 +-
>  arch/x86/kernel/setup_percpu.c   |   2 +
>  arch/x86/mm/kasan_init_64.c  | 191 --
>  include/linux/kasan.h|  71 -
>  kernel/fork.c|   7 +
>  mm/kasan/kasan.c | 555 
> 

Re: [PATCH v1 00/11] mm/kasan: support per-page shadow memory to reduce memory consumption

[Dmitry Vyukov]

On Mon, May 15, 2017 at 6:16 PM,   wrote:
> From: Joonsoo Kim 
>
> Hello, all.
>
> This is an attempt to recude memory consumption of KASAN. Please see
> following description to get the more information.
>
> 1. What is per-page shadow memory

Hi Joonsoo,

First I need to say that this is great work. I wanted KASAN to consume
1/8-th of _kernel_ memory rather than total physical memory for a long
time.

However, this implementation does not work inline instrumentation. And
the inline instrumentation is the main mode for KASAN. Outline
instrumentation is merely a rudiment to support gcc 4.9, and it needs
to be removed as soon as we stop caring about gcc 4.9 (do we at all?
is it the current compiler in any distro? Ubuntu 12 has 4.8, Ubuntu 14
already has 5.4. And if you build gcc yourself or get a fresher
compiler from somewhere else, you hopefully get something better than
4.9).

Here is an example boot+scp log with inline instrumentation:
https://gist.githubusercontent.com/dvyukov/dfdc8b6972ddd260b201a85d5d5cdb5d/raw/2a032cd5be371c7ad6cad8f14c0a0610e6fa772e/gistfile1.txt

Joonsoo, can you think of a way to take advantages of your approach,
but make it work with inline instrumentation?

Will it work if we map a single zero page for whole shadow initially,
and then lazily map real shadow pages only for kernel memory, and then
remap it again to zero pages when the whole KASAN_SHADOW_SCALE_SHIFT
range of pages becomes unused (similarly to what you do in
kasan_unmap_shadow())?





> This patch introduces infrastructure to support per-page shadow memory.
> Per-page shadow memory is the same with original shadow memory except
> the granualarity. It's one byte shows the shadow value for the page.
> The purpose of introducing this new shadow memory is to save memory
> consumption.
>
> 2. Problem of current approach
>
> Until now, KASAN needs shadow memory for all the range of the memory
> so the amount of statically allocated memory is so large. It causes
> the problem that KASAN cannot run on the system with hard memory
> constraint. Even if KASAN can run, large memory consumption due to
> KASAN changes behaviour of the workload so we cannot validate
> the moment that we want to check.
>
> 3. How does this patch fix the problem
>
> This patch tries to fix the problem by reducing memory consumption for
> the shadow memory. There are two observations.
>
> 1) Type of memory usage can be distinguished well.
> 2) Shadow memory is manipulated/checked in byte unit only for slab,
> kernel stack and global variable. Shadow memory for other usecases
> just show KASAN_FREE_PAGE or 0 (means valid) in page unit.
>
> With these two observations, I think an optimized way to support
> KASAN feature.
>
> 1) Introduces per-page shadow that cover all the memory
> 2) Checks validity of the access through per-page shadow except
> that checking object is a slab, kernel stack, global variable
> 3) For those byte accessible types of object, allocate/map original
> shadow by on-demand and checks validity of the access through
> original shadow
>
> Instead original shadow statically consumes 1/8 bytes of the amount of
> total memory, per-page shadow statically consumes 1/PAGE_SIZE bytes of it.
> Extra memory is required for a slab, kernel stack and global variable by
> on-demand in runtime, however, it would not be larger than before.
>
> 4. Result
>
> Following is the result of the memory consumption on my QEMU system.
> 'runtime' shows the maximum memory usage for on-demand shadow allocation
> during the kernel build workload.
>
> base vs patched
>
> MemTotal: 858 MB vs 987 MB
> runtime: 0 MB vs 30MB
> Net Available: 858 MB vs 957 MB
>
> For 4096 MB QEMU system
>
> MemTotal: 3477 MB vs 4000 MB
> runtime: 0 MB vs 50MB
>
> base vs patched (2048 MB QEMU system)
> 204 s vs 224 s
> Net Available: 3477 MB vs 3950 MB
>
> Thanks.
>
> Joonsoo Kim (11):
>   mm/kasan: rename XXX_is_zero to XXX_is_nonzero
>   mm/kasan: don't fetch the next shadow value speculartively
>   mm/kasan: handle unaligned end address in zero_pte_populate
>   mm/kasan: extend kasan_populate_zero_shadow()
>   mm/kasan: introduce per-page shadow memory infrastructure
>   mm/kasan: mark/unmark the target range that is for original shadow
> memory
>   x86/kasan: use per-page shadow memory
>   mm/kasan: support on-demand shadow allocation/mapping
>   x86/kasan: support on-demand shadow mapping
>   mm/kasan: support dynamic shadow memory free
>   mm/kasan: change the order of shadow memory check
>
>  arch/arm64/mm/kasan_init.c   |  17 +-
>  arch/x86/include/asm/kasan.h |   8 +
>  arch/x86/include/asm/processor.h |   4 +
>  arch/x86/kernel/cpu/common.c |   4 +-
>  arch/x86/kernel/setup_percpu.c   |   2 +
>  arch/x86/mm/kasan_init_64.c  | 191 --
>  include/linux/kasan.h|  71 -
>  kernel/fork.c|   7 +
>  mm/kasan/kasan.c | 555 
> +--
>  mm/kasan/kasan.h 

Re: [PATCH v8 0/4] Broadcom SBA RAID support

[Vinod Koul]

On Mon, May 15, 2017 at 10:34:51AM +0530, Anup Patel wrote:
> The Broadcom SBA RAID is a stream-based device which provides
> RAID5/6 offload.
> 
> It requires a SoC specific ring manager (such as Broadcom FlexRM
> ring manager) to provide ring-based programming interface. Due to
> this, the Broadcom SBA RAID driver (mailbox client) implements
> DMA device having one DMA channel using a set of mailbox channels
> provided by Broadcom SoC specific ring manager driver (mailbox
> controller).
> 
> The Broadcom SBA RAID hardware requires PQ disk position instead
> of PQ disk coefficient. To address this, we have added raid_gflog
> table which will help driver to convert PQ disk coefficient to PQ
> disk position.

Applied, now

-- 
~Vinod

Re: [PATCH v8 0/4] Broadcom SBA RAID support

[Vinod Koul]

On Mon, May 15, 2017 at 10:34:51AM +0530, Anup Patel wrote:
> The Broadcom SBA RAID is a stream-based device which provides
> RAID5/6 offload.
> 
> It requires a SoC specific ring manager (such as Broadcom FlexRM
> ring manager) to provide ring-based programming interface. Due to
> this, the Broadcom SBA RAID driver (mailbox client) implements
> DMA device having one DMA channel using a set of mailbox channels
> provided by Broadcom SoC specific ring manager driver (mailbox
> controller).
> 
> The Broadcom SBA RAID hardware requires PQ disk position instead
> of PQ disk coefficient. To address this, we have added raid_gflog
> table which will help driver to convert PQ disk coefficient to PQ
> disk position.

Applied, now

-- 
~Vinod

Re: [alsa-devel] [PATCH v2 2/2] dmaengine: dw: Remove AVR32 bits from the driver

[Vinod Koul]

On Mon, May 15, 2017 at 05:09:13PM +0200, Takashi Iwai wrote:
> On Mon, 15 May 2017 16:49:40 +0200,
> Vinod Koul wrote:
> > 
> > On Mon, May 15, 2017 at 11:43:11AM +0300, Andy Shevchenko wrote:
> > > On Sun, 2017-05-14 at 18:34 +0530, Vinod Koul wrote:
> > > > On Tue, May 09, 2017 at 07:18:37PM +0300, Andy Shevchenko wrote:
> > > > > AVR32 is gone. Now it's time to clean up the driver by removing
> > > > > leftovers that was used by AVR32 related code.
> > > > 
> > > > Since the cover didn't mention any dependency, I went ahead and
> > > > applied this
> > > > now
> > > > 
> > > 
> > > Sorry, I forgot to mention that it's supposed to go via either tree,
> > > though together. Since first we remove users of non-standard DMA
> > > callbacks.
> > 
> > Okay dropped it, anyway the kbuild complained due to dependency
> > 
> > SO if you want this to be merged thru sound tree:
> > 
> > Acked-by: Vinod Koul 
> 
> OK, I merged two patches in topic/avr32-removal branch.  It's based on
> 4.12-rc1, so it should be mergeable to your tree cleanly.

Thanks Takashi,

I have pulled and this is also in dmaengine-next now

-- 
~Vinod

Re: [alsa-devel] [PATCH v2 2/2] dmaengine: dw: Remove AVR32 bits from the driver

[Vinod Koul]

On Mon, May 15, 2017 at 05:09:13PM +0200, Takashi Iwai wrote:
> On Mon, 15 May 2017 16:49:40 +0200,
> Vinod Koul wrote:
> > 
> > On Mon, May 15, 2017 at 11:43:11AM +0300, Andy Shevchenko wrote:
> > > On Sun, 2017-05-14 at 18:34 +0530, Vinod Koul wrote:
> > > > On Tue, May 09, 2017 at 07:18:37PM +0300, Andy Shevchenko wrote:
> > > > > AVR32 is gone. Now it's time to clean up the driver by removing
> > > > > leftovers that was used by AVR32 related code.
> > > > 
> > > > Since the cover didn't mention any dependency, I went ahead and
> > > > applied this
> > > > now
> > > > 
> > > 
> > > Sorry, I forgot to mention that it's supposed to go via either tree,
> > > though together. Since first we remove users of non-standard DMA
> > > callbacks.
> > 
> > Okay dropped it, anyway the kbuild complained due to dependency
> > 
> > SO if you want this to be merged thru sound tree:
> > 
> > Acked-by: Vinod Koul 
> 
> OK, I merged two patches in topic/avr32-removal branch.  It's based on
> 4.12-rc1, so it should be mergeable to your tree cleanly.

Thanks Takashi,

I have pulled and this is also in dmaengine-next now

-- 
~Vinod

[4.12 regression] "cpufreq: intel_pstate: Active mode P-state limits rework"

[허종만]

 
Hi,
 
With 4.12-rc1 (Linus git), booting fails due to kernel panic, at 
intel_pstate_register_driver+0x56/0x110.
I can't copy the whole trace from the graphic console, it looks like below.
 
Call Trace:
  intel_pstate_init
  intel_pstate_setup
  do_one_initcall
  set_debug_rodata
  kernel_init_freeable
  rest_init
  kernel_init
  ret_from_fork
    Code: ...
  RIP: intel_pstate_register_driver+0x56/0x110 RSP: a3a98000bd80
  ...
 
git bisect points to c5a2ee7d (cpufreq: intel_pstate: Active mode P-state 
limits rework) as first bad commit.
But I can't revert the single commit due to dependency.
 
FYI, this is Fedora 25 Linux guest, running on VMWare workstation 12 (Host is 
Windows 7).
CPU is Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz.
If you need more information, plz let me know.
 
Here is bisect log and my .config.


[root@localhost linux]# git bisect log
# bad: [13e0988140374123bead1dd27c287354cb95108e] docs: complete bumping 
minimal GNU Make version to 3.81
# good: [a351e9b9fc24e982ec2f0e76379a49826036da12] Linux 4.11
git bisect start '13e0988140374' 'v4.11'
# bad: [a3719f34fdb664ffcfaec2160ef20fca7becf2ee] Merge branch 'generic' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs
git bisect bad a3719f34fdb664ffcfaec2160ef20fca7becf2ee
# good: [5d15af6778b8e4ed1fd41b040283af278e7a9a72] Merge branch 
'tipc-refactor-socket-receive-functions'
git bisect good 5d15af6778b8e4ed1fd41b040283af278e7a9a72
# bad: [7c8c03bfc7b9f5211d8a69eab7fee99c9fb4f449] Merge branch 
'perf-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 7c8c03bfc7b9f5211d8a69eab7fee99c9fb4f449
# bad: [08be881064da126b8df4b96b0b3e2e307969a4a1] Merge tag 'acpi-4.12-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect bad 08be881064da126b8df4b96b0b3e2e307969a4a1
# good: [a44f53faf4674d84cba79f7ee574584e18ab8744] lightnvm: pblk: fix erase 
counters on error fail
git bisect good a44f53faf4674d84cba79f7ee574584e18ab8744
# good: [5c6ba7d53274b5e8b13ecbc727d8eb1ea4a2bcdc] Merge tag 'hsi-for-4.12' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi
git bisect good 5c6ba7d53274b5e8b13ecbc727d8eb1ea4a2bcdc
# bad: [a1d2fcfd80bef6cdc5675dcabe25587010720bdb] Merge branch 'pm-tools'
git bisect bad a1d2fcfd80bef6cdc5675dcabe25587010720bdb
# bad: [2dee4b0e0b83c9d045d6cfe168d6798ead3fe33c] Merge intel_pstate driver 
updates for v4.12.
git bisect bad 2dee4b0e0b83c9d045d6cfe168d6798ead3fe33c
# bad: [67dd9bf4416305811d58280dbe108d78ab573d56] cpufreq: intel_pstate: Add 
update_util callback to pstate_funcs
git bisect bad 67dd9bf4416305811d58280dbe108d78ab573d56
# bad: [6404367862bb25730e373cb9d443757b76f6abcc] cpufreq: intel_pstate: Drop 
pointless initialization of PID parameters
git bisect bad 6404367862bb25730e373cb9d443757b76f6abcc
# good: [553953453b4b64fbccba31691257d006cee36613] cpufreq: intel_pstate: Use 
load-based P-state selection more widely
git bisect good 553953453b4b64fbccba31691257d006cee36613
# bad: [80b120ca1a75c2df093d15936ab0591d90c99de9] cpufreq: intel_pstate: Avoid 
transient updates of cpuinfo.max_freq
git bisect bad 80b120ca1a75c2df093d15936ab0591d90c99de9
# bad: [c5a2ee7dde893e0a06044e75c16711f08d5c011d] cpufreq: intel_pstate: Active 
mode P-state limits rework
git bisect bad c5a2ee7dde893e0a06044e75c16711f08d5c011d
# first bad commit: [c5a2ee7dde893e0a06044e75c16711f08d5c011d] cpufreq: 
intel_pstate: Active mode P-state limits rework
 

#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.11.0-rc2 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y

[4.12 regression] "cpufreq: intel_pstate: Active mode P-state limits rework"

[허종만]

 
Hi,
 
With 4.12-rc1 (Linus git), booting fails due to kernel panic, at 
intel_pstate_register_driver+0x56/0x110.
I can't copy the whole trace from the graphic console, it looks like below.
 
Call Trace:
  intel_pstate_init
  intel_pstate_setup
  do_one_initcall
  set_debug_rodata
  kernel_init_freeable
  rest_init
  kernel_init
  ret_from_fork
    Code: ...
  RIP: intel_pstate_register_driver+0x56/0x110 RSP: a3a98000bd80
  ...
 
git bisect points to c5a2ee7d (cpufreq: intel_pstate: Active mode P-state 
limits rework) as first bad commit.
But I can't revert the single commit due to dependency.
 
FYI, this is Fedora 25 Linux guest, running on VMWare workstation 12 (Host is 
Windows 7).
CPU is Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz.
If you need more information, plz let me know.
 
Here is bisect log and my .config.


[root@localhost linux]# git bisect log
# bad: [13e0988140374123bead1dd27c287354cb95108e] docs: complete bumping 
minimal GNU Make version to 3.81
# good: [a351e9b9fc24e982ec2f0e76379a49826036da12] Linux 4.11
git bisect start '13e0988140374' 'v4.11'
# bad: [a3719f34fdb664ffcfaec2160ef20fca7becf2ee] Merge branch 'generic' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs
git bisect bad a3719f34fdb664ffcfaec2160ef20fca7becf2ee
# good: [5d15af6778b8e4ed1fd41b040283af278e7a9a72] Merge branch 
'tipc-refactor-socket-receive-functions'
git bisect good 5d15af6778b8e4ed1fd41b040283af278e7a9a72
# bad: [7c8c03bfc7b9f5211d8a69eab7fee99c9fb4f449] Merge branch 
'perf-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 7c8c03bfc7b9f5211d8a69eab7fee99c9fb4f449
# bad: [08be881064da126b8df4b96b0b3e2e307969a4a1] Merge tag 'acpi-4.12-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect bad 08be881064da126b8df4b96b0b3e2e307969a4a1
# good: [a44f53faf4674d84cba79f7ee574584e18ab8744] lightnvm: pblk: fix erase 
counters on error fail
git bisect good a44f53faf4674d84cba79f7ee574584e18ab8744
# good: [5c6ba7d53274b5e8b13ecbc727d8eb1ea4a2bcdc] Merge tag 'hsi-for-4.12' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi
git bisect good 5c6ba7d53274b5e8b13ecbc727d8eb1ea4a2bcdc
# bad: [a1d2fcfd80bef6cdc5675dcabe25587010720bdb] Merge branch 'pm-tools'
git bisect bad a1d2fcfd80bef6cdc5675dcabe25587010720bdb
# bad: [2dee4b0e0b83c9d045d6cfe168d6798ead3fe33c] Merge intel_pstate driver 
updates for v4.12.
git bisect bad 2dee4b0e0b83c9d045d6cfe168d6798ead3fe33c
# bad: [67dd9bf4416305811d58280dbe108d78ab573d56] cpufreq: intel_pstate: Add 
update_util callback to pstate_funcs
git bisect bad 67dd9bf4416305811d58280dbe108d78ab573d56
# bad: [6404367862bb25730e373cb9d443757b76f6abcc] cpufreq: intel_pstate: Drop 
pointless initialization of PID parameters
git bisect bad 6404367862bb25730e373cb9d443757b76f6abcc
# good: [553953453b4b64fbccba31691257d006cee36613] cpufreq: intel_pstate: Use 
load-based P-state selection more widely
git bisect good 553953453b4b64fbccba31691257d006cee36613
# bad: [80b120ca1a75c2df093d15936ab0591d90c99de9] cpufreq: intel_pstate: Avoid 
transient updates of cpuinfo.max_freq
git bisect bad 80b120ca1a75c2df093d15936ab0591d90c99de9
# bad: [c5a2ee7dde893e0a06044e75c16711f08d5c011d] cpufreq: intel_pstate: Active 
mode P-state limits rework
git bisect bad c5a2ee7dde893e0a06044e75c16711f08d5c011d
# first bad commit: [c5a2ee7dde893e0a06044e75c16711f08d5c011d] cpufreq: 
intel_pstate: Active mode P-state limits rework
 

#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.11.0-rc2 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y

Re: [PATCH 8/8] waitid(): switch copyout of siginfo to unsafe_put_user()

[kbuild test robot]

Hi Al,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.12-rc1 next-20170515]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Al-Viro/move-compat-wait4-and-waitid-next-to-native-variants/20170516-084127
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All warnings (new ones prefixed by >>):

   In file included from include/asm-generic/bug.h:4:0,
from arch/arm64/include/asm/bug.h:66,
from include/linux/bug.h:4,
from include/linux/mmdebug.h:4,
from include/linux/mm.h:8,
from kernel/exit.c:7:
   kernel/exit.c: In function 'C_SYSC_waitid':
   kernel/exit.c:1746:38: error: 'infop' undeclared (first use in this function)
 unsafe_put_user(err ? 0 : SIGCHLD, >si_signo, Efault);
 ^
   include/linux/compiler.h:179:42: note: in definition of macro 'unlikely'
# define unlikely(x) __builtin_expect(!!(x), 0)
 ^
>> arch/arm64/include/asm/uaccess.h:313:2: note: in expansion of macro 
>> '__put_user_err'
 __put_user_err((x), (ptr), __pu_err);\
 ^~
   include/linux/uaccess.h:302:56: note: in expansion of macro '__put_user'
#define unsafe_put_user(x, ptr, err) do { if (unlikely(__put_user(x, ptr))) 
goto err; } while (0)
   ^~
   kernel/exit.c:1746:2: note: in expansion of macro 'unsafe_put_user'
 unsafe_put_user(err ? 0 : SIGCHLD, >si_signo, Efault);
 ^~~
   kernel/exit.c:1746:38: note: each undeclared identifier is reported only 
once for each function it appears in
 unsafe_put_user(err ? 0 : SIGCHLD, >si_signo, Efault);
 ^
   include/linux/compiler.h:179:42: note: in definition of macro 'unlikely'
# define unlikely(x) __builtin_expect(!!(x), 0)
 ^
>> arch/arm64/include/asm/uaccess.h:313:2: note: in expansion of macro 
>> '__put_user_err'
 __put_user_err((x), (ptr), __pu_err);\
 ^~
   include/linux/uaccess.h:302:56: note: in expansion of macro '__put_user'
#define unsafe_put_user(x, ptr, err) do { if (unlikely(__put_user(x, ptr))) 
goto err; } while (0)
   ^~
   kernel/exit.c:1746:2: note: in expansion of macro 'unsafe_put_user'
 unsafe_put_user(err ? 0 : SIGCHLD, >si_signo, Efault);
 ^~~

vim +/__put_user_err +313 arch/arm64/include/asm/uaccess.h

57f4959b James Morse 2016-02-05  297__put_user_asm("str", 
"sttr", "%w", __pu_val, (ptr),\
57f4959b James Morse 2016-02-05  298   (err), 
ARM64_HAS_UAO);   \
0aea86a2 Catalin Marinas 2012-03-05  299break;  
\
0aea86a2 Catalin Marinas 2012-03-05  300case 8: 
\
d135b8b5 Mark Rutland2017-05-03  301__put_user_asm("str", 
"sttr", "%x", __pu_val, (ptr),\
57f4959b James Morse 2016-02-05  302   (err), 
ARM64_HAS_UAO);   \
0aea86a2 Catalin Marinas 2012-03-05  303break;  
\
0aea86a2 Catalin Marinas 2012-03-05  304default:
\
0aea86a2 Catalin Marinas 2012-03-05  305BUILD_BUG();
\
0aea86a2 Catalin Marinas 2012-03-05  306}   
\
bd38967d Catalin Marinas 2016-07-01  307uaccess_disable_not_uao();  
\
0aea86a2 Catalin Marinas 2012-03-05  308  } while (0)
0aea86a2 Catalin Marinas 2012-03-05  309  
0aea86a2 Catalin Marinas 2012-03-05  310  #define __put_user(x, ptr)
\
0aea86a2 Catalin Marinas 2012-03-05  311  ({
\
0aea86a2 Catalin Marinas 2012-03-05  312int __pu_err = 0;   
\
0aea86a2 Catalin Marinas 2012-03-05 @313__put_user_err((x), (ptr), 
__pu_err);   \
0aea86a2 Catalin Marinas 2012-03-05  314__pu_err; 

Re: [PATCH 8/8] waitid(): switch copyout of siginfo to unsafe_put_user()

[kbuild test robot]

Hi Al,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.12-rc1 next-20170515]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Al-Viro/move-compat-wait4-and-waitid-next-to-native-variants/20170516-084127
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All warnings (new ones prefixed by >>):

   In file included from include/asm-generic/bug.h:4:0,
from arch/arm64/include/asm/bug.h:66,
from include/linux/bug.h:4,
from include/linux/mmdebug.h:4,
from include/linux/mm.h:8,
from kernel/exit.c:7:
   kernel/exit.c: In function 'C_SYSC_waitid':
   kernel/exit.c:1746:38: error: 'infop' undeclared (first use in this function)
 unsafe_put_user(err ? 0 : SIGCHLD, >si_signo, Efault);
 ^
   include/linux/compiler.h:179:42: note: in definition of macro 'unlikely'
# define unlikely(x) __builtin_expect(!!(x), 0)
 ^
>> arch/arm64/include/asm/uaccess.h:313:2: note: in expansion of macro 
>> '__put_user_err'
 __put_user_err((x), (ptr), __pu_err);\
 ^~
   include/linux/uaccess.h:302:56: note: in expansion of macro '__put_user'
#define unsafe_put_user(x, ptr, err) do { if (unlikely(__put_user(x, ptr))) 
goto err; } while (0)
   ^~
   kernel/exit.c:1746:2: note: in expansion of macro 'unsafe_put_user'
 unsafe_put_user(err ? 0 : SIGCHLD, >si_signo, Efault);
 ^~~
   kernel/exit.c:1746:38: note: each undeclared identifier is reported only 
once for each function it appears in
 unsafe_put_user(err ? 0 : SIGCHLD, >si_signo, Efault);
 ^
   include/linux/compiler.h:179:42: note: in definition of macro 'unlikely'
# define unlikely(x) __builtin_expect(!!(x), 0)
 ^
>> arch/arm64/include/asm/uaccess.h:313:2: note: in expansion of macro 
>> '__put_user_err'
 __put_user_err((x), (ptr), __pu_err);\
 ^~
   include/linux/uaccess.h:302:56: note: in expansion of macro '__put_user'
#define unsafe_put_user(x, ptr, err) do { if (unlikely(__put_user(x, ptr))) 
goto err; } while (0)
   ^~
   kernel/exit.c:1746:2: note: in expansion of macro 'unsafe_put_user'
 unsafe_put_user(err ? 0 : SIGCHLD, >si_signo, Efault);
 ^~~

vim +/__put_user_err +313 arch/arm64/include/asm/uaccess.h

57f4959b James Morse 2016-02-05  297__put_user_asm("str", 
"sttr", "%w", __pu_val, (ptr),\
57f4959b James Morse 2016-02-05  298   (err), 
ARM64_HAS_UAO);   \
0aea86a2 Catalin Marinas 2012-03-05  299break;  
\
0aea86a2 Catalin Marinas 2012-03-05  300case 8: 
\
d135b8b5 Mark Rutland2017-05-03  301__put_user_asm("str", 
"sttr", "%x", __pu_val, (ptr),\
57f4959b James Morse 2016-02-05  302   (err), 
ARM64_HAS_UAO);   \
0aea86a2 Catalin Marinas 2012-03-05  303break;  
\
0aea86a2 Catalin Marinas 2012-03-05  304default:
\
0aea86a2 Catalin Marinas 2012-03-05  305BUILD_BUG();
\
0aea86a2 Catalin Marinas 2012-03-05  306}   
\
bd38967d Catalin Marinas 2016-07-01  307uaccess_disable_not_uao();  
\
0aea86a2 Catalin Marinas 2012-03-05  308  } while (0)
0aea86a2 Catalin Marinas 2012-03-05  309  
0aea86a2 Catalin Marinas 2012-03-05  310  #define __put_user(x, ptr)
\
0aea86a2 Catalin Marinas 2012-03-05  311  ({
\
0aea86a2 Catalin Marinas 2012-03-05  312int __pu_err = 0;   
\
0aea86a2 Catalin Marinas 2012-03-05 @313__put_user_err((x), (ptr), 
__pu_err);   \
0aea86a2 Catalin Marinas 2012-03-05  314__pu_err; 

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

[Matt Brown]

On 05/15/2017 07:10 PM, Peter Dolding wrote:

On Tue, May 16, 2017 at 6:57 AM, Alan Cox  wrote:

O> I'm not implying that my patch is supposed to provide safety for

"hundreds of other" issues. I'm looking to provide a way to lock down a
single TTY ioctl that has caused real security issues to arise. For


In other words you are not actually fixing anything.


this reason, it's completely incorrect to say that this feature is
snake oil. My patch does exactly what it claims to do. No more no less.


In addition your change to allow it to be used by root in the guest
completely invalidates any protection you have because I can push

"rm -rf /\n"

as root in my namespace and exit

The tty buffers are not flushed across the context change so the shell
you return to gets the input and oh dear


This is precisely what my patch prevents! With my protection enabled, a
container will only be able to use the TIOCSTI ioctl on a tty if that
container has CAP_SYS_ADMIN in the user namespace in which the tty was
created.


Which is not necessarily the namespace of the process that next issues a
read().

This is snake oil. There is a correct and proper process for this use
case. That proper process is to create a new pty/tty pair. There are two
cases

- processes that do it right in which case the attacker is screwed and we
  don't need to mess up TIOCSTI handling for no reason.

- processes that do it wrong. If they do it wrong then they'll also use
  all the other holes and attacks available via the same path which are
  completely unfixable without making your system basically unusable.


So can we please apply the minimum of common sense reasoning to this and
drop the patch.

Alan

You missed some important.

From: http://man7.org/linux/man-pages/man7/capabilities.7.html
Don't choose CAP_SYS_ADMIN if you can possibly avoid it!
A vast  proportion of existing capability checks are associated with this
capability (see the partial list above).  It can plausibly be
called "the new root", since on the one hand, it confers a wide
range of powers, and on the other hand, its broad scope means that
 this is the capability that is required by many privileged
programs.  Don't make the problem worse.  The only new features
that should be associated with CAP_SYS_ADMIN are ones that closely
match existing uses in that silo.



That last sentence is the key. CAP_SYS_ADMIN is already associated with
the TIOCSTI ioctl!

From the same capabilities man page you quote above
under the CAP_SYS_ADMIN section:
employ the TIOCSTI ioctl(2) to insert characters into the input queue
of a terminal other than the caller's controlling terminal;


This not only a improper fix the attempted fix is breach do
documentation.   CAP_SYS_ADMIN is that far overloaded it does not
require any more thrown in it direction.



See my comment above. This is clearly following the capabilities
documentation since CAP_SYS_ADMIN is already closely linked with the
TIOCSTI ioctl.


This is one of the grsecurity patches mistakes.   GRKERNSEC_HARDEN_TTY
 is from 18 Feb 2016 this documentation as in place at the time they
wrote this.  Yes GRKERNSEC_HARDEN_TTY does exactly the same thing.
Yes Grsecurity guys did the same error and the grsecurity patches are
filled with this error.

The result is from the TIOCSTI patch done this way is you have to use
CAP_SYS_ADMIN to use TIOSCTI so opening up every exploit that
Grsecurity has added and every exploit CAP_SYS_ADMIN can do what is
quite a few.

Now I don't know if CAP_SYS_TTY_CONFIG what is an existing capability
might be what TIOCSTI should own under.



I could see a case being make for CAP_SYS_TTY_CONFIG. However I still
choose to do with CAP_SYS_ADMIN because it is already in use in the
TIOCSTI ioctl.


The reality here is CAP_SYS_ADMIN as become the Linux kernel security
equal what big kernel lock was for multi threading.

 In a ideal world CAP_SYS_ADMIN would not be used directly in most
cases.  Instead CAP_SYS_ADMIN would have a stack of sub capabilities
groups under it.

The excuse for doing it wrong grsecurity is
https://forums.grsecurity.net/viewtopic.php?f=7=2522

Yes most capabilities open up possibility of exploiting the system.
They are not in fact designed to prevent this.   They are designed to
limit the damage in case of malfunction so that a program/user has
only limited methods of damaging the system.  Like a program
malfunctioning with only limit capabilities if it does an action those
capabilities don't allow no damage will happen.   Now CAP_SYS_ADMIN is
for sure not limited.

But since grsecurity developers took the point of view these are False
Boundaries they then proceed to stack item after item under
CAP_SYS_ADMIN because the boundary made no sense to them.Also some
mainline Linux Kernel developers are guilty of the same sin of
overloading CAP_SYS_ADMIN.

From my point of view any new patching containing CAP_SYS_ADMIN
directly used should be bounced just for 

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

[Matt Brown]

On 05/15/2017 07:10 PM, Peter Dolding wrote:

On Tue, May 16, 2017 at 6:57 AM, Alan Cox  wrote:

O> I'm not implying that my patch is supposed to provide safety for

"hundreds of other" issues. I'm looking to provide a way to lock down a
single TTY ioctl that has caused real security issues to arise. For


In other words you are not actually fixing anything.


this reason, it's completely incorrect to say that this feature is
snake oil. My patch does exactly what it claims to do. No more no less.


In addition your change to allow it to be used by root in the guest
completely invalidates any protection you have because I can push

"rm -rf /\n"

as root in my namespace and exit

The tty buffers are not flushed across the context change so the shell
you return to gets the input and oh dear


This is precisely what my patch prevents! With my protection enabled, a
container will only be able to use the TIOCSTI ioctl on a tty if that
container has CAP_SYS_ADMIN in the user namespace in which the tty was
created.


Which is not necessarily the namespace of the process that next issues a
read().

This is snake oil. There is a correct and proper process for this use
case. That proper process is to create a new pty/tty pair. There are two
cases

- processes that do it right in which case the attacker is screwed and we
  don't need to mess up TIOCSTI handling for no reason.

- processes that do it wrong. If they do it wrong then they'll also use
  all the other holes and attacks available via the same path which are
  completely unfixable without making your system basically unusable.


So can we please apply the minimum of common sense reasoning to this and
drop the patch.

Alan

You missed some important.

From: http://man7.org/linux/man-pages/man7/capabilities.7.html
Don't choose CAP_SYS_ADMIN if you can possibly avoid it!
A vast  proportion of existing capability checks are associated with this
capability (see the partial list above).  It can plausibly be
called "the new root", since on the one hand, it confers a wide
range of powers, and on the other hand, its broad scope means that
 this is the capability that is required by many privileged
programs.  Don't make the problem worse.  The only new features
that should be associated with CAP_SYS_ADMIN are ones that closely
match existing uses in that silo.



That last sentence is the key. CAP_SYS_ADMIN is already associated with
the TIOCSTI ioctl!

From the same capabilities man page you quote above
under the CAP_SYS_ADMIN section:
employ the TIOCSTI ioctl(2) to insert characters into the input queue
of a terminal other than the caller's controlling terminal;


This not only a improper fix the attempted fix is breach do
documentation.   CAP_SYS_ADMIN is that far overloaded it does not
require any more thrown in it direction.



See my comment above. This is clearly following the capabilities
documentation since CAP_SYS_ADMIN is already closely linked with the
TIOCSTI ioctl.


This is one of the grsecurity patches mistakes.   GRKERNSEC_HARDEN_TTY
 is from 18 Feb 2016 this documentation as in place at the time they
wrote this.  Yes GRKERNSEC_HARDEN_TTY does exactly the same thing.
Yes Grsecurity guys did the same error and the grsecurity patches are
filled with this error.

The result is from the TIOCSTI patch done this way is you have to use
CAP_SYS_ADMIN to use TIOSCTI so opening up every exploit that
Grsecurity has added and every exploit CAP_SYS_ADMIN can do what is
quite a few.

Now I don't know if CAP_SYS_TTY_CONFIG what is an existing capability
might be what TIOCSTI should own under.



I could see a case being make for CAP_SYS_TTY_CONFIG. However I still
choose to do with CAP_SYS_ADMIN because it is already in use in the
TIOCSTI ioctl.


The reality here is CAP_SYS_ADMIN as become the Linux kernel security
equal what big kernel lock was for multi threading.

 In a ideal world CAP_SYS_ADMIN would not be used directly in most
cases.  Instead CAP_SYS_ADMIN would have a stack of sub capabilities
groups under it.

The excuse for doing it wrong grsecurity is
https://forums.grsecurity.net/viewtopic.php?f=7=2522

Yes most capabilities open up possibility of exploiting the system.
They are not in fact designed to prevent this.   They are designed to
limit the damage in case of malfunction so that a program/user has
only limited methods of damaging the system.  Like a program
malfunctioning with only limit capabilities if it does an action those
capabilities don't allow no damage will happen.   Now CAP_SYS_ADMIN is
for sure not limited.

But since grsecurity developers took the point of view these are False
Boundaries they then proceed to stack item after item under
CAP_SYS_ADMIN because the boundary made no sense to them.Also some
mainline Linux Kernel developers are guilty of the same sin of
overloading CAP_SYS_ADMIN.

From my point of view any new patching containing CAP_SYS_ADMIN
directly used should be bounced just for that.   If features need to
be 

Re: [PATCH 8/8] waitid(): switch copyout of siginfo to unsafe_put_user()

[kbuild test robot]

Hi Al,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.12-rc1 next-20170515]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Al-Viro/move-compat-wait4-and-waitid-next-to-native-variants/20170516-084127
config: powerpc-allmodconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

All warnings (new ones prefixed by >>):

   In file included from include/asm-generic/bug.h:4:0,
from arch/powerpc/include/asm/bug.h:127,
from include/linux/bug.h:4,
from include/linux/mmdebug.h:4,
from include/linux/mm.h:8,
from kernel/exit.c:7:
   kernel/exit.c: In function 'C_SYSC_waitid':
   kernel/exit.c:1746:38: error: 'infop' undeclared (first use in this function)
 unsafe_put_user(err ? 0 : SIGCHLD, >si_signo, Efault);
 ^
   include/linux/compiler.h:179:42: note: in definition of macro 'unlikely'
# define unlikely(x) __builtin_expect(!!(x), 0)
 ^
>> arch/powerpc/include/asm/uaccess.h:86:2: note: in expansion of macro 
>> '__put_user_nocheck'
 __put_user_nocheck((__typeof__(*(ptr)))(x), (ptr), sizeof(*(ptr)))
 ^~
   include/linux/uaccess.h:302:56: note: in expansion of macro '__put_user'
#define unsafe_put_user(x, ptr, err) do { if (unlikely(__put_user(x, ptr))) 
goto err; } while (0)
   ^~
   kernel/exit.c:1746:2: note: in expansion of macro 'unsafe_put_user'
 unsafe_put_user(err ? 0 : SIGCHLD, >si_signo, Efault);
 ^~~
   kernel/exit.c:1746:38: note: each undeclared identifier is reported only 
once for each function it appears in
 unsafe_put_user(err ? 0 : SIGCHLD, >si_signo, Efault);
 ^
   include/linux/compiler.h:179:42: note: in definition of macro 'unlikely'
# define unlikely(x) __builtin_expect(!!(x), 0)
 ^
>> arch/powerpc/include/asm/uaccess.h:86:2: note: in expansion of macro 
>> '__put_user_nocheck'
 __put_user_nocheck((__typeof__(*(ptr)))(x), (ptr), sizeof(*(ptr)))
 ^~
   include/linux/uaccess.h:302:56: note: in expansion of macro '__put_user'
#define unsafe_put_user(x, ptr, err) do { if (unlikely(__put_user(x, ptr))) 
goto err; } while (0)
   ^~
   kernel/exit.c:1746:2: note: in expansion of macro 'unsafe_put_user'
 unsafe_put_user(err ? 0 : SIGCHLD, >si_signo, Efault);
 ^~~

vim +/__put_user_nocheck +86 arch/powerpc/include/asm/uaccess.h

2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  70   
* with a separate "access_ok()" call (this is used when we do multiple
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  71   
* accesses to the same area of user memory).
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  72   *
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  73   
* As we use the same address space for kernel and user data on the
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  74   
* PowerPC, we can just do these as direct assignments.  (Of course, the
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  75   
* exception handling means that it's no longer "just"...)
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  76   *
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  77   
*/
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  78  
#define get_user(x, ptr) \
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  79
__get_user_check((x), (ptr), sizeof(*(ptr)))
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  80  
#define put_user(x, ptr) \
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  81
__put_user_check((__typeof__(*(ptr)))(x), (ptr), sizeof(*(ptr)))
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  82  
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  83  
#define __get_user(x, ptr) \
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  84
__get_user_nocheck((x), (ptr), sizeof(*(ptr)))
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  85  
#defi

Re: [PATCH 8/8] waitid(): switch copyout of siginfo to unsafe_put_user()

[kbuild test robot]

Hi Al,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.12-rc1 next-20170515]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Al-Viro/move-compat-wait4-and-waitid-next-to-native-variants/20170516-084127
config: powerpc-allmodconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

All warnings (new ones prefixed by >>):

   In file included from include/asm-generic/bug.h:4:0,
from arch/powerpc/include/asm/bug.h:127,
from include/linux/bug.h:4,
from include/linux/mmdebug.h:4,
from include/linux/mm.h:8,
from kernel/exit.c:7:
   kernel/exit.c: In function 'C_SYSC_waitid':
   kernel/exit.c:1746:38: error: 'infop' undeclared (first use in this function)
 unsafe_put_user(err ? 0 : SIGCHLD, >si_signo, Efault);
 ^
   include/linux/compiler.h:179:42: note: in definition of macro 'unlikely'
# define unlikely(x) __builtin_expect(!!(x), 0)
 ^
>> arch/powerpc/include/asm/uaccess.h:86:2: note: in expansion of macro 
>> '__put_user_nocheck'
 __put_user_nocheck((__typeof__(*(ptr)))(x), (ptr), sizeof(*(ptr)))
 ^~
   include/linux/uaccess.h:302:56: note: in expansion of macro '__put_user'
#define unsafe_put_user(x, ptr, err) do { if (unlikely(__put_user(x, ptr))) 
goto err; } while (0)
   ^~
   kernel/exit.c:1746:2: note: in expansion of macro 'unsafe_put_user'
 unsafe_put_user(err ? 0 : SIGCHLD, >si_signo, Efault);
 ^~~
   kernel/exit.c:1746:38: note: each undeclared identifier is reported only 
once for each function it appears in
 unsafe_put_user(err ? 0 : SIGCHLD, >si_signo, Efault);
 ^
   include/linux/compiler.h:179:42: note: in definition of macro 'unlikely'
# define unlikely(x) __builtin_expect(!!(x), 0)
 ^
>> arch/powerpc/include/asm/uaccess.h:86:2: note: in expansion of macro 
>> '__put_user_nocheck'
 __put_user_nocheck((__typeof__(*(ptr)))(x), (ptr), sizeof(*(ptr)))
 ^~
   include/linux/uaccess.h:302:56: note: in expansion of macro '__put_user'
#define unsafe_put_user(x, ptr, err) do { if (unlikely(__put_user(x, ptr))) 
goto err; } while (0)
   ^~
   kernel/exit.c:1746:2: note: in expansion of macro 'unsafe_put_user'
 unsafe_put_user(err ? 0 : SIGCHLD, >si_signo, Efault);
 ^~~

vim +/__put_user_nocheck +86 arch/powerpc/include/asm/uaccess.h

2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  70   
* with a separate "access_ok()" call (this is used when we do multiple
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  71   
* accesses to the same area of user memory).
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  72   *
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  73   
* As we use the same address space for kernel and user data on the
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  74   
* PowerPC, we can just do these as direct assignments.  (Of course, the
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  75   
* exception handling means that it's no longer "just"...)
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  76   *
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  77   
*/
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  78  
#define get_user(x, ptr) \
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  79
__get_user_check((x), (ptr), sizeof(*(ptr)))
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  80  
#define put_user(x, ptr) \
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  81
__put_user_check((__typeof__(*(ptr)))(x), (ptr), sizeof(*(ptr)))
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  82  
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  83  
#define __get_user(x, ptr) \
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  84
__get_user_nocheck((x), (ptr), sizeof(*(ptr)))
2df5e8bc include/asm-powerpc/uaccess.h Stephen Rothwell   2005-10-29  85  
#defi

[PATCH net v2] net: x25: fix one potential use-after-free issue

[linzhang]

The function x25_init is not properly unregister related resources
on error handler.It is will result in kernel oops if x25_init init
failed, so add properly unregister call on error handler.

Also, i adjust the coding style and make x25_register_sysctl properly
return failure.

Signed-off-by: linzhang 
---
 include/net/x25.h|  4 ++--
 net/x25/af_x25.c | 34 +-
 net/x25/sysctl_net_x25.c |  5 -
 3 files changed, 27 insertions(+), 16 deletions(-)

diff --git a/include/net/x25.h b/include/net/x25.h
index c383aa4..339820c 100644
--- a/include/net/x25.h
+++ b/include/net/x25.h
@@ -298,10 +298,10 @@ int x25_decode(struct sock *, struct sk_buff *, int *, 
int *, int *, int *,
 
 /* sysctl_net_x25.c */
 #ifdef CONFIG_SYSCTL
-void x25_register_sysctl(void);
+int x25_register_sysctl(void);
 void x25_unregister_sysctl(void);
 #else
-static inline void x25_register_sysctl(void) {};
+static inline int x25_register_sysctl(void) { return 0 };
 static inline void x25_unregister_sysctl(void) {};
 #endif /* CONFIG_SYSCTL */
 
diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
index 8b911c2..75c64de 100644
--- a/net/x25/af_x25.c
+++ b/net/x25/af_x25.c
@@ -1791,34 +1791,42 @@ void x25_kill_by_neigh(struct x25_neigh *nb)
 
 static int __init x25_init(void)
 {
-   int rc = proto_register(_proto, 0);
+   int rc;
 
-   if (rc != 0)
+   rc = proto_register(_proto, 0);
+   if (rc)
goto out;
 
rc = sock_register(_family_ops);
-   if (rc != 0)
-   goto out_proto;
+   if (rc)
+   goto out_sock;
 
dev_add_pack(_packet_type);
 
rc = register_netdevice_notifier(_dev_notifier);
-   if (rc != 0)
-   goto out_sock;
+   if (rc)
+   goto out_dev;
 
-   pr_info("Linux Version 0.2\n");
+   rc = x25_register_sysctl();
+   if (rc)
+   goto out_sysctl;
 
-   x25_register_sysctl();
rc = x25_proc_init();
-   if (rc != 0)
-   goto out_dev;
+   if (rc)
+   goto out_proc;
+
+   pr_info("Linux Version 0.2\n");
+
 out:
return rc;
-out_dev:
+out_proc:
+   x25_unregister_sysctl();
+out_sysctl:
unregister_netdevice_notifier(_dev_notifier);
-out_sock:
+out_dev:
+   dev_remove_pack(_packet_type);
sock_unregister(AF_X25);
-out_proto:
+out_sock:
proto_unregister(_proto);
goto out;
 }
diff --git a/net/x25/sysctl_net_x25.c b/net/x25/sysctl_net_x25.c
index a06dfe1..ba078c8 100644
--- a/net/x25/sysctl_net_x25.c
+++ b/net/x25/sysctl_net_x25.c
@@ -73,9 +73,12 @@
{ },
 };
 
-void __init x25_register_sysctl(void)
+int __init x25_register_sysctl(void)
 {
x25_table_header = register_net_sysctl(_net, "net/x25", x25_table);
+   if (!x25_table_header)
+   return -ENOMEM;
+   return 0;
 }
 
 void x25_unregister_sysctl(void)
-- 
1.8.3.1

[PATCH net v2] net: x25: fix one potential use-after-free issue

[linzhang]

The function x25_init is not properly unregister related resources
on error handler.It is will result in kernel oops if x25_init init
failed, so add properly unregister call on error handler.

Also, i adjust the coding style and make x25_register_sysctl properly
return failure.

Signed-off-by: linzhang 
---
 include/net/x25.h|  4 ++--
 net/x25/af_x25.c | 34 +-
 net/x25/sysctl_net_x25.c |  5 -
 3 files changed, 27 insertions(+), 16 deletions(-)

diff --git a/include/net/x25.h b/include/net/x25.h
index c383aa4..339820c 100644
--- a/include/net/x25.h
+++ b/include/net/x25.h
@@ -298,10 +298,10 @@ int x25_decode(struct sock *, struct sk_buff *, int *, 
int *, int *, int *,
 
 /* sysctl_net_x25.c */
 #ifdef CONFIG_SYSCTL
-void x25_register_sysctl(void);
+int x25_register_sysctl(void);
 void x25_unregister_sysctl(void);
 #else
-static inline void x25_register_sysctl(void) {};
+static inline int x25_register_sysctl(void) { return 0 };
 static inline void x25_unregister_sysctl(void) {};
 #endif /* CONFIG_SYSCTL */
 
diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
index 8b911c2..75c64de 100644
--- a/net/x25/af_x25.c
+++ b/net/x25/af_x25.c
@@ -1791,34 +1791,42 @@ void x25_kill_by_neigh(struct x25_neigh *nb)
 
 static int __init x25_init(void)
 {
-   int rc = proto_register(_proto, 0);
+   int rc;
 
-   if (rc != 0)
+   rc = proto_register(_proto, 0);
+   if (rc)
goto out;
 
rc = sock_register(_family_ops);
-   if (rc != 0)
-   goto out_proto;
+   if (rc)
+   goto out_sock;
 
dev_add_pack(_packet_type);
 
rc = register_netdevice_notifier(_dev_notifier);
-   if (rc != 0)
-   goto out_sock;
+   if (rc)
+   goto out_dev;
 
-   pr_info("Linux Version 0.2\n");
+   rc = x25_register_sysctl();
+   if (rc)
+   goto out_sysctl;
 
-   x25_register_sysctl();
rc = x25_proc_init();
-   if (rc != 0)
-   goto out_dev;
+   if (rc)
+   goto out_proc;
+
+   pr_info("Linux Version 0.2\n");
+
 out:
return rc;
-out_dev:
+out_proc:
+   x25_unregister_sysctl();
+out_sysctl:
unregister_netdevice_notifier(_dev_notifier);
-out_sock:
+out_dev:
+   dev_remove_pack(_packet_type);
sock_unregister(AF_X25);
-out_proto:
+out_sock:
proto_unregister(_proto);
goto out;
 }
diff --git a/net/x25/sysctl_net_x25.c b/net/x25/sysctl_net_x25.c
index a06dfe1..ba078c8 100644
--- a/net/x25/sysctl_net_x25.c
+++ b/net/x25/sysctl_net_x25.c
@@ -73,9 +73,12 @@
{ },
 };
 
-void __init x25_register_sysctl(void)
+int __init x25_register_sysctl(void)
 {
x25_table_header = register_net_sysctl(_net, "net/x25", x25_table);
+   if (!x25_table_header)
+   return -ENOMEM;
+   return 0;
 }
 
 void x25_unregister_sysctl(void)
-- 
1.8.3.1

Re: [PATCH v4 1/4] can: m_can: move Message RAM initialization to function

[Oliver Hartkopp]

On 05/15/2017 06:50 AM, Marc Kleine-Budde wrote:

On 05/12/2017 08:37 AM, Quentin Schulz wrote:

Hi all,

On 05/05/2017 15:50, Quentin Schulz wrote:

To avoid possible ECC/parity checksum errors when reading an
uninitialized buffer, the entire Message RAM is initialized when probing
the driver. This initialization is done in the same function reading the
Device Tree properties.

This patch moves the RAM initialization to a separate function so it can
be called separately from device initialization from Device Tree.

Signed-off-by: Quentin Schulz 


It's been a week since I sent this patch series. Any comments?


Looks good, added to linux-can-next.


Isn't this a fix for linux-can instead?

At least it would make no sense to me to have the upgraded M_CAN driver 
in Linux 4.12 without this fix.


Regards,
Oliver

Re: [PATCH v4 1/4] can: m_can: move Message RAM initialization to function

[Oliver Hartkopp]

On 05/15/2017 06:50 AM, Marc Kleine-Budde wrote:

On 05/12/2017 08:37 AM, Quentin Schulz wrote:

Hi all,

On 05/05/2017 15:50, Quentin Schulz wrote:

To avoid possible ECC/parity checksum errors when reading an
uninitialized buffer, the entire Message RAM is initialized when probing
the driver. This initialization is done in the same function reading the
Device Tree properties.

This patch moves the RAM initialization to a separate function so it can
be called separately from device initialization from Device Tree.

Signed-off-by: Quentin Schulz 


It's been a week since I sent this patch series. Any comments?


Looks good, added to linux-can-next.


Isn't this a fix for linux-can instead?

At least it would make no sense to me to have the upgraded M_CAN driver 
in Linux 4.12 without this fix.


Regards,
Oliver

Re: [RFC/RFT PATCH 3/3] PCI/ACPI: Add ACPI pci_bus_find_numa_node() implementation

[Zhou Wang]

On 2017/5/15 17:17, Lorenzo Pieralisi wrote:
> On Mon, May 15, 2017 at 02:13:47PM +0800, Zhou Wang wrote:
>> On 2017/4/26 18:06, Lorenzo Pieralisi wrote:
>>> The introduction of pci_bus_find_numa_node(pci_bus) allows at PCI
>>> host bridge registration to detect the NUMA node for a given
>>> struct pci_bus.dev. Implement an ACPI method that, through
>>> the struct pci_bus.bridge ACPI companion, retrieve and return
>>> the NUMA node corresponding to a given struct pci_bus.dev.
>>>
>>> Signed-off-by: Lorenzo Pieralisi 
>>> Cc: Bjorn Helgaas 
>>> ---
>>>  drivers/pci/pci-acpi.c | 20 
>>>  include/linux/pci.h|  6 ++
>>>  2 files changed, 26 insertions(+)
>>>
>>> diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
>>> index 0018603..915da79 100644
>>> --- a/drivers/pci/pci-acpi.c
>>> +++ b/drivers/pci/pci-acpi.c
>>> @@ -10,6 +10,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -853,6 +854,25 @@ struct irq_domain 
>>> *pci_host_bridge_acpi_msi_domain(struct pci_bus *bus)
>>> return irq_find_matching_fwnode(fwnode, DOMAIN_BUS_PCI_MSI);
>>>  }
>>>  
>>> +int acpi_pci_bus_find_numa_node(struct pci_bus *bus)
>>> +{
>>> +   int node = NUMA_NO_NODE;
>>> +   struct device *bridge = get_device(bus->bridge);
>>> +
>>> +   if (!bridge)
>>> +   return node;
>>> +
>>> +   if (has_acpi_companion(bridge)) {
>>> +   struct acpi_device *adev = to_acpi_device_node(bridge->fwnode);
>>> +
>>> +   node = acpi_get_node(adev->handle);
>>> +   }
>>> +
>>> +   put_device(bridge);
>>> +
>>> +   return node;
>>> +}
>>> +
>>
>> It seems there is no function to call this, am I right?
> 
> Sorry, I missed updating pci_bus_find_numa_node() while reshuffling
> the code, apologies.
> 
> I will repost shortly.
> 
>> Another question is that: in the latest IORT revision C, "Proximity
>> domain" has been added to the IORT spec.  So when we enable NUMA for a
>> PCIe device, should we also consider this?
> 
> That's for the SMMU device.

Sorry, this is another problem. Now I get it that this Proximity domain
is for SMMU itself.

Thanks,
Zhou

> 
> Lorenzo
> 
>> Thanks,
>> Zhou
>>
>>>  static int __init acpi_pci_init(void)
>>>  {
>>> int ret;
>>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>>> index 9e62462..b40d095 100644
>>> --- a/include/linux/pci.h
>>> +++ b/include/linux/pci.h
>>> @@ -1481,6 +1481,12 @@ static inline int acpi_pci_bus_find_domain_nr(struct 
>>> pci_bus *bus)
>>>  #endif
>>>  int pci_bus_find_domain_nr(struct pci_bus *bus, struct device *parent);
>>>  #endif
>>> +#ifdef CONFIG_ACPI
>>> +int acpi_pci_bus_find_numa_node(struct pci_bus *bus);
>>> +#else
>>> +static inline int acpi_pci_bus_find_numa_node(struct pci_bus *bus)
>>> +{ return NUMA_NO_NODE; }
>>> +#endif
>>>  int pci_bus_find_numa_node(struct pci_bus *bus);
>>>  
>>>  /* some architectures require additional setup to direct VGA traffic */
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> .
> 

Re: [RFC/RFT PATCH 3/3] PCI/ACPI: Add ACPI pci_bus_find_numa_node() implementation

[Zhou Wang]

On 2017/5/15 17:17, Lorenzo Pieralisi wrote:
> On Mon, May 15, 2017 at 02:13:47PM +0800, Zhou Wang wrote:
>> On 2017/4/26 18:06, Lorenzo Pieralisi wrote:
>>> The introduction of pci_bus_find_numa_node(pci_bus) allows at PCI
>>> host bridge registration to detect the NUMA node for a given
>>> struct pci_bus.dev. Implement an ACPI method that, through
>>> the struct pci_bus.bridge ACPI companion, retrieve and return
>>> the NUMA node corresponding to a given struct pci_bus.dev.
>>>
>>> Signed-off-by: Lorenzo Pieralisi 
>>> Cc: Bjorn Helgaas 
>>> ---
>>>  drivers/pci/pci-acpi.c | 20 
>>>  include/linux/pci.h|  6 ++
>>>  2 files changed, 26 insertions(+)
>>>
>>> diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
>>> index 0018603..915da79 100644
>>> --- a/drivers/pci/pci-acpi.c
>>> +++ b/drivers/pci/pci-acpi.c
>>> @@ -10,6 +10,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -853,6 +854,25 @@ struct irq_domain 
>>> *pci_host_bridge_acpi_msi_domain(struct pci_bus *bus)
>>> return irq_find_matching_fwnode(fwnode, DOMAIN_BUS_PCI_MSI);
>>>  }
>>>  
>>> +int acpi_pci_bus_find_numa_node(struct pci_bus *bus)
>>> +{
>>> +   int node = NUMA_NO_NODE;
>>> +   struct device *bridge = get_device(bus->bridge);
>>> +
>>> +   if (!bridge)
>>> +   return node;
>>> +
>>> +   if (has_acpi_companion(bridge)) {
>>> +   struct acpi_device *adev = to_acpi_device_node(bridge->fwnode);
>>> +
>>> +   node = acpi_get_node(adev->handle);
>>> +   }
>>> +
>>> +   put_device(bridge);
>>> +
>>> +   return node;
>>> +}
>>> +
>>
>> It seems there is no function to call this, am I right?
> 
> Sorry, I missed updating pci_bus_find_numa_node() while reshuffling
> the code, apologies.
> 
> I will repost shortly.
> 
>> Another question is that: in the latest IORT revision C, "Proximity
>> domain" has been added to the IORT spec.  So when we enable NUMA for a
>> PCIe device, should we also consider this?
> 
> That's for the SMMU device.

Sorry, this is another problem. Now I get it that this Proximity domain
is for SMMU itself.

Thanks,
Zhou

> 
> Lorenzo
> 
>> Thanks,
>> Zhou
>>
>>>  static int __init acpi_pci_init(void)
>>>  {
>>> int ret;
>>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>>> index 9e62462..b40d095 100644
>>> --- a/include/linux/pci.h
>>> +++ b/include/linux/pci.h
>>> @@ -1481,6 +1481,12 @@ static inline int acpi_pci_bus_find_domain_nr(struct 
>>> pci_bus *bus)
>>>  #endif
>>>  int pci_bus_find_domain_nr(struct pci_bus *bus, struct device *parent);
>>>  #endif
>>> +#ifdef CONFIG_ACPI
>>> +int acpi_pci_bus_find_numa_node(struct pci_bus *bus);
>>> +#else
>>> +static inline int acpi_pci_bus_find_numa_node(struct pci_bus *bus)
>>> +{ return NUMA_NO_NODE; }
>>> +#endif
>>>  int pci_bus_find_numa_node(struct pci_bus *bus);
>>>  
>>>  /* some architectures require additional setup to direct VGA traffic */
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> .
> 

RE: Good day

[Johnson, Robert]

Good day
I av' been trying to reach you, contact me --> jeanettewon...@outlook.com 
for details

RE: Good day

[Johnson, Robert]

Good day
I av' been trying to reach you, contact me --> jeanettewon...@outlook.com 
for details

Re: [PATCH 08/18] xen/pvcalls: implement connect command

[Boris Ostrovsky]

On 05/15/2017 04:36 PM, Stefano Stabellini wrote:

Allocate a socket. Keep track of socket <-> ring mappings with a new data
structure, called sock_mapping. Implement the connect command by calling
inet_stream_connect, and mapping the new indexes page and data ring.
Associate the socket to an ioworker randomly.

When an active socket is closed (sk_state_change), set in_error to
-ENOTCONN and notify the other end, as specified by the protocol.

sk_data_ready will be implemented later.

Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-back.c | 145 +
 1 file changed, 145 insertions(+)

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index 2eae096..9ac1cf2 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -63,6 +63,29 @@ struct pvcalls_back_priv {
struct work_struct register_work;
 };

+struct sock_mapping {
+   struct list_head list;
+   struct list_head queue;


Since you have two lists it would be helpful if names were a bit more 
descriptive.


(and comments for at least some fields would be welcome too)


+   struct pvcalls_back_priv *priv;
+   struct socket *sock;
+   int data_worker;
+   uint64_t id;
+   grant_ref_t ref;
+   struct pvcalls_data_intf *ring;
+   void *bytes;
+   struct pvcalls_data data;
+   uint32_t ring_order;
+   int irq;
+   atomic_t read;
+   atomic_t write;
+   atomic_t release;
+   void (*saved_data_ready)(struct sock *sk);
+};
+
+static irqreturn_t pvcalls_back_conn_event(int irq, void *sock_map);
+static int pvcalls_back_release_active(struct xenbus_device *dev,
+  struct pvcalls_back_priv *priv,
+  struct sock_mapping *map);
 static void pvcalls_back_ioworker(struct work_struct *work)
 {
 }
@@ -97,9 +120,126 @@ static int pvcalls_back_socket(struct xenbus_device *dev,
return 1;
 }

+static void pvcalls_sk_state_change(struct sock *sock)
+{
+   struct sock_mapping *map = sock->sk_user_data;
+   struct pvcalls_data_intf *intf;
+
+   if (map == NULL)
+   return;
+
+   intf = map->ring;
+   intf->in_error = -ENOTCONN;
+   notify_remote_via_irq(map->irq);
+}
+
+static void pvcalls_sk_data_ready(struct sock *sock)
+{
+}
+
 static int pvcalls_back_connect(struct xenbus_device *dev,
struct xen_pvcalls_request *req)
 {
+   struct pvcalls_back_priv *priv;
+   int ret;
+   struct socket *sock;
+   struct sock_mapping *map = NULL;
+   void *page;
+   struct xen_pvcalls_response *rsp;
+
+   if (dev == NULL)
+   return 0;
+   priv = dev_get_drvdata(>dev);
+
+   map = kzalloc(sizeof(*map), GFP_KERNEL);
+   if (map == NULL) {
+   ret = -ENOMEM;
+   goto out;
+   }
+   ret = sock_create(AF_INET, SOCK_STREAM, 0, );
+   if (ret < 0) {
+   kfree(map);
+   goto out;
+   }
+   INIT_LIST_HEAD(>queue);
+   map->data_worker = get_random_int() % pvcalls_back_global.nr_ioworkers;
+
+   map->priv = priv;
+   map->sock = sock;
+   map->id = req->u.connect.id;
+   map->ref = req->u.connect.ref;
+
+   ret = xenbus_map_ring_valloc(dev, >u.connect.ref, 1, );
+   if (ret < 0) {
+   sock_release(map->sock);
+   kfree(map);
+   goto out;
+   }
+   map->ring = page;
+   map->ring_order = map->ring->ring_order;
+   /* first read the order, then map the data ring */
+   virt_rmb();



Not sure I understand what the barrier is for here. I don't think 
compiler will reorder ring_order access with the call.




+   if (map->ring_order > MAX_RING_ORDER) {
+   ret = -EFAULT;
+   goto out;
+   }


If the barrier is indeed needed this check belongs before it.

-boris



+   ret = xenbus_map_ring_valloc(dev, map->ring->ref,
+(1 << map->ring_order), );
+   if (ret < 0) {
+   sock_release(map->sock);
+   xenbus_unmap_ring_vfree(dev, map->ring);
+   kfree(map);
+   goto out;
+   }
+   map->bytes = page;
+
+   ret = bind_interdomain_evtchn_to_irqhandler(priv->dev->otherend_id,
+   req->u.connect.evtchn,
+   pvcalls_back_conn_event,
+   0,
+   "pvcalls-backend",
+   map);
+   if (ret < 0) {
+   sock_release(map->sock);
+   kfree(map);
+   goto out;
+   }
+   map->irq = ret;
+
+   map->data.in = map->bytes;
+   

Re: [PATCH 08/18] xen/pvcalls: implement connect command

[Boris Ostrovsky]

On 05/15/2017 04:36 PM, Stefano Stabellini wrote:

Allocate a socket. Keep track of socket <-> ring mappings with a new data
structure, called sock_mapping. Implement the connect command by calling
inet_stream_connect, and mapping the new indexes page and data ring.
Associate the socket to an ioworker randomly.

When an active socket is closed (sk_state_change), set in_error to
-ENOTCONN and notify the other end, as specified by the protocol.

sk_data_ready will be implemented later.

Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-back.c | 145 +
 1 file changed, 145 insertions(+)

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index 2eae096..9ac1cf2 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -63,6 +63,29 @@ struct pvcalls_back_priv {
struct work_struct register_work;
 };

+struct sock_mapping {
+   struct list_head list;
+   struct list_head queue;


Since you have two lists it would be helpful if names were a bit more 
descriptive.


(and comments for at least some fields would be welcome too)


+   struct pvcalls_back_priv *priv;
+   struct socket *sock;
+   int data_worker;
+   uint64_t id;
+   grant_ref_t ref;
+   struct pvcalls_data_intf *ring;
+   void *bytes;
+   struct pvcalls_data data;
+   uint32_t ring_order;
+   int irq;
+   atomic_t read;
+   atomic_t write;
+   atomic_t release;
+   void (*saved_data_ready)(struct sock *sk);
+};
+
+static irqreturn_t pvcalls_back_conn_event(int irq, void *sock_map);
+static int pvcalls_back_release_active(struct xenbus_device *dev,
+  struct pvcalls_back_priv *priv,
+  struct sock_mapping *map);
 static void pvcalls_back_ioworker(struct work_struct *work)
 {
 }
@@ -97,9 +120,126 @@ static int pvcalls_back_socket(struct xenbus_device *dev,
return 1;
 }

+static void pvcalls_sk_state_change(struct sock *sock)
+{
+   struct sock_mapping *map = sock->sk_user_data;
+   struct pvcalls_data_intf *intf;
+
+   if (map == NULL)
+   return;
+
+   intf = map->ring;
+   intf->in_error = -ENOTCONN;
+   notify_remote_via_irq(map->irq);
+}
+
+static void pvcalls_sk_data_ready(struct sock *sock)
+{
+}
+
 static int pvcalls_back_connect(struct xenbus_device *dev,
struct xen_pvcalls_request *req)
 {
+   struct pvcalls_back_priv *priv;
+   int ret;
+   struct socket *sock;
+   struct sock_mapping *map = NULL;
+   void *page;
+   struct xen_pvcalls_response *rsp;
+
+   if (dev == NULL)
+   return 0;
+   priv = dev_get_drvdata(>dev);
+
+   map = kzalloc(sizeof(*map), GFP_KERNEL);
+   if (map == NULL) {
+   ret = -ENOMEM;
+   goto out;
+   }
+   ret = sock_create(AF_INET, SOCK_STREAM, 0, );
+   if (ret < 0) {
+   kfree(map);
+   goto out;
+   }
+   INIT_LIST_HEAD(>queue);
+   map->data_worker = get_random_int() % pvcalls_back_global.nr_ioworkers;
+
+   map->priv = priv;
+   map->sock = sock;
+   map->id = req->u.connect.id;
+   map->ref = req->u.connect.ref;
+
+   ret = xenbus_map_ring_valloc(dev, >u.connect.ref, 1, );
+   if (ret < 0) {
+   sock_release(map->sock);
+   kfree(map);
+   goto out;
+   }
+   map->ring = page;
+   map->ring_order = map->ring->ring_order;
+   /* first read the order, then map the data ring */
+   virt_rmb();



Not sure I understand what the barrier is for here. I don't think 
compiler will reorder ring_order access with the call.




+   if (map->ring_order > MAX_RING_ORDER) {
+   ret = -EFAULT;
+   goto out;
+   }


If the barrier is indeed needed this check belongs before it.

-boris



+   ret = xenbus_map_ring_valloc(dev, map->ring->ref,
+(1 << map->ring_order), );
+   if (ret < 0) {
+   sock_release(map->sock);
+   xenbus_unmap_ring_vfree(dev, map->ring);
+   kfree(map);
+   goto out;
+   }
+   map->bytes = page;
+
+   ret = bind_interdomain_evtchn_to_irqhandler(priv->dev->otherend_id,
+   req->u.connect.evtchn,
+   pvcalls_back_conn_event,
+   0,
+   "pvcalls-backend",
+   map);
+   if (ret < 0) {
+   sock_release(map->sock);
+   kfree(map);
+   goto out;
+   }
+   map->irq = ret;
+
+   map->data.in = map->bytes;
+   map->data.out = map->bytes 

Re: [PATCH v5 2/3] KASLR: Handle memory limit specified by memmap and mem option

[Baoquan He]

On 05/16/17 at 09:43am, Dou Liyang wrote:
> 
> 
> At 05/16/2017 09:12 AM, Baoquan He wrote:
> > On 05/16/17 at 08:56am, Dou Liyang wrote:
> > > Hi Baoquan,
> > > 
> > > At 05/13/2017 01:46 PM, Baoquan He wrote:
> > > > Option mem= will limit the max address a system can use and any memory
> > > > region above the limit will be removed.
> > > > 
> > > > Furthermore, memmap=nn[KMG] which has no offset specified has the same
> > > > behaviour as mem=.
> > > > 
> > > > KASLR needs to consider this when choosing the random position for
> > > > decompressing the kernel. Do it now.
> > > > 
> > > > Signed-off-by: Baoquan He 
> > > > Tested-by: Masayoshi Mizuma 
> > > > ---
> > > >  arch/x86/boot/compressed/kaslr.c | 68 
> > > > +---
> > > >  1 file changed, 50 insertions(+), 18 deletions(-)
> > > > 
> > > > return -EINVAL;
> > > > @@ -173,9 +184,14 @@ static void mem_avoid_memmap(char *str)
> > > > if (rc < 0)
> > > > break;
> > > > str = k;
> > > > -   /* A usable region that should not be skipped */
> > > > -   if (size == 0)
> > > > +
> > > > +   if (start == 0) {
> > > > +   /* Store the specified memory limit if size > 0 
> > > > */
> > > > +   if (size > 0)
> > > > +   mem_limit = size;
> > > 
> > > Baoquan,
> > > 
> > > I am not sure about setting the value of mem_limit to mem_size directly.
> > > 
> > > If the command line has both the "memmap" and "mem", such as
> > >  ... mem=2G memmap=4G ...
> > > 
> > > ...in that code, the mem_limit may be 4G not 2G.
> > 
> > No, could you tell why you want to add both "memmap=nnKMG" and "mem=" at
> > the same time? As you sid, what if I add "mem=4G mem=2G mem=1G"?
> 
> Just for testing :)
> 
> Ok, thanks, I see. We should be responsible for our command line. don't
> need to consider with these situations in kernel.

Thanks for testing and looking into this patchset, Liyang. I understand
your worry, this patch is trying to have the same behaviour as in
arch/x86/kernel/e820.c. Seems the liability of specifying them right lays
on users' shoulder.

Thanks
Baoquan

Re: [PATCH v5 2/3] KASLR: Handle memory limit specified by memmap and mem option

[Baoquan He]

On 05/16/17 at 09:43am, Dou Liyang wrote:
> 
> 
> At 05/16/2017 09:12 AM, Baoquan He wrote:
> > On 05/16/17 at 08:56am, Dou Liyang wrote:
> > > Hi Baoquan,
> > > 
> > > At 05/13/2017 01:46 PM, Baoquan He wrote:
> > > > Option mem= will limit the max address a system can use and any memory
> > > > region above the limit will be removed.
> > > > 
> > > > Furthermore, memmap=nn[KMG] which has no offset specified has the same
> > > > behaviour as mem=.
> > > > 
> > > > KASLR needs to consider this when choosing the random position for
> > > > decompressing the kernel. Do it now.
> > > > 
> > > > Signed-off-by: Baoquan He 
> > > > Tested-by: Masayoshi Mizuma 
> > > > ---
> > > >  arch/x86/boot/compressed/kaslr.c | 68 
> > > > +---
> > > >  1 file changed, 50 insertions(+), 18 deletions(-)
> > > > 
> > > > return -EINVAL;
> > > > @@ -173,9 +184,14 @@ static void mem_avoid_memmap(char *str)
> > > > if (rc < 0)
> > > > break;
> > > > str = k;
> > > > -   /* A usable region that should not be skipped */
> > > > -   if (size == 0)
> > > > +
> > > > +   if (start == 0) {
> > > > +   /* Store the specified memory limit if size > 0 
> > > > */
> > > > +   if (size > 0)
> > > > +   mem_limit = size;
> > > 
> > > Baoquan,
> > > 
> > > I am not sure about setting the value of mem_limit to mem_size directly.
> > > 
> > > If the command line has both the "memmap" and "mem", such as
> > >  ... mem=2G memmap=4G ...
> > > 
> > > ...in that code, the mem_limit may be 4G not 2G.
> > 
> > No, could you tell why you want to add both "memmap=nnKMG" and "mem=" at
> > the same time? As you sid, what if I add "mem=4G mem=2G mem=1G"?
> 
> Just for testing :)
> 
> Ok, thanks, I see. We should be responsible for our command line. don't
> need to consider with these situations in kernel.

Thanks for testing and looking into this patchset, Liyang. I understand
your worry, this patch is trying to have the same behaviour as in
arch/x86/kernel/e820.c. Seems the liability of specifying them right lays
on users' shoulder.

Thanks
Baoquan

[PATCH v3] cros_ec_i2c: prevent i2c timeout for EC_CMD_FLASH_ERASE

[Wei-Ning Huang]

From: Wei-Ning Huang 

Some EC chip has larger flash sector size which requires longer erase
time. During erase the CPU is usually stalled and can't even respond to
interrupts. We sleep a while to block any EC command from executing
during the flash erase period.

Signed-off-by: Wei-Ning Huang 
---
 drivers/mfd/cros_ec_i2c.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
index 9f70de1e4c70..c1b5c831b9cb 100644
--- a/drivers/mfd/cros_ec_i2c.c
+++ b/drivers/mfd/cros_ec_i2c.c
@@ -23,6 +23,14 @@
 #include 
 #include 
 
+/*
+ * Some EC chip has larger flash sector size which requires longer erase time.
+ * During erase the CPU is usually stalled and can't even respond to
+ * interrupts. We sleep for a while to block any EC command from executing
+ * during the flash erase period to prevent i2c timeout.
+ */
+#define EC_FLASH_ERASE_DELAY_MS5000
+
 /**
  * Request format for protocol v3
  * byte 0  0xda (EC_COMMAND_PROTOCOL_3)
@@ -120,7 +128,7 @@ static int cros_ec_pkt_xfer_i2c(struct cros_ec_device 
*ec_dev,
ret = -EAGAIN;
dev_dbg(ec_dev->dev, "command 0x%02x in progress\n",
msg->command);
-   goto done;
+   goto inprogress;
 
default:
dev_dbg(ec_dev->dev, "command 0x%02x returned %d\n",
@@ -177,7 +185,19 @@ static int cros_ec_pkt_xfer_i2c(struct cros_ec_device 
*ec_dev,
 
ret = ec_response->data_len;
 
+inprogress:
+   /*
+* If we get EC_RES_IN_PROGRESS for EC_CMD_FLASH_ERASE this means EC
+* need a long time to erase flash, during flash erase CPU is stalled
+* and can't respond to interrupts, so we sleep for a while to stop new
+* EC commands from communicating with EC.
+*/
+   if (msg->command == EC_CMD_FLASH_ERASE &&
+   msg->result == EC_RES_IN_PROGRESS)
+   msleep(EC_FLASH_ERASE_DELAY_MS);
+
 done:
+
if (msg->command == EC_CMD_REBOOT_EC)
msleep(EC_REBOOT_DELAY_MS);
 
-- 
2.12.2

[PATCH v3] cros_ec_i2c: prevent i2c timeout for EC_CMD_FLASH_ERASE

[Wei-Ning Huang]

From: Wei-Ning Huang 

Some EC chip has larger flash sector size which requires longer erase
time. During erase the CPU is usually stalled and can't even respond to
interrupts. We sleep a while to block any EC command from executing
during the flash erase period.

Signed-off-by: Wei-Ning Huang 
---
 drivers/mfd/cros_ec_i2c.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
index 9f70de1e4c70..c1b5c831b9cb 100644
--- a/drivers/mfd/cros_ec_i2c.c
+++ b/drivers/mfd/cros_ec_i2c.c
@@ -23,6 +23,14 @@
 #include 
 #include 
 
+/*
+ * Some EC chip has larger flash sector size which requires longer erase time.
+ * During erase the CPU is usually stalled and can't even respond to
+ * interrupts. We sleep for a while to block any EC command from executing
+ * during the flash erase period to prevent i2c timeout.
+ */
+#define EC_FLASH_ERASE_DELAY_MS5000
+
 /**
  * Request format for protocol v3
  * byte 0  0xda (EC_COMMAND_PROTOCOL_3)
@@ -120,7 +128,7 @@ static int cros_ec_pkt_xfer_i2c(struct cros_ec_device 
*ec_dev,
ret = -EAGAIN;
dev_dbg(ec_dev->dev, "command 0x%02x in progress\n",
msg->command);
-   goto done;
+   goto inprogress;
 
default:
dev_dbg(ec_dev->dev, "command 0x%02x returned %d\n",
@@ -177,7 +185,19 @@ static int cros_ec_pkt_xfer_i2c(struct cros_ec_device 
*ec_dev,
 
ret = ec_response->data_len;
 
+inprogress:
+   /*
+* If we get EC_RES_IN_PROGRESS for EC_CMD_FLASH_ERASE this means EC
+* need a long time to erase flash, during flash erase CPU is stalled
+* and can't respond to interrupts, so we sleep for a while to stop new
+* EC commands from communicating with EC.
+*/
+   if (msg->command == EC_CMD_FLASH_ERASE &&
+   msg->result == EC_RES_IN_PROGRESS)
+   msleep(EC_FLASH_ERASE_DELAY_MS);
+
 done:
+
if (msg->command == EC_CMD_REBOOT_EC)
msleep(EC_REBOOT_DELAY_MS);
 
-- 
2.12.2

Re: [PATCH 2/2] zram: do not count duplicated pages as compressed

[Sergey Senozhatsky]

Hello Minchan,

On (05/16/17 10:59), Minchan Kim wrote:
> Hi Sergey,
>

[..]
> You mean this?
> 
> static void zram_free_page(..) {
> if (zram_test_flag(zram, index, ZRAM_SAME))
> ...
> 
> if (!entry)
> return;
> 
> if (zram_dedup_enabled(zram) && )) {
> zram_clear_flag(ZRAM_DUP);
> atomic64_sub(entry->len, >stats.dup_data_size);
> } else {
> atomic64_sub(zram_get_obj_size(zram, index),
> >stats.compr_dat_size);
> }
> 
> zram_entry_free
> zram_set_entry
> zram_set_obj_size
> }

yeah, something like this.

> > > @@ -794,7 +801,15 @@ static int __zram_bvec_write(struct zram *zram, 
> > > struct bio_vec *bvec, u32 index)
> > >   entry = zram_dedup_find(zram, page, );
> > >   if (entry) {
> > >   comp_len = entry->len;
> > > - goto found_dup;
> > > + zram_slot_lock(zram, index);
> > > + zram_free_page(zram, index);
> > > + zram_set_flag(zram, index, ZRAM_DUP);
> > > + zram_set_entry(zram, index, entry);
> > > + zram_set_obj_size(zram, index, comp_len);
> > > + zram_slot_unlock(zram, index);
> > > + atomic64_add(comp_len, >stats.dup_data_size);
> > > + atomic64_inc(>stats.pages_stored);
> > > + return 0;
> > 
> > hm. that's a somewhat big code duplication. isn't it?
> 
> Yub. 3 parts. above part,  zram_same_page_write and tail of __zram_bvec_write.

hmm... good question... hardly can think of anything significantly
better, zram object handling is now a mix of flags, entries,
ref_counters, etc. etc. may be we can merge some of those ops, if we
would keep slot locked through the entire __zram_bvec_write(), but
that does not look attractive.

something ABSOLUTELY untested and incomplete. not even compile tested (!).
99% broken and stupid (!). but there is one thing that it has revealed, so
thus incomplete. see below:

---

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 372602c7da49..b31543c40d54 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -509,11 +509,8 @@ static bool zram_same_page_write(struct zram *zram, u32 
index,
if (page_same_filled(mem, )) {
kunmap_atomic(mem);
/* Free memory associated with this sector now. */
-   zram_slot_lock(zram, index);
-   zram_free_page(zram, index);
zram_set_flag(zram, index, ZRAM_SAME);
zram_set_element(zram, index, element);
-   zram_slot_unlock(zram, index);
 
atomic64_inc(>stats.same_pages);
return true;
@@ -778,7 +775,7 @@ static int zram_compress(struct zram *zram, struct 
zcomp_strm **zstrm,
 
 static int __zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 
index)
 {
-   int ret;
+   int ret = 0;
struct zram_entry *entry;
unsigned int comp_len;
void *src, *dst;
@@ -786,12 +783,20 @@ static int __zram_bvec_write(struct zram *zram, struct 
bio_vec *bvec, u32 index)
struct page *page = bvec->bv_page;
u32 checksum;
 
+   /*
+* Free memory associated with this sector
+* before overwriting unused sectors.
+*/
+   zram_slot_lock(zram, index);
+   zram_free_page(zram, index);
+
if (zram_same_page_write(zram, index, page))
-   return 0;
+   goto out_unlock;
 
entry = zram_dedup_find(zram, page, );
if (entry) {
comp_len = entry->len;
+   zram_set_flag(zram, index, ZRAM_DUP);
goto found_dup;
}
 
@@ -799,7 +804,7 @@ static int __zram_bvec_write(struct zram *zram, struct 
bio_vec *bvec, u32 index)
ret = zram_compress(zram, , page, , _len);
if (ret) {
zcomp_stream_put(zram->comp);
-   return ret;
+   goto out_unlock;
}
 
dst = zs_map_object(zram->mem_pool,
@@ -817,20 +822,16 @@ static int __zram_bvec_write(struct zram *zram, struct 
bio_vec *bvec, u32 index)
zram_dedup_insert(zram, entry, checksum);
 
 found_dup:
-   /*
-* Free memory associated with this sector
-* before overwriting unused sectors.
-*/
-   zram_slot_lock(zram, index);
-   zram_free_page(zram, index);
zram_set_entry(zram, index, entry);
zram_set_obj_size(zram, index, comp_len);
-   zram_slot_unlock(zram, index);
 
/* Update stats */
atomic64_add(comp_len, >stats.compr_data_size);
atomic64_inc(>stats.pages_stored);
-   return 0;
+
+out_unlock:
+   zram_slot_unlock(zram, index);
+   return ret;
 }

---


namely,
that zram_compress() error return path from __zram_bvec_write().

currently, we touch the existing compressed object and overwrite it only
when we successfully compressed a 

Re: [PATCH 2/2] zram: do not count duplicated pages as compressed

[Sergey Senozhatsky]

Hello Minchan,

On (05/16/17 10:59), Minchan Kim wrote:
> Hi Sergey,
>

[..]
> You mean this?
> 
> static void zram_free_page(..) {
> if (zram_test_flag(zram, index, ZRAM_SAME))
> ...
> 
> if (!entry)
> return;
> 
> if (zram_dedup_enabled(zram) && )) {
> zram_clear_flag(ZRAM_DUP);
> atomic64_sub(entry->len, >stats.dup_data_size);
> } else {
> atomic64_sub(zram_get_obj_size(zram, index),
> >stats.compr_dat_size);
> }
> 
> zram_entry_free
> zram_set_entry
> zram_set_obj_size
> }

yeah, something like this.

> > > @@ -794,7 +801,15 @@ static int __zram_bvec_write(struct zram *zram, 
> > > struct bio_vec *bvec, u32 index)
> > >   entry = zram_dedup_find(zram, page, );
> > >   if (entry) {
> > >   comp_len = entry->len;
> > > - goto found_dup;
> > > + zram_slot_lock(zram, index);
> > > + zram_free_page(zram, index);
> > > + zram_set_flag(zram, index, ZRAM_DUP);
> > > + zram_set_entry(zram, index, entry);
> > > + zram_set_obj_size(zram, index, comp_len);
> > > + zram_slot_unlock(zram, index);
> > > + atomic64_add(comp_len, >stats.dup_data_size);
> > > + atomic64_inc(>stats.pages_stored);
> > > + return 0;
> > 
> > hm. that's a somewhat big code duplication. isn't it?
> 
> Yub. 3 parts. above part,  zram_same_page_write and tail of __zram_bvec_write.

hmm... good question... hardly can think of anything significantly
better, zram object handling is now a mix of flags, entries,
ref_counters, etc. etc. may be we can merge some of those ops, if we
would keep slot locked through the entire __zram_bvec_write(), but
that does not look attractive.

something ABSOLUTELY untested and incomplete. not even compile tested (!).
99% broken and stupid (!). but there is one thing that it has revealed, so
thus incomplete. see below:

---

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 372602c7da49..b31543c40d54 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -509,11 +509,8 @@ static bool zram_same_page_write(struct zram *zram, u32 
index,
if (page_same_filled(mem, )) {
kunmap_atomic(mem);
/* Free memory associated with this sector now. */
-   zram_slot_lock(zram, index);
-   zram_free_page(zram, index);
zram_set_flag(zram, index, ZRAM_SAME);
zram_set_element(zram, index, element);
-   zram_slot_unlock(zram, index);
 
atomic64_inc(>stats.same_pages);
return true;
@@ -778,7 +775,7 @@ static int zram_compress(struct zram *zram, struct 
zcomp_strm **zstrm,
 
 static int __zram_bvec_write(struct zram *zram, struct bio_vec *bvec, u32 
index)
 {
-   int ret;
+   int ret = 0;
struct zram_entry *entry;
unsigned int comp_len;
void *src, *dst;
@@ -786,12 +783,20 @@ static int __zram_bvec_write(struct zram *zram, struct 
bio_vec *bvec, u32 index)
struct page *page = bvec->bv_page;
u32 checksum;
 
+   /*
+* Free memory associated with this sector
+* before overwriting unused sectors.
+*/
+   zram_slot_lock(zram, index);
+   zram_free_page(zram, index);
+
if (zram_same_page_write(zram, index, page))
-   return 0;
+   goto out_unlock;
 
entry = zram_dedup_find(zram, page, );
if (entry) {
comp_len = entry->len;
+   zram_set_flag(zram, index, ZRAM_DUP);
goto found_dup;
}
 
@@ -799,7 +804,7 @@ static int __zram_bvec_write(struct zram *zram, struct 
bio_vec *bvec, u32 index)
ret = zram_compress(zram, , page, , _len);
if (ret) {
zcomp_stream_put(zram->comp);
-   return ret;
+   goto out_unlock;
}
 
dst = zs_map_object(zram->mem_pool,
@@ -817,20 +822,16 @@ static int __zram_bvec_write(struct zram *zram, struct 
bio_vec *bvec, u32 index)
zram_dedup_insert(zram, entry, checksum);
 
 found_dup:
-   /*
-* Free memory associated with this sector
-* before overwriting unused sectors.
-*/
-   zram_slot_lock(zram, index);
-   zram_free_page(zram, index);
zram_set_entry(zram, index, entry);
zram_set_obj_size(zram, index, comp_len);
-   zram_slot_unlock(zram, index);
 
/* Update stats */
atomic64_add(comp_len, >stats.compr_data_size);
atomic64_inc(>stats.pages_stored);
-   return 0;
+
+out_unlock:
+   zram_slot_unlock(zram, index);
+   return ret;
 }

---


namely,
that zram_compress() error return path from __zram_bvec_write().

currently, we touch the existing compressed object and overwrite it only
when we successfully compressed a 

Re: [RFC/PATCH 1/2] dt-binding: mfd: Add Maxim/Dallas DS1374 MFD device binding

[Moritz Fischer]

On Fri, May 12, 2017 at 07:00:29PM -0500, Rob Herring wrote:
> On Tue, May 09, 2017 at 11:20:20AM -0700, Moritz Fischer wrote:
> > This adds a binding for the Maxim/Dallas DS1374 MFD.
> > 
> > Signed-off-by: Moritz Fischer 
> > ---
> > 
> > Hi all,
> > 
> > I'm not entirely sure aobut the binding, does anyone
> > have a better suggestion for the remap-wdt-reset property?
> > 
> > Thanks,
> > 
> > Moritz
> > 
> > ---
> >  Documentation/devicetree/bindings/mfd/ds1374.txt   | 63 
> > ++
> >  .../devicetree/bindings/trivial-devices.txt|  1 -
> >  drivers/rtc/Kconfig|  2 +
> >  3 files changed, 65 insertions(+), 1 deletion(-)
> >  create mode 100644 Documentation/devicetree/bindings/mfd/ds1374.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/mfd/ds1374.txt 
> > b/Documentation/devicetree/bindings/mfd/ds1374.txt
> > new file mode 100644
> > index 000..b22396f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mfd/ds1374.txt
> > @@ -0,0 +1,63 @@
> > +* Device tree bindings for Maxim/Dallas DS1374 Multi Function Device (MFD)
> > +
> > +The Maxim/Dallas DS1374 is a multi function device that combines rtc,
> > +watchdog or alarm, as well as trickle charger.
> > +
> > +The DS1374 is connected via I2C.
> > +
> > +Required properties:
> > +- compatible: "dallas,ds1374"
> > +- reg: I2C slave address
> > +- dallas,ds1374-mode: Should be one of the following values:
> 
> Just "dallas,mode" is sufficient.

Will fix.
> 
> > +   <0> for RTC
> > +   <1> for RTC + Alarm (Interrupt)
> > +   <2> for RTC + Watchdog
> > +
> > +Required child:
> > +A single available child device of type matching the "dallas,ds1374-mode"
> > +property.
> > +
> > +Optional properties (watchdog):
> > +- dallas,ds1374-remap-wdt-reset: Boolean describing whether the INT pin
> > +on the device is used as interrupt for
> > +the alarm
> 
> Isn't presence of the interrupt property or not enough? It would be 
> kind of useless to have no interrupt and also not do anything on 
> timeout.

So you're saying:

If interrupt not present AND mode = <0> ignore interrupt

If interrupt present AND mode = <1> (maybe define here would be nicer),
make it an interrupt.

If interrupt not present AND mode = <2> then this implies that reset
output is mapped to RST pin.

If Interrupt present AND mode = <2> then this implies that the reset
output is (re)mapped to INT pin?

> 
> > +
> > +See ../watchdog/* for generic watchdog bindings.
> > +
> > +Optional properties (real time clock):
> > +- interrupt: phandle to interrupt cell for the rtc's alarm feature
> > +
> > +See ../rtc/* for generic rtc bindings.
> > +
> > +Optional properties (trickle-charger):
> > +- dallas,trickle-resistor-ohms : Selected resistor for trickle charger
> > +   Values usable for ds1374 are 250, 2000, 4000
> > +   Should be given if trickle charger should be enabled
> > +- dallas,trickle-diode-disable : Do not use internal trickle charger diode
> > +   Should be given if internal trickle charger diode should be disabled
> > +
> > +Example for rtc with alarm mode and interrupt:
> > +
> > +i2c@12ca {
> > +   rtc@68 {
> > +   compatible = "ds1374";
> > +   reg = <0x68>;
> > +   interrupts = < 62>;
> > +   dallas,ds1374-mode = <2>
> > +
> > +   dallas,trickle-resistor-ohms = <250>;
> > +   dallas,trickle-diode-disable;
> > +   };
> > +};
> > +
> > +Example for rtc with watchdog and reset on timeout, with reset remapped
> > +to the INT pin:
> > +
> > +i2c@12ca {
> > +   rtc@68 {
> > +   compatible = "ds1374";
> > +   reg = <0x68>;
> > +   dallas,ds1374-mode = <2>
> > +   dallas,ds1374-remap-wdt-reset;
> > +   };
> > +};
> > diff --git a/Documentation/devicetree/bindings/trivial-devices.txt 
> > b/Documentation/devicetree/bindings/trivial-devices.txt
> > index 3e0a34c..f7a50e5 100644
> > --- a/Documentation/devicetree/bindings/trivial-devices.txt
> > +++ b/Documentation/devicetree/bindings/trivial-devices.txt
> > @@ -29,7 +29,6 @@ cirrus,cs42l51Cirrus Logic CS42L51 audio codec
> >  dallas,ds1307  64 x 8, Serial, I2C Real-Time Clock
> >  dallas,ds1338  I2C RTC with 56-Byte NV RAM
> >  dallas,ds1340  I2C RTC with Trickle Charger
> > -dallas,ds1374  I2C, 32-Bit Binary Counter Watchdog RTC with 
> > Trickle Charger and Reset Input/Output
> >  dallas,ds1631  High-Precision Digital Thermometer
> >  dallas,ds1682  Total-Elapsed-Time Recorder with Alarm
> >  dallas,ds1775  Tiny Digital Thermometer and Thermostat
> > diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> > index 8d3b957..e6763fe 100644
> > --- a/drivers/rtc/Kconfig
> > +++ b/drivers/rtc/Kconfig
> > @@ -250,6 +250,8 @@ config RTC_DRV_DS1307_CENTURY
> >  
> >  config 

Re: [RFC/PATCH 1/2] dt-binding: mfd: Add Maxim/Dallas DS1374 MFD device binding

[Moritz Fischer]

On Fri, May 12, 2017 at 07:00:29PM -0500, Rob Herring wrote:
> On Tue, May 09, 2017 at 11:20:20AM -0700, Moritz Fischer wrote:
> > This adds a binding for the Maxim/Dallas DS1374 MFD.
> > 
> > Signed-off-by: Moritz Fischer 
> > ---
> > 
> > Hi all,
> > 
> > I'm not entirely sure aobut the binding, does anyone
> > have a better suggestion for the remap-wdt-reset property?
> > 
> > Thanks,
> > 
> > Moritz
> > 
> > ---
> >  Documentation/devicetree/bindings/mfd/ds1374.txt   | 63 
> > ++
> >  .../devicetree/bindings/trivial-devices.txt|  1 -
> >  drivers/rtc/Kconfig|  2 +
> >  3 files changed, 65 insertions(+), 1 deletion(-)
> >  create mode 100644 Documentation/devicetree/bindings/mfd/ds1374.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/mfd/ds1374.txt 
> > b/Documentation/devicetree/bindings/mfd/ds1374.txt
> > new file mode 100644
> > index 000..b22396f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mfd/ds1374.txt
> > @@ -0,0 +1,63 @@
> > +* Device tree bindings for Maxim/Dallas DS1374 Multi Function Device (MFD)
> > +
> > +The Maxim/Dallas DS1374 is a multi function device that combines rtc,
> > +watchdog or alarm, as well as trickle charger.
> > +
> > +The DS1374 is connected via I2C.
> > +
> > +Required properties:
> > +- compatible: "dallas,ds1374"
> > +- reg: I2C slave address
> > +- dallas,ds1374-mode: Should be one of the following values:
> 
> Just "dallas,mode" is sufficient.

Will fix.
> 
> > +   <0> for RTC
> > +   <1> for RTC + Alarm (Interrupt)
> > +   <2> for RTC + Watchdog
> > +
> > +Required child:
> > +A single available child device of type matching the "dallas,ds1374-mode"
> > +property.
> > +
> > +Optional properties (watchdog):
> > +- dallas,ds1374-remap-wdt-reset: Boolean describing whether the INT pin
> > +on the device is used as interrupt for
> > +the alarm
> 
> Isn't presence of the interrupt property or not enough? It would be 
> kind of useless to have no interrupt and also not do anything on 
> timeout.

So you're saying:

If interrupt not present AND mode = <0> ignore interrupt

If interrupt present AND mode = <1> (maybe define here would be nicer),
make it an interrupt.

If interrupt not present AND mode = <2> then this implies that reset
output is mapped to RST pin.

If Interrupt present AND mode = <2> then this implies that the reset
output is (re)mapped to INT pin?

> 
> > +
> > +See ../watchdog/* for generic watchdog bindings.
> > +
> > +Optional properties (real time clock):
> > +- interrupt: phandle to interrupt cell for the rtc's alarm feature
> > +
> > +See ../rtc/* for generic rtc bindings.
> > +
> > +Optional properties (trickle-charger):
> > +- dallas,trickle-resistor-ohms : Selected resistor for trickle charger
> > +   Values usable for ds1374 are 250, 2000, 4000
> > +   Should be given if trickle charger should be enabled
> > +- dallas,trickle-diode-disable : Do not use internal trickle charger diode
> > +   Should be given if internal trickle charger diode should be disabled
> > +
> > +Example for rtc with alarm mode and interrupt:
> > +
> > +i2c@12ca {
> > +   rtc@68 {
> > +   compatible = "ds1374";
> > +   reg = <0x68>;
> > +   interrupts = < 62>;
> > +   dallas,ds1374-mode = <2>
> > +
> > +   dallas,trickle-resistor-ohms = <250>;
> > +   dallas,trickle-diode-disable;
> > +   };
> > +};
> > +
> > +Example for rtc with watchdog and reset on timeout, with reset remapped
> > +to the INT pin:
> > +
> > +i2c@12ca {
> > +   rtc@68 {
> > +   compatible = "ds1374";
> > +   reg = <0x68>;
> > +   dallas,ds1374-mode = <2>
> > +   dallas,ds1374-remap-wdt-reset;
> > +   };
> > +};
> > diff --git a/Documentation/devicetree/bindings/trivial-devices.txt 
> > b/Documentation/devicetree/bindings/trivial-devices.txt
> > index 3e0a34c..f7a50e5 100644
> > --- a/Documentation/devicetree/bindings/trivial-devices.txt
> > +++ b/Documentation/devicetree/bindings/trivial-devices.txt
> > @@ -29,7 +29,6 @@ cirrus,cs42l51Cirrus Logic CS42L51 audio codec
> >  dallas,ds1307  64 x 8, Serial, I2C Real-Time Clock
> >  dallas,ds1338  I2C RTC with 56-Byte NV RAM
> >  dallas,ds1340  I2C RTC with Trickle Charger
> > -dallas,ds1374  I2C, 32-Bit Binary Counter Watchdog RTC with 
> > Trickle Charger and Reset Input/Output
> >  dallas,ds1631  High-Precision Digital Thermometer
> >  dallas,ds1682  Total-Elapsed-Time Recorder with Alarm
> >  dallas,ds1775  Tiny Digital Thermometer and Thermostat
> > diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> > index 8d3b957..e6763fe 100644
> > --- a/drivers/rtc/Kconfig
> > +++ b/drivers/rtc/Kconfig
> > @@ -250,6 +250,8 @@ config RTC_DRV_DS1307_CENTURY
> >  
> >  config RTC_DRV_DS1374
> 

Re: [PATCH 07/18] xen/pvcalls: implement socket command

[Boris Ostrovsky]

On 05/15/2017 04:35 PM, Stefano Stabellini wrote:

Just reply with success to the other end for now. Delay the allocation
of the actual socket to bind and/or connect.

Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-back.c | 31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index 2b2a49a..2eae096 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -12,12 +12,17 @@
  * GNU General Public License for more details.
  */

+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 

 #include 
 #include 
@@ -65,7 +70,31 @@ static void pvcalls_back_ioworker(struct work_struct *work)
 static int pvcalls_back_socket(struct xenbus_device *dev,
struct xen_pvcalls_request *req)
 {
-   return 0;
+   struct pvcalls_back_priv *priv;
+   int ret;
+   struct xen_pvcalls_response *rsp;
+
+   if (dev == NULL)
+   return 0;
+   priv = dev_get_drvdata(>dev);


This is inconsistent with pvcalls_back_event() tests, where you check 
both for NULL. OTOH, I am not sure a check is needed at all since you've 
just tested these in pvcalls_back_event().



-boris


+
+   if (req->u.socket.domain != AF_INET ||
+   req->u.socket.type != SOCK_STREAM ||
+   (req->u.socket.protocol != 0 &&
+req->u.socket.protocol != AF_INET))
+   ret = -EAFNOSUPPORT;
+   else
+   ret = 0;
+
+   /* leave the actual socket allocation for later */
+
+   rsp = RING_GET_RESPONSE(>ring, priv->ring.rsp_prod_pvt++);
+   rsp->req_id = req->req_id;
+   rsp->cmd = req->cmd;
+   rsp->u.socket.id = req->u.socket.id;
+   rsp->ret = ret;
+
+   return 1;
 }

 static int pvcalls_back_connect(struct xenbus_device *dev,

Re: [PATCH 07/18] xen/pvcalls: implement socket command

[Boris Ostrovsky]

On 05/15/2017 04:35 PM, Stefano Stabellini wrote:

Just reply with success to the other end for now. Delay the allocation
of the actual socket to bind and/or connect.

Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-back.c | 31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index 2b2a49a..2eae096 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -12,12 +12,17 @@
  * GNU General Public License for more details.
  */

+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 

 #include 
 #include 
@@ -65,7 +70,31 @@ static void pvcalls_back_ioworker(struct work_struct *work)
 static int pvcalls_back_socket(struct xenbus_device *dev,
struct xen_pvcalls_request *req)
 {
-   return 0;
+   struct pvcalls_back_priv *priv;
+   int ret;
+   struct xen_pvcalls_response *rsp;
+
+   if (dev == NULL)
+   return 0;
+   priv = dev_get_drvdata(>dev);


This is inconsistent with pvcalls_back_event() tests, where you check 
both for NULL. OTOH, I am not sure a check is needed at all since you've 
just tested these in pvcalls_back_event().



-boris


+
+   if (req->u.socket.domain != AF_INET ||
+   req->u.socket.type != SOCK_STREAM ||
+   (req->u.socket.protocol != 0 &&
+req->u.socket.protocol != AF_INET))
+   ret = -EAFNOSUPPORT;
+   else
+   ret = 0;
+
+   /* leave the actual socket allocation for later */
+
+   rsp = RING_GET_RESPONSE(>ring, priv->ring.rsp_prod_pvt++);
+   rsp->req_id = req->req_id;
+   rsp->cmd = req->cmd;
+   rsp->u.socket.id = req->u.socket.id;
+   rsp->ret = ret;
+
+   return 1;
 }

 static int pvcalls_back_connect(struct xenbus_device *dev,

Re: [PATCH 2/4] ftrace/instances: Clear function triggers when removing instances

[Steven Rostedt]

On Sun, 14 May 2017 01:01:02 +0530
"Naveen N. Rao"  wrote:

> If instance directories are deleted while there are registered function
> triggers:
> 
>   # cd /sys/kernel/debug/tracing/instances
>   # mkdir test
>   # echo "schedule:enable_event:sched:sched_switch" > test/set_ftrace_filter
>   # rmdir test
>   Unable to handle kernel paging request for data at address 0x0008
>   Unable to handle kernel paging request for data at address 0x0008
>   Faulting instruction address: 0xc21edde8
>   Oops: Kernel access of bad area, sig: 11 [#1]
>   SMP NR_CPUS=2048
>   NUMA
>   pSeries
>   Modules linked in: iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 
> iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack 
> nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp tun bridge stp llc kvm 
> iptable_filter fuse binfmt_misc pseries_rng rng_core vmx_crypto ib_iser 
> rdma_cm iw_cm ib_cm ib_core libiscsi scsi_transport_iscsi ip_tables x_tables 
> autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq 
> async_xor async_tx xor raid6_pq libcrc32c multipath virtio_net virtio_blk 
> virtio_pci crc32c_vpmsum virtio_ring virtio
>   CPU: 8 PID: 8694 Comm: rmdir Not tainted 4.11.0-nnr+ #113
>   task: c000bab52800 task.stack: c000baba
>   NIP: c21edde8 LR: c21f0590 CTR: c2119620
>   REGS: c000baba3870 TRAP: 0300   Not tainted  (4.11.0-nnr+)
>   MSR: 80009033 
> CR: 22002422  XER: 2000
>   CFAR: 7fffabb725a8 DAR: 0008 DSISR: 4000 SOFTE: 0
>   GPR00: c220f750 c000baba3af0 c3157e00 
>   GPR04: 0040 00eb 0040 
>   GPR08:  0113  c305db98
>   GPR12: c2119620 cfd42c00  
>   GPR16:    
>   GPR20:   c000bab52e90 
>   GPR24:  00eb 0040 c000baba3bb0
>   GPR28: c0009cb06eb0 c000bab52800 c0009cb06eb0 c000baba3bb0
>   NIP [c21edde8] ring_buffer_lock_reserve+0x8/0x4e0
>   LR [c21f0590] trace_event_buffer_lock_reserve+0xe0/0x1a0
>   Call Trace:
>   [c000baba3af0] [c21f96c8] trace_event_buffer_commit+0x1b8/0x280 
> (unreliable)
>   [c000baba3b60] [c220f750] trace_event_buffer_reserve+0x80/0xd0
>   [c000baba3b90] [c21196b8] 
> trace_event_raw_event_sched_switch+0x98/0x180
>   [c000baba3c10] [c29d9980] __schedule+0x6e0/0xab0
>   [c000baba3ce0] [c2122230] do_task_dead+0x70/0xc0
>   [c000baba3d10] [c20ea9c8] do_exit+0x828/0xd00
>   [c000baba3dd0] [c20eaf70] do_group_exit+0x60/0x100
>   [c000baba3e10] [c20eb034] SyS_exit_group+0x24/0x30
>   [c000baba3e30] [c200bcec] system_call+0x38/0x54
>   Instruction dump:
>   6000 6042 7d244b78 7f63db78 4bffaa09 393efff8 793e0020 3920
>   4bfffecc 6042 3c4c00f7 3842a020 <81230008> 2f89 409e02f0 a14d0008
>   ---[ end trace b917b8985d0e650b ]---
>   Unable to handle kernel paging request for data at address 0x0008
>   Faulting instruction address: 0xc21edde8
>   Unable to handle kernel paging request for data at address 0x0008
>   Faulting instruction address: 0xc21edde8
>   Faulting instruction address: 0xc21edde8
> 
> To address this, let's clear all registered function probes before
> deleting the ftrace instance.
> 
> Reported-by: Michael Ellerman 
> Signed-off-by: Naveen N. Rao 
> ---
>  kernel/trace/ftrace.c | 8 
>  kernel/trace/trace.c  | 1 +
>  kernel/trace/trace.h  | 1 +
>  3 files changed, 10 insertions(+)
> 
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 28dc824ad072..1b96d927a082 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -4256,6 +4256,14 @@ unregister_ftrace_function_probe_func(char *glob, 
> struct trace_array *tr,
>   return ret;
>  }
>  
> +void clear_ftrace_function_probes(struct trace_array *tr)
> +{
> + struct ftrace_func_probe *probe, *n;
> +
> + list_for_each_entry_safe(probe, n, >func_probes, list)
> + unregister_ftrace_function_probe_func(NULL, tr, 
> probe->probe_ops);
> +}
> +
>  static LIST_HEAD(ftrace_commands);
>  static DEFINE_MUTEX(ftrace_cmd_mutex);
>  
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index c4536c449021..3f2aed4ad1ed 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -7550,6 +7550,7 @@ static int instance_rmdir(const char *name)
>   }
>  
>   tracing_set_nop(tr);
> + clear_ftrace_function_probes(tr);
>   event_trace_del_tracer(tr);
>   ftrace_clear_pids(tr);
>   

Re: [PATCH 2/4] ftrace/instances: Clear function triggers when removing instances

[Steven Rostedt]

On Sun, 14 May 2017 01:01:02 +0530
"Naveen N. Rao"  wrote:

> If instance directories are deleted while there are registered function
> triggers:
> 
>   # cd /sys/kernel/debug/tracing/instances
>   # mkdir test
>   # echo "schedule:enable_event:sched:sched_switch" > test/set_ftrace_filter
>   # rmdir test
>   Unable to handle kernel paging request for data at address 0x0008
>   Unable to handle kernel paging request for data at address 0x0008
>   Faulting instruction address: 0xc21edde8
>   Oops: Kernel access of bad area, sig: 11 [#1]
>   SMP NR_CPUS=2048
>   NUMA
>   pSeries
>   Modules linked in: iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 
> iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack 
> nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp tun bridge stp llc kvm 
> iptable_filter fuse binfmt_misc pseries_rng rng_core vmx_crypto ib_iser 
> rdma_cm iw_cm ib_cm ib_core libiscsi scsi_transport_iscsi ip_tables x_tables 
> autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq 
> async_xor async_tx xor raid6_pq libcrc32c multipath virtio_net virtio_blk 
> virtio_pci crc32c_vpmsum virtio_ring virtio
>   CPU: 8 PID: 8694 Comm: rmdir Not tainted 4.11.0-nnr+ #113
>   task: c000bab52800 task.stack: c000baba
>   NIP: c21edde8 LR: c21f0590 CTR: c2119620
>   REGS: c000baba3870 TRAP: 0300   Not tainted  (4.11.0-nnr+)
>   MSR: 80009033 
> CR: 22002422  XER: 2000
>   CFAR: 7fffabb725a8 DAR: 0008 DSISR: 4000 SOFTE: 0
>   GPR00: c220f750 c000baba3af0 c3157e00 
>   GPR04: 0040 00eb 0040 
>   GPR08:  0113  c305db98
>   GPR12: c2119620 cfd42c00  
>   GPR16:    
>   GPR20:   c000bab52e90 
>   GPR24:  00eb 0040 c000baba3bb0
>   GPR28: c0009cb06eb0 c000bab52800 c0009cb06eb0 c000baba3bb0
>   NIP [c21edde8] ring_buffer_lock_reserve+0x8/0x4e0
>   LR [c21f0590] trace_event_buffer_lock_reserve+0xe0/0x1a0
>   Call Trace:
>   [c000baba3af0] [c21f96c8] trace_event_buffer_commit+0x1b8/0x280 
> (unreliable)
>   [c000baba3b60] [c220f750] trace_event_buffer_reserve+0x80/0xd0
>   [c000baba3b90] [c21196b8] 
> trace_event_raw_event_sched_switch+0x98/0x180
>   [c000baba3c10] [c29d9980] __schedule+0x6e0/0xab0
>   [c000baba3ce0] [c2122230] do_task_dead+0x70/0xc0
>   [c000baba3d10] [c20ea9c8] do_exit+0x828/0xd00
>   [c000baba3dd0] [c20eaf70] do_group_exit+0x60/0x100
>   [c000baba3e10] [c20eb034] SyS_exit_group+0x24/0x30
>   [c000baba3e30] [c200bcec] system_call+0x38/0x54
>   Instruction dump:
>   6000 6042 7d244b78 7f63db78 4bffaa09 393efff8 793e0020 3920
>   4bfffecc 6042 3c4c00f7 3842a020 <81230008> 2f89 409e02f0 a14d0008
>   ---[ end trace b917b8985d0e650b ]---
>   Unable to handle kernel paging request for data at address 0x0008
>   Faulting instruction address: 0xc21edde8
>   Unable to handle kernel paging request for data at address 0x0008
>   Faulting instruction address: 0xc21edde8
>   Faulting instruction address: 0xc21edde8
> 
> To address this, let's clear all registered function probes before
> deleting the ftrace instance.
> 
> Reported-by: Michael Ellerman 
> Signed-off-by: Naveen N. Rao 
> ---
>  kernel/trace/ftrace.c | 8 
>  kernel/trace/trace.c  | 1 +
>  kernel/trace/trace.h  | 1 +
>  3 files changed, 10 insertions(+)
> 
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 28dc824ad072..1b96d927a082 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -4256,6 +4256,14 @@ unregister_ftrace_function_probe_func(char *glob, 
> struct trace_array *tr,
>   return ret;
>  }
>  
> +void clear_ftrace_function_probes(struct trace_array *tr)
> +{
> + struct ftrace_func_probe *probe, *n;
> +
> + list_for_each_entry_safe(probe, n, >func_probes, list)
> + unregister_ftrace_function_probe_func(NULL, tr, 
> probe->probe_ops);
> +}
> +
>  static LIST_HEAD(ftrace_commands);
>  static DEFINE_MUTEX(ftrace_cmd_mutex);
>  
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index c4536c449021..3f2aed4ad1ed 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -7550,6 +7550,7 @@ static int instance_rmdir(const char *name)
>   }
>  
>   tracing_set_nop(tr);
> + clear_ftrace_function_probes(tr);
>   event_trace_del_tracer(tr);
>   ftrace_clear_pids(tr);
>   ftrace_destroy_function_files(tr);
> diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
> index 

Re: [PATCH 06/18] xen/pvcalls: handle commands from the frontend

[Boris Ostrovsky]

On 05/15/2017 04:35 PM, Stefano Stabellini wrote:

When the other end notifies us that there are commands to be read
(pvcalls_back_event), wake up the backend thread to parse the command.

The command ring works like most other Xen rings, so use the usual
ring macros to read and write to it. The functions implementing the
commands are empty stubs for now.

Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-back.c | 115 +
 1 file changed, 115 insertions(+)

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index 876e577..2b2a49a 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -62,12 +62,127 @@ static void pvcalls_back_ioworker(struct work_struct *work)
 {
 }

+static int pvcalls_back_socket(struct xenbus_device *dev,
+   struct xen_pvcalls_request *req)
+{
+   return 0;
+}
+
+static int pvcalls_back_connect(struct xenbus_device *dev,
+   struct xen_pvcalls_request *req)
+{
+   return 0;
+}
+
+static int pvcalls_back_release(struct xenbus_device *dev,
+   struct xen_pvcalls_request *req)
+{
+   return 0;
+}
+
+static int pvcalls_back_bind(struct xenbus_device *dev,
+struct xen_pvcalls_request *req)
+{
+   return 0;
+}
+
+static int pvcalls_back_listen(struct xenbus_device *dev,
+  struct xen_pvcalls_request *req)
+{
+   return 0;
+}
+
+static int pvcalls_back_accept(struct xenbus_device *dev,
+  struct xen_pvcalls_request *req)
+{
+   return 0;
+}
+
+static int pvcalls_back_poll(struct xenbus_device *dev,
+struct xen_pvcalls_request *req)
+{
+   return 0;
+}
+
+static int pvcalls_back_handle_cmd(struct xenbus_device *dev,
+  struct xen_pvcalls_request *req)
+{
+   int ret = 0;
+
+   switch (req->cmd) {
+   case PVCALLS_SOCKET:
+   ret = pvcalls_back_socket(dev, req);
+   break;
+   case PVCALLS_CONNECT:
+   ret = pvcalls_back_connect(dev, req);
+   break;
+   case PVCALLS_RELEASE:
+   ret = pvcalls_back_release(dev, req);
+   break;
+   case PVCALLS_BIND:
+   ret = pvcalls_back_bind(dev, req);
+   break;
+   case PVCALLS_LISTEN:
+   ret = pvcalls_back_listen(dev, req);
+   break;
+   case PVCALLS_ACCEPT:
+   ret = pvcalls_back_accept(dev, req);
+   break;
+   case PVCALLS_POLL:
+   ret = pvcalls_back_poll(dev, req);
+   break;
+   default:
+   ret = -ENOTSUPP;
+   break;
+   }
+   return ret;
+}
+
 static void pvcalls_back_work(struct work_struct *work)
 {
+   struct pvcalls_back_priv *priv = container_of(work,
+   struct pvcalls_back_priv, register_work);
+   int notify, notify_all = 0, more = 1;
+   struct xen_pvcalls_request req;
+   struct xenbus_device *dev = priv->dev;
+
+   atomic_set(>work, 1);
+
+   while (more || !atomic_dec_and_test(>work)) {
+   while (RING_HAS_UNCONSUMED_REQUESTS(>ring)) {
+   RING_COPY_REQUEST(>ring,
+ priv->ring.req_cons++,
+ );
+
+   if (pvcalls_back_handle_cmd(dev, ) > 0) {


Can you make handlers make "traditional" returns, i.e. <0 on error and 0 
on success? Or do you really need to distinguish 0 from >0?



+   RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(
+   >ring, notify);
+   notify_all += notify;
+   }
+   }
+
+   if (notify_all)
+   notify_remote_via_irq(priv->irq);
+
+   RING_FINAL_CHECK_FOR_REQUESTS(>ring, more);
+   }
 }

 static irqreturn_t pvcalls_back_event(int irq, void *dev_id)
 {
+   struct xenbus_device *dev = dev_id;
+   struct pvcalls_back_priv *priv = NULL;
+
+   if (dev == NULL)
+   return IRQ_HANDLED;
+
+   priv = dev_get_drvdata(>dev);
+   if (priv == NULL)
+   return IRQ_HANDLED;


These two aren't errors?


+
+   atomic_inc(>work);


Is this really needed? We have a new entry on the ring, so the outer 
loop in pvcalls_back_work() will pick this up (by setting 'more').



-boris


+   queue_work(priv->wq, >register_work);
+
return IRQ_HANDLED;
 }

Re: [PATCH 06/18] xen/pvcalls: handle commands from the frontend

[Boris Ostrovsky]

On 05/15/2017 04:35 PM, Stefano Stabellini wrote:

When the other end notifies us that there are commands to be read
(pvcalls_back_event), wake up the backend thread to parse the command.

The command ring works like most other Xen rings, so use the usual
ring macros to read and write to it. The functions implementing the
commands are empty stubs for now.

Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-back.c | 115 +
 1 file changed, 115 insertions(+)

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index 876e577..2b2a49a 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -62,12 +62,127 @@ static void pvcalls_back_ioworker(struct work_struct *work)
 {
 }

+static int pvcalls_back_socket(struct xenbus_device *dev,
+   struct xen_pvcalls_request *req)
+{
+   return 0;
+}
+
+static int pvcalls_back_connect(struct xenbus_device *dev,
+   struct xen_pvcalls_request *req)
+{
+   return 0;
+}
+
+static int pvcalls_back_release(struct xenbus_device *dev,
+   struct xen_pvcalls_request *req)
+{
+   return 0;
+}
+
+static int pvcalls_back_bind(struct xenbus_device *dev,
+struct xen_pvcalls_request *req)
+{
+   return 0;
+}
+
+static int pvcalls_back_listen(struct xenbus_device *dev,
+  struct xen_pvcalls_request *req)
+{
+   return 0;
+}
+
+static int pvcalls_back_accept(struct xenbus_device *dev,
+  struct xen_pvcalls_request *req)
+{
+   return 0;
+}
+
+static int pvcalls_back_poll(struct xenbus_device *dev,
+struct xen_pvcalls_request *req)
+{
+   return 0;
+}
+
+static int pvcalls_back_handle_cmd(struct xenbus_device *dev,
+  struct xen_pvcalls_request *req)
+{
+   int ret = 0;
+
+   switch (req->cmd) {
+   case PVCALLS_SOCKET:
+   ret = pvcalls_back_socket(dev, req);
+   break;
+   case PVCALLS_CONNECT:
+   ret = pvcalls_back_connect(dev, req);
+   break;
+   case PVCALLS_RELEASE:
+   ret = pvcalls_back_release(dev, req);
+   break;
+   case PVCALLS_BIND:
+   ret = pvcalls_back_bind(dev, req);
+   break;
+   case PVCALLS_LISTEN:
+   ret = pvcalls_back_listen(dev, req);
+   break;
+   case PVCALLS_ACCEPT:
+   ret = pvcalls_back_accept(dev, req);
+   break;
+   case PVCALLS_POLL:
+   ret = pvcalls_back_poll(dev, req);
+   break;
+   default:
+   ret = -ENOTSUPP;
+   break;
+   }
+   return ret;
+}
+
 static void pvcalls_back_work(struct work_struct *work)
 {
+   struct pvcalls_back_priv *priv = container_of(work,
+   struct pvcalls_back_priv, register_work);
+   int notify, notify_all = 0, more = 1;
+   struct xen_pvcalls_request req;
+   struct xenbus_device *dev = priv->dev;
+
+   atomic_set(>work, 1);
+
+   while (more || !atomic_dec_and_test(>work)) {
+   while (RING_HAS_UNCONSUMED_REQUESTS(>ring)) {
+   RING_COPY_REQUEST(>ring,
+ priv->ring.req_cons++,
+ );
+
+   if (pvcalls_back_handle_cmd(dev, ) > 0) {


Can you make handlers make "traditional" returns, i.e. <0 on error and 0 
on success? Or do you really need to distinguish 0 from >0?



+   RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(
+   >ring, notify);
+   notify_all += notify;
+   }
+   }
+
+   if (notify_all)
+   notify_remote_via_irq(priv->irq);
+
+   RING_FINAL_CHECK_FOR_REQUESTS(>ring, more);
+   }
 }

 static irqreturn_t pvcalls_back_event(int irq, void *dev_id)
 {
+   struct xenbus_device *dev = dev_id;
+   struct pvcalls_back_priv *priv = NULL;
+
+   if (dev == NULL)
+   return IRQ_HANDLED;
+
+   priv = dev_get_drvdata(>dev);
+   if (priv == NULL)
+   return IRQ_HANDLED;


These two aren't errors?


+
+   atomic_inc(>work);


Is this really needed? We have a new entry on the ring, so the outer 
loop in pvcalls_back_work() will pick this up (by setting 'more').



-boris


+   queue_work(priv->wq, >register_work);
+
return IRQ_HANDLED;
 }