Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest

[Harald Freudenberger]

On 12/02/2017 02:30 AM, Tony Krowiak wrote:
> On 11/03/2017 04:47 AM, Christian Borntraeger wrote:
>>
>> On 11/02/2017 07:49 PM, Tony Krowiak wrote:
>>> On 11/02/2017 11:53 AM, Christian Borntraeger wrote:
 On 11/02/2017 04:36 PM, Tony Krowiak wrote:
> On 11/02/2017 08:08 AM, Christian Borntraeger wrote:
>> On 10/16/2017 11:25 AM, Martin Schwidefsky wrote:
>>> On Fri, 13 Oct 2017 13:39:04 -0400
>>> Tony Krowiak  wrote:
>>>
 Sets up the following facilities bits to enable the specified AP
 facilities for the guest VM:
   * STFLE.12: Enables the AP Query Configuration Information
   facility. The AP bus running in the guest uses
   the information returned from this instruction
   to configure AP adapters and domains for the
   guest machine.
   * STFLE.15: Indicates the AP facilities test is available.
   The AP bus running in the guest uses the
   information.

 Signed-off-by: Tony Krowiak 
 ---
    arch/s390/tools/gen_facilities.c |    2 ++
    1 files changed, 2 insertions(+), 0 deletions(-)

 diff --git a/arch/s390/tools/gen_facilities.c 
 b/arch/s390/tools/gen_facilities.c
 index 70dd8f1..eeaa7db 100644
 --- a/arch/s390/tools/gen_facilities.c
 +++ b/arch/s390/tools/gen_facilities.c
 @@ -74,8 +74,10 @@ struct facility_def {
    8,  /* enhanced-DAT 1 */
    9,  /* sense-running-status */
    10, /* conditional sske */
 +    12, /* AP query configuration */
    13, /* ipte-range */
    14, /* nonquiescing key-setting */
 +    15, /* AP special-command facility */
    73, /* transactional execution */
    75, /* access-exception-fetch/store indication */
    76, /* msa extension 3 */
>>> With this all KVM guests will always have the AP instructions 
>>> available, no?
>>> In principles I like this approach, but it differs from the way z/VM 
>>> does things,
>>> there the guest will get an exception if it tries to execute an AP 
>>> instruction
>>> if there are no AP devices assigned to the guest. I wonder if there is 
>>> a reason
>>> why z/VM does it the way it does.
>> A good question. For LPAR it seems that you have AP instructions even if 
>> you have
>> no crypto cards.
>>
> I don't believe these facilities control whether or not AP instructions 
> will be available
>
> to the guest.
 This is actually handled by your patch2 enabling the ECA bit.
 I think we must decide if we want to be able to disable these instructions
 via the cpu model. If yes we must then couple the facilities with the 
 enablement.
>>> The ECA.28 bit controls whether instructions are intercepted or interpreted 
>>> - i.e., handled via hardware
>>> virtualization. If set, as is done in patch2, then instructions will be 
>>> interpreted. I don't see how
>>> that affects enabling or disabling AP instructions, unless we don't set 
>>> ECA.28, intercept every instruction
>>> and program check. Am I missing something here?
>> If we do not set ECA.28 these instructions intercept and we (the hypervisor) 
>> can then
>> decide what to do. For example we can give an PIC01 operation exception 
>> (illegal
>> instruction) - thats what we do today.
>>
>> Now: if we want to be able to migrate a guest from a new kernel back to an 
>> old kernel,
>> there must be a way to disable the new behaviour so that the user can 
>> configure a guest
>> that does NOT have these 3 instructions. That means, I want to bind the ap 
>> instruction
>> to a cpu model feature, so that we only enable ECA.28 and the facility bits, 
>> if the
>> feature is enabled in the CPU model. Otherwise we have no control on what 
>> happens
>> when the guest issues these instructions.
>>
>> Imagine what happens if we not do this and you migrate from an identical hw 
>> with an
>> identical libvirt/qemu but from a new kernel to an old kernel:
>>
>> The guest boots starts up on the new kernel
>> guest kernel: drivers/s390/crypto/ap_bus.c  ap_module_init -> 
>> ap_instructions_available
>> checks if the instructions work. They do and now the guest driver assumes 
>> that all
>> instructions will continue to work.
>>
>> Now the guest is migrated back to an old kernel
>> sooner or later the ap_scan_bus kthread will run to scan the bus (or some 
>> crypto operation
>> is started) and the instruction will be rejected with a PIC01. kernel oops.
> There are several scenarios that have to be accounted for, such as:
> * Migrating from a linux host where both the 

[f2fs-dev] [PATCH] f2fs: release reserved blocks for quota

[LiFan]

Quota has been modified during inc_valid_block_count(), but not in
truncate process. This patch adds it.

Signed-off-by: Fan li 
---
 fs/f2fs/f2fs.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 82f1dc3..71fbba96 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1619,7 +1619,9 @@ static inline void dec_valid_block_count(struct 
f2fs_sb_info *sbi,
sbi->current_reserved_blocks = min(sbi->reserved_blocks,
sbi->current_reserved_blocks + count);
spin_unlock(>stat_lock);
+
f2fs_i_blocks_write(inode, count, false, true);
+   dquot_release_reservation_block(inode, count);
 }
 
 static inline void inc_page_count(struct f2fs_sb_info *sbi, int count_type)
-- 
2.7.4

Re: [RFC 19/19] s390/facilities: enable AP facilities needed by guest

[Harald Freudenberger]

On 12/02/2017 02:30 AM, Tony Krowiak wrote:
> On 11/03/2017 04:47 AM, Christian Borntraeger wrote:
>>
>> On 11/02/2017 07:49 PM, Tony Krowiak wrote:
>>> On 11/02/2017 11:53 AM, Christian Borntraeger wrote:
 On 11/02/2017 04:36 PM, Tony Krowiak wrote:
> On 11/02/2017 08:08 AM, Christian Borntraeger wrote:
>> On 10/16/2017 11:25 AM, Martin Schwidefsky wrote:
>>> On Fri, 13 Oct 2017 13:39:04 -0400
>>> Tony Krowiak  wrote:
>>>
 Sets up the following facilities bits to enable the specified AP
 facilities for the guest VM:
   * STFLE.12: Enables the AP Query Configuration Information
   facility. The AP bus running in the guest uses
   the information returned from this instruction
   to configure AP adapters and domains for the
   guest machine.
   * STFLE.15: Indicates the AP facilities test is available.
   The AP bus running in the guest uses the
   information.

 Signed-off-by: Tony Krowiak 
 ---
    arch/s390/tools/gen_facilities.c |    2 ++
    1 files changed, 2 insertions(+), 0 deletions(-)

 diff --git a/arch/s390/tools/gen_facilities.c 
 b/arch/s390/tools/gen_facilities.c
 index 70dd8f1..eeaa7db 100644
 --- a/arch/s390/tools/gen_facilities.c
 +++ b/arch/s390/tools/gen_facilities.c
 @@ -74,8 +74,10 @@ struct facility_def {
    8,  /* enhanced-DAT 1 */
    9,  /* sense-running-status */
    10, /* conditional sske */
 +    12, /* AP query configuration */
    13, /* ipte-range */
    14, /* nonquiescing key-setting */
 +    15, /* AP special-command facility */
    73, /* transactional execution */
    75, /* access-exception-fetch/store indication */
    76, /* msa extension 3 */
>>> With this all KVM guests will always have the AP instructions 
>>> available, no?
>>> In principles I like this approach, but it differs from the way z/VM 
>>> does things,
>>> there the guest will get an exception if it tries to execute an AP 
>>> instruction
>>> if there are no AP devices assigned to the guest. I wonder if there is 
>>> a reason
>>> why z/VM does it the way it does.
>> A good question. For LPAR it seems that you have AP instructions even if 
>> you have
>> no crypto cards.
>>
> I don't believe these facilities control whether or not AP instructions 
> will be available
>
> to the guest.
 This is actually handled by your patch2 enabling the ECA bit.
 I think we must decide if we want to be able to disable these instructions
 via the cpu model. If yes we must then couple the facilities with the 
 enablement.
>>> The ECA.28 bit controls whether instructions are intercepted or interpreted 
>>> - i.e., handled via hardware
>>> virtualization. If set, as is done in patch2, then instructions will be 
>>> interpreted. I don't see how
>>> that affects enabling or disabling AP instructions, unless we don't set 
>>> ECA.28, intercept every instruction
>>> and program check. Am I missing something here?
>> If we do not set ECA.28 these instructions intercept and we (the hypervisor) 
>> can then
>> decide what to do. For example we can give an PIC01 operation exception 
>> (illegal
>> instruction) - thats what we do today.
>>
>> Now: if we want to be able to migrate a guest from a new kernel back to an 
>> old kernel,
>> there must be a way to disable the new behaviour so that the user can 
>> configure a guest
>> that does NOT have these 3 instructions. That means, I want to bind the ap 
>> instruction
>> to a cpu model feature, so that we only enable ECA.28 and the facility bits, 
>> if the
>> feature is enabled in the CPU model. Otherwise we have no control on what 
>> happens
>> when the guest issues these instructions.
>>
>> Imagine what happens if we not do this and you migrate from an identical hw 
>> with an
>> identical libvirt/qemu but from a new kernel to an old kernel:
>>
>> The guest boots starts up on the new kernel
>> guest kernel: drivers/s390/crypto/ap_bus.c  ap_module_init -> 
>> ap_instructions_available
>> checks if the instructions work. They do and now the guest driver assumes 
>> that all
>> instructions will continue to work.
>>
>> Now the guest is migrated back to an old kernel
>> sooner or later the ap_scan_bus kthread will run to scan the bus (or some 
>> crypto operation
>> is started) and the instruction will be rejected with a PIC01. kernel oops.
> There are several scenarios that have to be accounted for, such as:
> * Migrating from a linux host where both the KVM/kernel and QEMU support AP 
> matrix
>   devices to a 

[f2fs-dev] [PATCH] f2fs: release reserved blocks for quota

[LiFan]

Quota has been modified during inc_valid_block_count(), but not in
truncate process. This patch adds it.

Signed-off-by: Fan li 
---
 fs/f2fs/f2fs.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 82f1dc3..71fbba96 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1619,7 +1619,9 @@ static inline void dec_valid_block_count(struct 
f2fs_sb_info *sbi,
sbi->current_reserved_blocks = min(sbi->reserved_blocks,
sbi->current_reserved_blocks + count);
spin_unlock(>stat_lock);
+
f2fs_i_blocks_write(inode, count, false, true);
+   dquot_release_reservation_block(inode, count);
 }
 
 static inline void inc_page_count(struct f2fs_sb_info *sbi, int count_type)
-- 
2.7.4

[PATCH] SCSI: run queue if SCSI device queue isn't ready and queue is idle

[Ming Lei]

Before commit 0df21c86bdbf ("scsi: implement .get_budget and .put_budget
for blk-mq"), we run queue after 3ms if queue is idle and SCSI device
queue isn't ready, which is done in handling BLK_STS_RESOURCE. After
commit 0df21c86bdbf is introduced, queue won't be run any more under
this situation.

IO hang is observed when timeout happened, and this patch fixes the IO
hang issue by running queue after delay in scsi_dev_queue_ready, just like
non-mq. This issue can be triggered by the following script[1].

There is another issue which can be covered by running idle queue:
when .get_budget() is called on request coming from hctx->dispatch_list,
if one request just completes during .get_budget(), we can't depend on
SCSI's restart to make progress any more. This patch fixes the race too.

With this patch, we basically recover to previous behaviour(before commit
0df21c86bdbf) of handling idle queue when running out of resource.

[1] script for test/verify SCSI timeout
rmmod scsi_debug
modprobe scsi_debug max_queue=1

DEVICE=`ls -d 
/sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | 
xargs basename`
DISK_DIR=`ls -d /sys/block/$DEVICE/device/scsi_disk/*`

echo "using scsi device $DEVICE"
echo "-1" >/sys/bus/pseudo/drivers/scsi_debug/every_nth
echo "temporary write through" >$DISK_DIR/cache_type
echo "128" >/sys/bus/pseudo/drivers/scsi_debug/opts
echo none > /sys/block/$DEVICE/queue/scheduler
dd if=/dev/$DEVICE of=/dev/null bs=1M iflag=direct count=1 &
sleep 5
echo "0" >/sys/bus/pseudo/drivers/scsi_debug/opts
wait
echo "SUCCESS"

Fixes: 0df21c86bdbf ("scsi: implement .get_budget and .put_budget for blk-mq")
Signed-off-by: Ming Lei 
---
 drivers/scsi/scsi_lib.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index db9556662e27..1816dd8259b3 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1967,6 +1967,8 @@ static bool scsi_mq_get_budget(struct blk_mq_hw_ctx *hctx)
 out_put_device:
put_device(>sdev_gendev);
 out:
+   if (atomic_read(>device_busy) == 0 && !scsi_device_blocked(sdev))
+   blk_mq_delay_run_hw_queue(hctx, SCSI_QUEUE_DELAY);
return false;
 }
 
-- 
2.9.5

[PATCH] SCSI: run queue if SCSI device queue isn't ready and queue is idle

[Ming Lei]

Before commit 0df21c86bdbf ("scsi: implement .get_budget and .put_budget
for blk-mq"), we run queue after 3ms if queue is idle and SCSI device
queue isn't ready, which is done in handling BLK_STS_RESOURCE. After
commit 0df21c86bdbf is introduced, queue won't be run any more under
this situation.

IO hang is observed when timeout happened, and this patch fixes the IO
hang issue by running queue after delay in scsi_dev_queue_ready, just like
non-mq. This issue can be triggered by the following script[1].

There is another issue which can be covered by running idle queue:
when .get_budget() is called on request coming from hctx->dispatch_list,
if one request just completes during .get_budget(), we can't depend on
SCSI's restart to make progress any more. This patch fixes the race too.

With this patch, we basically recover to previous behaviour(before commit
0df21c86bdbf) of handling idle queue when running out of resource.

[1] script for test/verify SCSI timeout
rmmod scsi_debug
modprobe scsi_debug max_queue=1

DEVICE=`ls -d 
/sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | 
xargs basename`
DISK_DIR=`ls -d /sys/block/$DEVICE/device/scsi_disk/*`

echo "using scsi device $DEVICE"
echo "-1" >/sys/bus/pseudo/drivers/scsi_debug/every_nth
echo "temporary write through" >$DISK_DIR/cache_type
echo "128" >/sys/bus/pseudo/drivers/scsi_debug/opts
echo none > /sys/block/$DEVICE/queue/scheduler
dd if=/dev/$DEVICE of=/dev/null bs=1M iflag=direct count=1 &
sleep 5
echo "0" >/sys/bus/pseudo/drivers/scsi_debug/opts
wait
echo "SUCCESS"

Fixes: 0df21c86bdbf ("scsi: implement .get_budget and .put_budget for blk-mq")
Signed-off-by: Ming Lei 
---
 drivers/scsi/scsi_lib.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index db9556662e27..1816dd8259b3 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1967,6 +1967,8 @@ static bool scsi_mq_get_budget(struct blk_mq_hw_ctx *hctx)
 out_put_device:
put_device(>sdev_gendev);
 out:
+   if (atomic_read(>device_busy) == 0 && !scsi_device_blocked(sdev))
+   blk_mq_delay_run_hw_queue(hctx, SCSI_QUEUE_DELAY);
return false;
 }
 
-- 
2.9.5

Re: [PATCH 4.14 00/95] 4.14.4-stable review

[Greg Kroah-Hartman]

On Tue, Dec 05, 2017 at 12:31:40PM +0530, Naresh Kamboju wrote:
> On 4 December 2017 at 21:29, Greg Kroah-Hartman
>  wrote:
> > This is the start of the stable review cycle for the 4.14.4 release.
> > There are 95 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Dec  6 16:00:27 UTC 2017.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.14.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
> 
> Results from Linaro’s test farm.
> No regressions on arm64, arm and x86_64.

Thanks for testing all 3 of these releases and letting me know.

greg k-h

Re: [PATCH 4.14 00/95] 4.14.4-stable review

[Greg Kroah-Hartman]

On Tue, Dec 05, 2017 at 12:31:40PM +0530, Naresh Kamboju wrote:
> On 4 December 2017 at 21:29, Greg Kroah-Hartman
>  wrote:
> > This is the start of the stable review cycle for the 4.14.4 release.
> > There are 95 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Dec  6 16:00:27 UTC 2017.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.14.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
> 
> Results from Linaro’s test farm.
> No regressions on arm64, arm and x86_64.

Thanks for testing all 3 of these releases and letting me know.

greg k-h

Re: Writing "+pids" to cgroup.subtree_control flie yields EINVAL

[Michael Kerrisk (man-pages)]

[dropping Lennart into CC]

Hello Tejun,

On 12/04/2017 10:47 PM, Tejun Heo wrote:
> Hello, Michael.
> 
> On Mon, Dec 04, 2017 at 10:35:13PM +0100, Michael Kerrisk (man-pages) wrote:
>> I was trying to do some simple testing ot the CPU controller
>> that is merged into 4.15, and ran immediately into some confusion.
>> In the root cgroup on a freshly booted 4.150-rc1, I try the following:
>>
>> # pwd
>> /sys/fs/cgroup/unified
>> # echo '+cpu' > cgroup.subtree_control 
>> sh: echo: write error: Invalid argument
>>
>> What am I missing> I presume I'm missing something obvious, although
>> nothing jumped out at me as I read the cgroups-v2.txt file.
> 
> Checking whether I messed up something really basic... hmmm doesn't
> seem that way.  What do /sys/fs/cgroup/unified/cgroup.controllers and
> /proc/cgroups say?

Oh -- they're all sensible:

In the root cgroup:

# cat cgroup.controllers 
cpu io memory pids

$ cat /proc/cgroups 
#subsys_namehierarchy   num_cgroups enabled
cpuset  0   142 1
cpu 0   142 1
cpuacct 0   142 1
blkio   0   142 1
memory  0   142 1
devices 0   142 1
freezer 0   142 1
net_cls 0   142 1
perf_event  0   142 1
net_prio0   142 1
hugetlb 0   142 1
pids0   142 1

But, I through some trial and error and printk() I worked out

a) If I first move all tasks to the root cgroup, then I can
write '+cpu' to the cgroup.subtree_control file in the root
cgroup.

b) The reason for my initial problems was this test in
the kernel in cpu_cgroup_can_attach():

#ifdef CONFIG_RT_GROUP_SCHED
if (!sched_rt_can_attach(css_tg(css), task))
return -EINVAL;
#else
/* We don't support RT-tasks being in separate groups */
if (task->sched_class != _sched_class)
return -EINVAL;
#endif

I don't have CONFIG_RT_GROUP_SCHED, and the second 'if' was yielding
false because of some SCHED_RR processes that are in some of the nonroot
cgroups created by systemd, namely:

# ps ax -L -o 'pid tid cls rtprio comm'|grep RR
  685   723  RR 99 rtkit-daemon
  972   979  RR  5 alsa-sink-ALC26
  972   982  RR  5 alsa-source-ALC
 1594  1597  RR  5 alsa-sink-ALC26
 1594  1600  RR  5 alsa-source-ALC

So, one solution is to move those processes to the root cgroup,
and then it's possible to write '+pids' to cgroup.subtree_control.

Is enabling CONFIG_RT_GROUP_SCHED also a solution? (I have
not had a chance to test that yet.)

Anyway, it seems like this should be documented somewhere in the
kernel Documentation files, since it may be that others will run
into this as well. I'm not quite sure what should be added to the
documentation. Do you have some idea?

Thanks,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: Writing "+pids" to cgroup.subtree_control flie yields EINVAL

[Michael Kerrisk (man-pages)]

[dropping Lennart into CC]

Hello Tejun,

On 12/04/2017 10:47 PM, Tejun Heo wrote:
> Hello, Michael.
> 
> On Mon, Dec 04, 2017 at 10:35:13PM +0100, Michael Kerrisk (man-pages) wrote:
>> I was trying to do some simple testing ot the CPU controller
>> that is merged into 4.15, and ran immediately into some confusion.
>> In the root cgroup on a freshly booted 4.150-rc1, I try the following:
>>
>> # pwd
>> /sys/fs/cgroup/unified
>> # echo '+cpu' > cgroup.subtree_control 
>> sh: echo: write error: Invalid argument
>>
>> What am I missing> I presume I'm missing something obvious, although
>> nothing jumped out at me as I read the cgroups-v2.txt file.
> 
> Checking whether I messed up something really basic... hmmm doesn't
> seem that way.  What do /sys/fs/cgroup/unified/cgroup.controllers and
> /proc/cgroups say?

Oh -- they're all sensible:

In the root cgroup:

# cat cgroup.controllers 
cpu io memory pids

$ cat /proc/cgroups 
#subsys_namehierarchy   num_cgroups enabled
cpuset  0   142 1
cpu 0   142 1
cpuacct 0   142 1
blkio   0   142 1
memory  0   142 1
devices 0   142 1
freezer 0   142 1
net_cls 0   142 1
perf_event  0   142 1
net_prio0   142 1
hugetlb 0   142 1
pids0   142 1

But, I through some trial and error and printk() I worked out

a) If I first move all tasks to the root cgroup, then I can
write '+cpu' to the cgroup.subtree_control file in the root
cgroup.

b) The reason for my initial problems was this test in
the kernel in cpu_cgroup_can_attach():

#ifdef CONFIG_RT_GROUP_SCHED
if (!sched_rt_can_attach(css_tg(css), task))
return -EINVAL;
#else
/* We don't support RT-tasks being in separate groups */
if (task->sched_class != _sched_class)
return -EINVAL;
#endif

I don't have CONFIG_RT_GROUP_SCHED, and the second 'if' was yielding
false because of some SCHED_RR processes that are in some of the nonroot
cgroups created by systemd, namely:

# ps ax -L -o 'pid tid cls rtprio comm'|grep RR
  685   723  RR 99 rtkit-daemon
  972   979  RR  5 alsa-sink-ALC26
  972   982  RR  5 alsa-source-ALC
 1594  1597  RR  5 alsa-sink-ALC26
 1594  1600  RR  5 alsa-source-ALC

So, one solution is to move those processes to the root cgroup,
and then it's possible to write '+pids' to cgroup.subtree_control.

Is enabling CONFIG_RT_GROUP_SCHED also a solution? (I have
not had a chance to test that yet.)

Anyway, it seems like this should be documented somewhere in the
kernel Documentation files, since it may be that others will run
into this as well. I'm not quite sure what should be added to the
documentation. Do you have some idea?

Thanks,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH v2 0/4] lockdep/crossrelease: Apply crossrelease to page locks

[Matthew Wilcox]

On Tue, Dec 05, 2017 at 03:19:46PM +0900, Byungchul Park wrote:
> On 12/5/2017 2:46 PM, Byungchul Park wrote:
> > On 12/5/2017 2:30 PM, Matthew Wilcox wrote:
> > > On Mon, Dec 04, 2017 at 02:16:19PM +0900, Byungchul Park wrote:
> > > > For now, wait_for_completion() / complete() works with lockdep, add
> > > > lock_page() / unlock_page() and its family to lockdep support.
> > > > 
> > > > Changes from v1
> > > >   - Move lockdep_map_cross outside of page_ext to make it flexible
> > > >   - Prevent allocating lockdep_map per page by default
> > > >   - Add a boot parameter allowing the allocation for debugging
> > > > 
> > > > Byungchul Park (4):
> > > >    lockdep: Apply crossrelease to PG_locked locks
> > > >    lockdep: Apply lock_acquire(release) on __Set(__Clear)PageLocked
> > > >    lockdep: Move data of CONFIG_LOCKDEP_PAGELOCK from page to page_ext
> > > >    lockdep: Add a boot parameter enabling to track page locks using
> > > >  lockdep and disable it by default
> > > 
> > > I don't like the way you've structured this patch series; first adding
> > > the lockdep map to struct page, then moving it to page_ext.
> > 
> > Hello,
> > 
> > I will make them into one patch.
> 
> I've thought it more.
> 
> Actually I did it because I thought I'd better make it into two
> patches since it makes reviewers easier to review. It doesn't matter
> which one I choose, but I prefer to split it.

I don't know whether it's better to make it all one patch or split it
into multiple patches.  But it makes no sense to introduce it in struct
page, then move it to struct page_ext.

Re: [PATCH v2 0/4] lockdep/crossrelease: Apply crossrelease to page locks

[Matthew Wilcox]

On Tue, Dec 05, 2017 at 03:19:46PM +0900, Byungchul Park wrote:
> On 12/5/2017 2:46 PM, Byungchul Park wrote:
> > On 12/5/2017 2:30 PM, Matthew Wilcox wrote:
> > > On Mon, Dec 04, 2017 at 02:16:19PM +0900, Byungchul Park wrote:
> > > > For now, wait_for_completion() / complete() works with lockdep, add
> > > > lock_page() / unlock_page() and its family to lockdep support.
> > > > 
> > > > Changes from v1
> > > >   - Move lockdep_map_cross outside of page_ext to make it flexible
> > > >   - Prevent allocating lockdep_map per page by default
> > > >   - Add a boot parameter allowing the allocation for debugging
> > > > 
> > > > Byungchul Park (4):
> > > >    lockdep: Apply crossrelease to PG_locked locks
> > > >    lockdep: Apply lock_acquire(release) on __Set(__Clear)PageLocked
> > > >    lockdep: Move data of CONFIG_LOCKDEP_PAGELOCK from page to page_ext
> > > >    lockdep: Add a boot parameter enabling to track page locks using
> > > >  lockdep and disable it by default
> > > 
> > > I don't like the way you've structured this patch series; first adding
> > > the lockdep map to struct page, then moving it to page_ext.
> > 
> > Hello,
> > 
> > I will make them into one patch.
> 
> I've thought it more.
> 
> Actually I did it because I thought I'd better make it into two
> patches since it makes reviewers easier to review. It doesn't matter
> which one I choose, but I prefer to split it.

I don't know whether it's better to make it all one patch or split it
into multiple patches.  But it makes no sense to introduce it in struct
page, then move it to struct page_ext.

Re: [PATCH v3 1/1] at24: support eeproms that do not auto-rollover reads.

[Sakari Ailus]

On Mon, Dec 04, 2017 at 05:24:33PM -0500, Sven Van Asbroeck wrote:
> > If this is truly specific to at24, then vendor prefix would be appropriate,
> > plus it'd go to an at24 specific binding file. However if it isn't I'd just
> > remove the above sentence. I guess the latter?
> 
> Yes, no-read-rollover is truly specific to at24.c, because it applies only
> to i2c multi-address chips. The at25 is spi based so cannot have multiple
> addresses.
> 
> So yes, "at24,no-read-rollover" would perhaps be a better name.
> 
> Regarding an at24 specific binding file. You're saying I should create
> Documentation/devicetree/bindings/eeprom/at24.txt ? Should I indicate
> that at24.txt "inherits from" eeprom.txt? Note that at25.txt does not
> currently do this.

Hmm. I actually missed we didn't have one to begin with. at25.txt exists
and it documents a number of properties specific to at25, so if at24 will
have an at24-specific property, then I think it should go to a separate
file.

Aren't there really other chips which need this? It'd be (a little bit)
easier to just remove the sentence. :-)

-- 
Regards,

Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH v3 1/1] at24: support eeproms that do not auto-rollover reads.

[Sakari Ailus]

On Mon, Dec 04, 2017 at 05:24:33PM -0500, Sven Van Asbroeck wrote:
> > If this is truly specific to at24, then vendor prefix would be appropriate,
> > plus it'd go to an at24 specific binding file. However if it isn't I'd just
> > remove the above sentence. I guess the latter?
> 
> Yes, no-read-rollover is truly specific to at24.c, because it applies only
> to i2c multi-address chips. The at25 is spi based so cannot have multiple
> addresses.
> 
> So yes, "at24,no-read-rollover" would perhaps be a better name.
> 
> Regarding an at24 specific binding file. You're saying I should create
> Documentation/devicetree/bindings/eeprom/at24.txt ? Should I indicate
> that at24.txt "inherits from" eeprom.txt? Note that at25.txt does not
> currently do this.

Hmm. I actually missed we didn't have one to begin with. at25.txt exists
and it documents a number of properties specific to at25, so if at24 will
have an at24-specific property, then I think it should go to a separate
file.

Aren't there really other chips which need this? It'd be (a little bit)
easier to just remove the sentence. :-)

-- 
Regards,

Sakari Ailus
sakari.ai...@linux.intel.com

Re: [PATCH v2] mmap.2: MAP_FIXED updated documentation

[John Hubbard]

On 12/04/2017 11:08 PM, Michal Hocko wrote:
> On Mon 04-12-17 18:52:27, John Hubbard wrote:
>> On 12/04/2017 03:31 AM, Mike Rapoport wrote:
>>> On Sun, Dec 03, 2017 at 06:14:11PM -0800, john.hubb...@gmail.com wrote:
 From: John Hubbard 

>> [...]
 +.IP
 +Given the above limitations, one of the very few ways to use this option
 +safely is: mmap() a region, without specifying MAP_FIXED. Then, within 
 that
 +region, call mmap(MAP_FIXED) to suballocate regions. This avoids both the
 +portability problem (because the first mmap call lets the kernel pick the
 +address), and the address space corruption problem (because the region 
 being
 +overwritten is already owned by the calling thread).
>>>
>>> Maybe "address space corruption problem caused by implicit calls to mmap"?
>>> The region allocated with the first mmap is not exactly owned by the
>>> thread and a multi-thread application can still corrupt its memory if
>>> different threads use mmap(MAP_FIXED) for overlapping regions.
>>>
>>> My 2 cents.
>>>
>>
>> Hi Mike,
>>
>> Yes, thanks for picking through this, and I agree that the above is 
>> misleading.
>> It should definitely not use the word "owned" at all. Re-doing the whole 
>> paragraph in order to make it all fit together nicely, I get this:
>>
>> "Given the above limitations, one of the very few ways to use this option
>> safely is: mmap() an enclosing region, without specifying MAP_FIXED.
>> Then, within that region, call mmap(MAP_FIXED) to suballocate regions
>> within the enclosing region. This avoids both the portability problem 
>> (because the first mmap call lets the kernel pick the address), and the 
>> address space corruption problem (because implicit calls to mmap will 
>> not affect the already-mapped enclosing region)."
>>
>> ...how's that sound to you? I'll post a v3 soon with this.
> 
> It sounds to me you are trying to tell way to much while actually being
> a bit misleading. Even sub-range MAP_FIXED is not multi-thread safe.
> 
> Really the more corner cases you will try to cover the worse the end
> result will end up. I would just try to be simple here and mention the
> address space corruption issues you've had earlier and be done with it.
> Maybe add a note that some architectures might need a special alignement
> and fail if it is not the case but nothing really specific.
> 

Sure, I can drop the "how to use this safely" section.  It seemed like a good
idea at the time... :)

thanks,
John Hubbard
NVIDIA

Re: [PATCH v2] mmap.2: MAP_FIXED updated documentation

[John Hubbard]

On 12/04/2017 11:08 PM, Michal Hocko wrote:
> On Mon 04-12-17 18:52:27, John Hubbard wrote:
>> On 12/04/2017 03:31 AM, Mike Rapoport wrote:
>>> On Sun, Dec 03, 2017 at 06:14:11PM -0800, john.hubb...@gmail.com wrote:
 From: John Hubbard 

>> [...]
 +.IP
 +Given the above limitations, one of the very few ways to use this option
 +safely is: mmap() a region, without specifying MAP_FIXED. Then, within 
 that
 +region, call mmap(MAP_FIXED) to suballocate regions. This avoids both the
 +portability problem (because the first mmap call lets the kernel pick the
 +address), and the address space corruption problem (because the region 
 being
 +overwritten is already owned by the calling thread).
>>>
>>> Maybe "address space corruption problem caused by implicit calls to mmap"?
>>> The region allocated with the first mmap is not exactly owned by the
>>> thread and a multi-thread application can still corrupt its memory if
>>> different threads use mmap(MAP_FIXED) for overlapping regions.
>>>
>>> My 2 cents.
>>>
>>
>> Hi Mike,
>>
>> Yes, thanks for picking through this, and I agree that the above is 
>> misleading.
>> It should definitely not use the word "owned" at all. Re-doing the whole 
>> paragraph in order to make it all fit together nicely, I get this:
>>
>> "Given the above limitations, one of the very few ways to use this option
>> safely is: mmap() an enclosing region, without specifying MAP_FIXED.
>> Then, within that region, call mmap(MAP_FIXED) to suballocate regions
>> within the enclosing region. This avoids both the portability problem 
>> (because the first mmap call lets the kernel pick the address), and the 
>> address space corruption problem (because implicit calls to mmap will 
>> not affect the already-mapped enclosing region)."
>>
>> ...how's that sound to you? I'll post a v3 soon with this.
> 
> It sounds to me you are trying to tell way to much while actually being
> a bit misleading. Even sub-range MAP_FIXED is not multi-thread safe.
> 
> Really the more corner cases you will try to cover the worse the end
> result will end up. I would just try to be simple here and mention the
> address space corruption issues you've had earlier and be done with it.
> Maybe add a note that some architectures might need a special alignement
> and fail if it is not the case but nothing really specific.
> 

Sure, I can drop the "how to use this safely" section.  It seemed like a good
idea at the time... :)

thanks,
John Hubbard
NVIDIA

Re: [PATCH v2] mmap.2: MAP_FIXED updated documentation

[John Hubbard]

On 12/04/2017 11:05 PM, Michal Hocko wrote:
> On Mon 04-12-17 18:14:18, John Hubbard wrote:
>> On 12/04/2017 02:55 AM, Cyril Hrubis wrote:
>>> Hi!
>>> I know that we are not touching the rest of the existing description for
>>> MAP_FIXED however the second sentence in the manual page says that "addr
>>> must be a multiple of the page size." Which however is misleading as
>>> this is not enough on some architectures. Code in the wild seems to
>>> (mis)use SHMLBA for aligment purposes but I'm not sure that we should
>>> advise something like that in the manpages.
>>>
>>> So what about something as:
>>>
>>> "addr must be suitably aligned, for most architectures multiple of page
>>> size is sufficient, however some may impose additional restrictions for
>>> page mapping addresses."
>>>
>>
>> Hi Cyril,
>>
>> Right, so I've been looking into this today, and I think we can go a bit
>> further than that, even. The kernel, as far back as the *original* git
>> commit in 2005, implements mmap on ARM by requiring that the address is
>> aligned to SHMLBA:
>>
>> arch/arm/mm/mmap.c:50:
>>
>>  if (flags & MAP_FIXED) {
>>  if (aliasing && flags & MAP_SHARED &&
>>  (addr - (pgoff << PAGE_SHIFT)) & (SHMLBA - 1))
>>  return -EINVAL;
>>  return addr;
>>  }
>>
>> So, given that this has been the implementation for the last 12+ years (and
>> probably the whole time, in fact), I think we can be bold enough to use this
>> wording for the second sentence of MAP_FIXED:
>>
>> "addr must be a multiple of SHMLBA (), which in turn is either
>> the system page size (on many architectures) or a multiple of the system
>> page size (on some architectures)."
>>
>> What do you think?
> 
> I am not sure this is a good idea. This is pulling way too many
> implementation details into the man page IMHO. Note that your wording is
> even incorrect because this applies only to shared mappings and on some
> architectures it even requires special memory regions. We do not want
> all that in the man page...
> 

Hi Michal,

OK, so it sounds like Cyril's original wording would be just about right,
after all, like this?

"addr must be suitably aligned. For most architectures multiple of page
size is sufficient; however, some may impose additional restrictions."

(It does seem unfortunate that the man page cannot help the programmer
actually write correct code here. He or she is forced to read the kernel
implementation, in order to figure out the true alignment rules. I was
hoping we could avoid that.)

thanks,
John Hubbard
NVIDIA

Re: [PATCH v2] mmap.2: MAP_FIXED updated documentation

[John Hubbard]

On 12/04/2017 11:05 PM, Michal Hocko wrote:
> On Mon 04-12-17 18:14:18, John Hubbard wrote:
>> On 12/04/2017 02:55 AM, Cyril Hrubis wrote:
>>> Hi!
>>> I know that we are not touching the rest of the existing description for
>>> MAP_FIXED however the second sentence in the manual page says that "addr
>>> must be a multiple of the page size." Which however is misleading as
>>> this is not enough on some architectures. Code in the wild seems to
>>> (mis)use SHMLBA for aligment purposes but I'm not sure that we should
>>> advise something like that in the manpages.
>>>
>>> So what about something as:
>>>
>>> "addr must be suitably aligned, for most architectures multiple of page
>>> size is sufficient, however some may impose additional restrictions for
>>> page mapping addresses."
>>>
>>
>> Hi Cyril,
>>
>> Right, so I've been looking into this today, and I think we can go a bit
>> further than that, even. The kernel, as far back as the *original* git
>> commit in 2005, implements mmap on ARM by requiring that the address is
>> aligned to SHMLBA:
>>
>> arch/arm/mm/mmap.c:50:
>>
>>  if (flags & MAP_FIXED) {
>>  if (aliasing && flags & MAP_SHARED &&
>>  (addr - (pgoff << PAGE_SHIFT)) & (SHMLBA - 1))
>>  return -EINVAL;
>>  return addr;
>>  }
>>
>> So, given that this has been the implementation for the last 12+ years (and
>> probably the whole time, in fact), I think we can be bold enough to use this
>> wording for the second sentence of MAP_FIXED:
>>
>> "addr must be a multiple of SHMLBA (), which in turn is either
>> the system page size (on many architectures) or a multiple of the system
>> page size (on some architectures)."
>>
>> What do you think?
> 
> I am not sure this is a good idea. This is pulling way too many
> implementation details into the man page IMHO. Note that your wording is
> even incorrect because this applies only to shared mappings and on some
> architectures it even requires special memory regions. We do not want
> all that in the man page...
> 

Hi Michal,

OK, so it sounds like Cyril's original wording would be just about right,
after all, like this?

"addr must be suitably aligned. For most architectures multiple of page
size is sufficient; however, some may impose additional restrictions."

(It does seem unfortunate that the man page cannot help the programmer
actually write correct code here. He or she is forced to read the kernel
implementation, in order to figure out the true alignment rules. I was
hoping we could avoid that.)

thanks,
John Hubbard
NVIDIA

Re: [PATCH v3 13/16] iommu/intel-svm: notify page request to guest

[Lu Baolu]

Hi,

On 11/18/2017 02:55 AM, Jacob Pan wrote:
> If the source device of a page request has its PASID table pointer
> bond to a guest, the first level page tables are owned by the guest.
> In this case, we shall let guest OS to manage page fault.
>
> This patch uses the IOMMU fault notification API to send notifications,
> possibly via VFIO, to the guest OS. Once guest pages are fault in, guest
> will issue page response which will be passed down via the invalidation
> passdown APIs.
>
> Signed-off-by: Jacob Pan 
> Signed-off-by: Ashok Raj 
> ---
>  drivers/iommu/intel-svm.c | 80 
> ++-
>  include/linux/iommu.h |  1 +
>  2 files changed, 74 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
> index f6697e5..77c25d8 100644
> --- a/drivers/iommu/intel-svm.c
> +++ b/drivers/iommu/intel-svm.c
> @@ -555,6 +555,71 @@ static bool is_canonical_address(u64 addr)
>   return (((saddr << shift) >> shift) == saddr);
>  }
>  
> +static int prq_to_iommu_prot(struct page_req_dsc *req)
> +{
> + int prot = 0;
> +
> + if (req->rd_req)
> + prot |= IOMMU_FAULT_READ;
> + if (req->wr_req)
> + prot |= IOMMU_FAULT_WRITE;
> + if (req->exe_req)
> + prot |= IOMMU_FAULT_EXEC;
> + if (req->priv_req)
> + prot |= IOMMU_FAULT_PRIV;
> +
> + return prot;
> +}
> +
> +static int intel_svm_prq_report(struct device *dev, struct page_req_dsc 
> *desc)
> +{
> + int ret = 0;

It seems that "ret" should be initialized as -EINVAL. Otherwise, this function
will return 0 for devices which have no fault handlers, and all page requests
will be ignored by iommu driver.

> + struct iommu_fault_event event;
> + struct pci_dev *pdev;
> +
> + /**
> +  * If caller does not provide struct device, this is the case where
> +  * guest PASID table is bound to the device. So we need to retrieve
> +  * struct device from the page request descriptor then proceed.
> +  */
> + if (!dev) {
> + pdev = pci_get_bus_and_slot(desc->bus, desc->devfn);
> + if (!pdev) {
> + pr_err("No PCI device found for PRQ [%02x:%02x.%d]\n",
> + desc->bus, PCI_SLOT(desc->devfn),
> + PCI_FUNC(desc->devfn));
> + return -ENODEV;
> + }
> + dev = >dev;
> + } else if (dev_is_pci(dev)) {
> + pdev = to_pci_dev(dev);
> + pci_dev_get(pdev);
> + } else
> + return -ENODEV;
> +
> + pr_debug("Notify PRQ device [%02x:%02x.%d]\n",
> + desc->bus, PCI_SLOT(desc->devfn),
> + PCI_FUNC(desc->devfn));
> +
> + /* invoke device fault handler if registered */
> + if (iommu_has_device_fault_handler(dev)) {
> + /* Fill in event data for device specific processing */
> + event.type = IOMMU_FAULT_PAGE_REQ;
> + event.addr = desc->addr;
> + event.pasid = desc->pasid;
> + event.page_req_group_id = desc->prg_index;
> + event.prot = prq_to_iommu_prot(desc);
> + event.last_req = desc->lpig;
> + event.pasid_valid = 1;
> + event.iommu_private = desc->private;
> + ret = iommu_report_device_fault(>dev, );
> + }
> +
> + pci_dev_put(pdev);
> +
> + return ret;
> +}
> +
>  static irqreturn_t prq_event_thread(int irq, void *d)
>  {
>   struct intel_iommu *iommu = d;
> @@ -578,7 +643,12 @@ static irqreturn_t prq_event_thread(int irq, void *d)
>   handled = 1;
>  
>   req = >prq[head / sizeof(*req)];
> -
> + /**
> +  * If prq is to be handled outside iommu driver via receiver of
> +  * the fault notifiers, we skip the page response here.
> +  */
> + if (!intel_svm_prq_report(NULL, req))
> + goto prq_advance;
>   result = QI_RESP_FAILURE;
>   address = (u64)req->addr << VTD_PAGE_SHIFT;
>   if (!req->pasid_present) {
> @@ -649,11 +719,7 @@ static irqreturn_t prq_event_thread(int irq, void *d)
>   if (WARN_ON(>list == >devs))
>   sdev = NULL;
>  
> - if (sdev && sdev->ops && sdev->ops->fault_cb) {
> - int rwxp = (req->rd_req << 3) | (req->wr_req << 2) |
> - (req->exe_req << 1) | (req->priv_req);
> - sdev->ops->fault_cb(sdev->dev, req->pasid, req->addr, 
> req->private, rwxp, result);
> - }
> + intel_svm_prq_report(sdev->dev, req);

Do you mind explaining why we need to report this request twice?

Best regards,
Lu Baolu

>   /* We get here in the error case where the PASID lookup failed,
>  and these can be NULL. Do not use them 

Re: [PATCH v3 13/16] iommu/intel-svm: notify page request to guest

[Lu Baolu]

Hi,

On 11/18/2017 02:55 AM, Jacob Pan wrote:
> If the source device of a page request has its PASID table pointer
> bond to a guest, the first level page tables are owned by the guest.
> In this case, we shall let guest OS to manage page fault.
>
> This patch uses the IOMMU fault notification API to send notifications,
> possibly via VFIO, to the guest OS. Once guest pages are fault in, guest
> will issue page response which will be passed down via the invalidation
> passdown APIs.
>
> Signed-off-by: Jacob Pan 
> Signed-off-by: Ashok Raj 
> ---
>  drivers/iommu/intel-svm.c | 80 
> ++-
>  include/linux/iommu.h |  1 +
>  2 files changed, 74 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
> index f6697e5..77c25d8 100644
> --- a/drivers/iommu/intel-svm.c
> +++ b/drivers/iommu/intel-svm.c
> @@ -555,6 +555,71 @@ static bool is_canonical_address(u64 addr)
>   return (((saddr << shift) >> shift) == saddr);
>  }
>  
> +static int prq_to_iommu_prot(struct page_req_dsc *req)
> +{
> + int prot = 0;
> +
> + if (req->rd_req)
> + prot |= IOMMU_FAULT_READ;
> + if (req->wr_req)
> + prot |= IOMMU_FAULT_WRITE;
> + if (req->exe_req)
> + prot |= IOMMU_FAULT_EXEC;
> + if (req->priv_req)
> + prot |= IOMMU_FAULT_PRIV;
> +
> + return prot;
> +}
> +
> +static int intel_svm_prq_report(struct device *dev, struct page_req_dsc 
> *desc)
> +{
> + int ret = 0;

It seems that "ret" should be initialized as -EINVAL. Otherwise, this function
will return 0 for devices which have no fault handlers, and all page requests
will be ignored by iommu driver.

> + struct iommu_fault_event event;
> + struct pci_dev *pdev;
> +
> + /**
> +  * If caller does not provide struct device, this is the case where
> +  * guest PASID table is bound to the device. So we need to retrieve
> +  * struct device from the page request descriptor then proceed.
> +  */
> + if (!dev) {
> + pdev = pci_get_bus_and_slot(desc->bus, desc->devfn);
> + if (!pdev) {
> + pr_err("No PCI device found for PRQ [%02x:%02x.%d]\n",
> + desc->bus, PCI_SLOT(desc->devfn),
> + PCI_FUNC(desc->devfn));
> + return -ENODEV;
> + }
> + dev = >dev;
> + } else if (dev_is_pci(dev)) {
> + pdev = to_pci_dev(dev);
> + pci_dev_get(pdev);
> + } else
> + return -ENODEV;
> +
> + pr_debug("Notify PRQ device [%02x:%02x.%d]\n",
> + desc->bus, PCI_SLOT(desc->devfn),
> + PCI_FUNC(desc->devfn));
> +
> + /* invoke device fault handler if registered */
> + if (iommu_has_device_fault_handler(dev)) {
> + /* Fill in event data for device specific processing */
> + event.type = IOMMU_FAULT_PAGE_REQ;
> + event.addr = desc->addr;
> + event.pasid = desc->pasid;
> + event.page_req_group_id = desc->prg_index;
> + event.prot = prq_to_iommu_prot(desc);
> + event.last_req = desc->lpig;
> + event.pasid_valid = 1;
> + event.iommu_private = desc->private;
> + ret = iommu_report_device_fault(>dev, );
> + }
> +
> + pci_dev_put(pdev);
> +
> + return ret;
> +}
> +
>  static irqreturn_t prq_event_thread(int irq, void *d)
>  {
>   struct intel_iommu *iommu = d;
> @@ -578,7 +643,12 @@ static irqreturn_t prq_event_thread(int irq, void *d)
>   handled = 1;
>  
>   req = >prq[head / sizeof(*req)];
> -
> + /**
> +  * If prq is to be handled outside iommu driver via receiver of
> +  * the fault notifiers, we skip the page response here.
> +  */
> + if (!intel_svm_prq_report(NULL, req))
> + goto prq_advance;
>   result = QI_RESP_FAILURE;
>   address = (u64)req->addr << VTD_PAGE_SHIFT;
>   if (!req->pasid_present) {
> @@ -649,11 +719,7 @@ static irqreturn_t prq_event_thread(int irq, void *d)
>   if (WARN_ON(>list == >devs))
>   sdev = NULL;
>  
> - if (sdev && sdev->ops && sdev->ops->fault_cb) {
> - int rwxp = (req->rd_req << 3) | (req->wr_req << 2) |
> - (req->exe_req << 1) | (req->priv_req);
> - sdev->ops->fault_cb(sdev->dev, req->pasid, req->addr, 
> req->private, rwxp, result);
> - }
> + intel_svm_prq_report(sdev->dev, req);

Do you mind explaining why we need to report this request twice?

Best regards,
Lu Baolu

>   /* We get here in the error case where the PASID lookup failed,
>  and these can be NULL. Do not use them below this point! */
>   sdev = NULL;
> @@ 

Re: [patch V4 02/11] LICENSES: Add the GPL 2.0 license

[Greg Kroah-Hartman]

On Mon, Dec 04, 2017 at 10:19:29PM +0100, Thomas Gleixner wrote:
> Add the full text of the GPL 2.0 license to the LICENSES directory.  It was
> copied directly from the COPYING file in the kernel source tree as it
> differs from the public available version of the license in various places
> including the FSF.
> 
> Philippe did some research on the GPL2.0 history:
> 
>   There is NO trustworthy version of an official GPL 2.0 text: the FSF
>   official texts are all fubar (if only in small and subtle ways). The FSF
>   texts should be authoritative, but then which one? They published more
>   GPL 2.0 versions than most. So we would be hard pressed to blame SPDX or
>   the OSI for having their own minor variant.
> 
>   Then in digging further, I found the ONE true original GPL with a file
>   time stamp on June 2 1991, 01:50 (AM?, PM? unknown time zone?)  ! in an
>   old GCC archive.
> 
>   For the posterity and everyone's enjoyment I have built a git history
>   of GPL 2.0 Mark1 to Mark6
> 
>   See https://github.com/pombredanne/gpl-history/commits/master/COPYING
> 
>   I also added a shorter history of the Linux COPYING text. The first
>   version in Linus's git tree is based on the very fine and well tuned GPL
>   2 Mark4, the first fully Y2K compliant version of the GPL 2, as you can
>   see from the diffs with the former Mark3: that was dangerously stuck in
>   the last century.
> 
>   The current version in is based on a rare GPL 2.0 Mark5.1 aka "Franklin
>   St", that I do not have in my history yet and spells "Franklin St."
>   rather than "Franklin Street."  Therefore there is likely another GPL 2.0
>   version between Mark4 and Mark5 that I have yet to find and may not have
>   been caught by the archive.org spiders. Here help and patches welcomed:
>   this is likely an important missing link.
> 
>   Further information about this archaelogical research;
>   
>   
> http://lkml.kernel.org/r/CAOFm3uEzRMf261+O-Nm+9HDoEn9RbFjH=5j9i1c2ggmug2g...@mail.gmail.com
> 
> Add the required tags for reference and tooling.
> 
> Signed-off-by: Thomas Gleixner 

Reviewed-by: Greg Kroah-Hartman 

Re: [patch V4 02/11] LICENSES: Add the GPL 2.0 license

[Greg Kroah-Hartman]

On Mon, Dec 04, 2017 at 10:19:29PM +0100, Thomas Gleixner wrote:
> Add the full text of the GPL 2.0 license to the LICENSES directory.  It was
> copied directly from the COPYING file in the kernel source tree as it
> differs from the public available version of the license in various places
> including the FSF.
> 
> Philippe did some research on the GPL2.0 history:
> 
>   There is NO trustworthy version of an official GPL 2.0 text: the FSF
>   official texts are all fubar (if only in small and subtle ways). The FSF
>   texts should be authoritative, but then which one? They published more
>   GPL 2.0 versions than most. So we would be hard pressed to blame SPDX or
>   the OSI for having their own minor variant.
> 
>   Then in digging further, I found the ONE true original GPL with a file
>   time stamp on June 2 1991, 01:50 (AM?, PM? unknown time zone?)  ! in an
>   old GCC archive.
> 
>   For the posterity and everyone's enjoyment I have built a git history
>   of GPL 2.0 Mark1 to Mark6
> 
>   See https://github.com/pombredanne/gpl-history/commits/master/COPYING
> 
>   I also added a shorter history of the Linux COPYING text. The first
>   version in Linus's git tree is based on the very fine and well tuned GPL
>   2 Mark4, the first fully Y2K compliant version of the GPL 2, as you can
>   see from the diffs with the former Mark3: that was dangerously stuck in
>   the last century.
> 
>   The current version in is based on a rare GPL 2.0 Mark5.1 aka "Franklin
>   St", that I do not have in my history yet and spells "Franklin St."
>   rather than "Franklin Street."  Therefore there is likely another GPL 2.0
>   version between Mark4 and Mark5 that I have yet to find and may not have
>   been caught by the archive.org spiders. Here help and patches welcomed:
>   this is likely an important missing link.
> 
>   Further information about this archaelogical research;
>   
>   
> http://lkml.kernel.org/r/CAOFm3uEzRMf261+O-Nm+9HDoEn9RbFjH=5j9i1c2ggmug2g...@mail.gmail.com
> 
> Add the required tags for reference and tooling.
> 
> Signed-off-by: Thomas Gleixner 

Reviewed-by: Greg Kroah-Hartman 

RE: [PATCH] refcount_t: documentation for memory ordering differences

[Reshetova, Elena]

 On 11/29/2017 04:36 AM, Elena Reshetova wrote:
> > Some functions from refcount_t API provide different
> > memory ordering guarantees that their atomic counterparts.
> > This adds a document outlining these differences.
> >
> > Signed-off-by: Elena Reshetova 
> > ---
> >  Documentation/core-api/index.rst  |   1 +
> >  Documentation/core-api/refcount-vs-atomic.rst | 129
> ++
> >  2 files changed, 130 insertions(+)
> >  create mode 100644 Documentation/core-api/refcount-vs-atomic.rst
> 
> > diff --git a/Documentation/core-api/refcount-vs-atomic.rst
> b/Documentation/core-api/refcount-vs-atomic.rst
> > new file mode 100644
> > index 000..5619d48
> > --- /dev/null
> > +++ b/Documentation/core-api/refcount-vs-atomic.rst
> > @@ -0,0 +1,129 @@
> > +===
> > +refcount_t API compared to atomic_t
> > +===
> > +
> > +The goal of refcount_t API is to provide a minimal API for implementing
> > +an object's reference counters. While a generic architecture-independent
> > +implementation from lib/refcount.c uses atomic operations underneath,
> > +there are a number of differences between some of the refcount_*() and
> > +atomic_*() functions with regards to the memory ordering guarantees.
> > +This document outlines the differences and provides respective examples
> > +in order to help maintainers validate their code against the change in
> > +these memory ordering guarantees.
> > +
> > +memory-barriers.txt and atomic_t.txt provide more background to the
> > +memory ordering in general and for atomic operations specifically.
> > +
> > +Relevant types of memory ordering
> > +=
> > +
> > +**Note**: the following section only covers some of the memory
> > +ordering types that are relevant for the atomics and reference
> > +counters and used through this document. For a much broader picture
> > +please consult memory-barriers.txt document.
> > +
> > +In the absence of any memory ordering guarantees (i.e. fully unordered)
> > +atomics & refcounters only provide atomicity and
> > +program order (po) relation (on the same CPU). It guarantees that
> > +each atomic_*() and refcount_*() operation is atomic and instructions
> > +are executed in program order on a single CPU.
> > +This is implemented using READ_ONCE()/WRITE_ONCE() and
> > +compare-and-swap primitives.
> > +
> > +A strong (full) memory ordering guarantees that all prior loads and
> > +stores (all po-earlier instructions) on the same CPU are completed
> > +before any po-later instruction is executed on the same CPU.
> > +It also guarantees that all po-earlier stores on the same CPU
> > +and all propagated stores from other CPUs must propagate to all
> > +other CPUs before any po-later instruction is executed on the original
> > +CPU (A-cumulative property). This is implemented using smp_mb().
> 
> I don't know what "A-cumulative property" means, and google search didn't
> either.
> 
> Is it non-cumulative, similar to typical vs. atypical, where atypical
> roughly means non-typical.  Or is it accumlative (something being
> accumulated, summed up, gathered up)?
> 
> Or is it something else.. TBD?


Sorry, I should have mentioned also explicitly in this document where the terms 
are
coming from. I have mentioned in cover letter, but failed to say here. 
I will fix it. 

Thank you for catching! I see that reply was already given to this by Andrea. 

Best Regards,
Elena


> 
> > +A RELEASE memory ordering guarantees that all prior loads and
> > +stores (all po-earlier instructions) on the same CPU are completed
> > +before the operation. It also guarantees that all po-earlier
> > +stores on the same CPU and all propagated stores from other CPUs
> > +must propagate to all other CPUs before the release operation
> > +(A-cumulative property). This is implemented using smp_store_release().
> 
> thanks.
> --
> ~Randy

RE: [PATCH] refcount_t: documentation for memory ordering differences

[Reshetova, Elena]

 On 11/29/2017 04:36 AM, Elena Reshetova wrote:
> > Some functions from refcount_t API provide different
> > memory ordering guarantees that their atomic counterparts.
> > This adds a document outlining these differences.
> >
> > Signed-off-by: Elena Reshetova 
> > ---
> >  Documentation/core-api/index.rst  |   1 +
> >  Documentation/core-api/refcount-vs-atomic.rst | 129
> ++
> >  2 files changed, 130 insertions(+)
> >  create mode 100644 Documentation/core-api/refcount-vs-atomic.rst
> 
> > diff --git a/Documentation/core-api/refcount-vs-atomic.rst
> b/Documentation/core-api/refcount-vs-atomic.rst
> > new file mode 100644
> > index 000..5619d48
> > --- /dev/null
> > +++ b/Documentation/core-api/refcount-vs-atomic.rst
> > @@ -0,0 +1,129 @@
> > +===
> > +refcount_t API compared to atomic_t
> > +===
> > +
> > +The goal of refcount_t API is to provide a minimal API for implementing
> > +an object's reference counters. While a generic architecture-independent
> > +implementation from lib/refcount.c uses atomic operations underneath,
> > +there are a number of differences between some of the refcount_*() and
> > +atomic_*() functions with regards to the memory ordering guarantees.
> > +This document outlines the differences and provides respective examples
> > +in order to help maintainers validate their code against the change in
> > +these memory ordering guarantees.
> > +
> > +memory-barriers.txt and atomic_t.txt provide more background to the
> > +memory ordering in general and for atomic operations specifically.
> > +
> > +Relevant types of memory ordering
> > +=
> > +
> > +**Note**: the following section only covers some of the memory
> > +ordering types that are relevant for the atomics and reference
> > +counters and used through this document. For a much broader picture
> > +please consult memory-barriers.txt document.
> > +
> > +In the absence of any memory ordering guarantees (i.e. fully unordered)
> > +atomics & refcounters only provide atomicity and
> > +program order (po) relation (on the same CPU). It guarantees that
> > +each atomic_*() and refcount_*() operation is atomic and instructions
> > +are executed in program order on a single CPU.
> > +This is implemented using READ_ONCE()/WRITE_ONCE() and
> > +compare-and-swap primitives.
> > +
> > +A strong (full) memory ordering guarantees that all prior loads and
> > +stores (all po-earlier instructions) on the same CPU are completed
> > +before any po-later instruction is executed on the same CPU.
> > +It also guarantees that all po-earlier stores on the same CPU
> > +and all propagated stores from other CPUs must propagate to all
> > +other CPUs before any po-later instruction is executed on the original
> > +CPU (A-cumulative property). This is implemented using smp_mb().
> 
> I don't know what "A-cumulative property" means, and google search didn't
> either.
> 
> Is it non-cumulative, similar to typical vs. atypical, where atypical
> roughly means non-typical.  Or is it accumlative (something being
> accumulated, summed up, gathered up)?
> 
> Or is it something else.. TBD?


Sorry, I should have mentioned also explicitly in this document where the terms 
are
coming from. I have mentioned in cover letter, but failed to say here. 
I will fix it. 

Thank you for catching! I see that reply was already given to this by Andrea. 

Best Regards,
Elena


> 
> > +A RELEASE memory ordering guarantees that all prior loads and
> > +stores (all po-earlier instructions) on the same CPU are completed
> > +before the operation. It also guarantees that all po-earlier
> > +stores on the same CPU and all propagated stores from other CPUs
> > +must propagate to all other CPUs before the release operation
> > +(A-cumulative property). This is implemented using smp_store_release().
> 
> thanks.
> --
> ~Randy

Re: [PATCH 21/45] usb: typec: remove duplicate includes

[Heikki Krogerus]

On Tue, Dec 05, 2017 at 07:34:55AM +0530, Pravin Shedge wrote:
> These duplicate includes have been found with scripts/checkincludes.pl but
> they have been removed manually to avoid removing false positives.
> 
> Signed-off-by: Pravin Shedge 

Acked-by: Heikki Krogerus 

> ---
>  drivers/usb/typec/fusb302/fusb302.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/usb/typec/fusb302/fusb302.c 
> b/drivers/usb/typec/fusb302/fusb302.c
> index 72cb060..a3e4cc9 100644
> --- a/drivers/usb/typec/fusb302/fusb302.c
> +++ b/drivers/usb/typec/fusb302/fusb302.c
> @@ -16,7 +16,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 

Thanks,

-- 
heikki

Re: [PATCH 21/45] usb: typec: remove duplicate includes

[Heikki Krogerus]

On Tue, Dec 05, 2017 at 07:34:55AM +0530, Pravin Shedge wrote:
> These duplicate includes have been found with scripts/checkincludes.pl but
> they have been removed manually to avoid removing false positives.
> 
> Signed-off-by: Pravin Shedge 

Acked-by: Heikki Krogerus 

> ---
>  drivers/usb/typec/fusb302/fusb302.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/usb/typec/fusb302/fusb302.c 
> b/drivers/usb/typec/fusb302/fusb302.c
> index 72cb060..a3e4cc9 100644
> --- a/drivers/usb/typec/fusb302/fusb302.c
> +++ b/drivers/usb/typec/fusb302/fusb302.c
> @@ -16,7 +16,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 

Thanks,

-- 
heikki

Re: [PATCH net-next V3] tun: add eBPF based queue selection method

[Jason Wang]

On 2017年12月05日 08:16, Willem de Bruijn wrote:

On Mon, Dec 4, 2017 at 4:31 AM, Jason Wang  wrote:

This patch introduces an eBPF based queue selection method. With this,
the policy could be offloaded to userspace completely through a new
ioctl TUNSETSTEERINGEBPF.

Signed-off-by: Jason Wang 
---
+static u16 tun_ebpf_select_queue(struct tun_struct *tun, struct sk_buff *skb)
+{
+   struct tun_steering_prog *prog;
+   u16 ret = 0;
+
+   prog = rcu_dereference(tun->steering_prog);
+   if (prog)
+   ret = bpf_prog_run_clear_cb(prog->prog, skb);

This dereferences tun->steering_prog for a second time. It is safe
in this load balancing case to assign a few extra packets to queue 0.
But the issue can also be avoided by replacing the function with a
direct call in tun_net_xmit:

struct tun_steering_prog *s = rcu_dereference(tun->steering_prog);
if (s)
ret = bpf_prog_run_clear_cb(s->prog, skb) % tun->numqueues;


Right.




  /* Net device start xmit */
-static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
+static void tun_automq_xmit(struct tun_struct *tun, struct sk_buff *skb)
  {
-   struct tun_struct *tun = netdev_priv(dev);
-   int txq = skb->queue_mapping;
-   struct tun_file *tfile;
-   u32 numqueues = 0;
-
-   rcu_read_lock();
-   tfile = rcu_dereference(tun->tfiles[txq]);
-   numqueues = READ_ONCE(tun->numqueues);
-
-   /* Drop packet if interface is not attached */
-   if (txq >= numqueues)
-   goto drop;
-
  #ifdef CONFIG_RPS
-   if (numqueues == 1 && static_key_false(_needed)) {
+   if (tun->numqueues == 1 && static_key_false(_needed)) {
 /* Select queue was not called for the skbuff, so we extract 
the
  * RPS hash and save it into the flow_table here.
  */
@@ -969,6 +986,26 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, 
struct net_device *dev)
 }
 }
  #endif
+}
+
+/* Net device start xmit */
+static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+   struct tun_struct *tun = netdev_priv(dev);
+   int txq = skb->queue_mapping;
+   struct tun_file *tfile;
+   u32 numqueues = 0;
+
+   rcu_read_lock();
+   tfile = rcu_dereference(tun->tfiles[txq]);
+   numqueues = READ_ONCE(tun->numqueues);

Now tun->numqueues is read twice, reversing commit fa35864e0bb7
("tuntap: Fix for a race in accessing numqueues"). I don't see anything
left that would cause a divide by zero after the relevant code was
converted from divide to multiple and subsequently even removed.

But if it's safe to read multiple times, might as well remove the READ_ONCE.


Good point, but READ_ONCE() is not something new, we'd better change 
this in another patch.





@@ -1551,7 +1588,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, 
struct tun_file *tfile,
 int copylen;
 bool zerocopy = false;
 int err;
-   u32 rxhash;
+   u32 rxhash = 0;
 int skb_xdp = 1;
 bool frags = tun_napi_frags_enabled(tun);

@@ -1739,7 +1776,10 @@ static ssize_t tun_get_user(struct tun_struct *tun, 
struct tun_file *tfile,
 rcu_read_unlock();
 }

-   rxhash = __skb_get_hash_symmetric(skb);
+   rcu_read_lock();
+   if (!rcu_dereference(tun->steering_prog))
+   rxhash = __skb_get_hash_symmetric(skb);
+   rcu_read_unlock();

 if (frags) {
 /* Exercise flow dissector code path. */
@@ -1783,7 +1823,9 @@ static ssize_t tun_get_user(struct tun_struct *tun, 
struct tun_file *tfile,
 u64_stats_update_end(>syncp);
 put_cpu_ptr(stats);

-   tun_flow_update(tun, rxhash, tfile);
+   if (rxhash)
+   tun_flow_update(tun, rxhash, tfile);
+

Nit: zero is a valid hash? In which case, an int64_t initialized to -1 is the
safer check.


Looks not? E.g looking at __flow_hash_from_keys() it did:

static inline u32 __flow_hash_from_keys(struct flow_keys *keys, u32 keyval)
{
    u32 hash;

    __flow_hash_consistentify(keys);

    hash = __flow_hash_words(flow_keys_hash_start(keys),
                 flow_keys_hash_length(keys), keyval);
    if (!hash)
        hash = 1;

    return hash;
}

Thanks

Re: [PATCH net-next V3] tun: add eBPF based queue selection method

[Jason Wang]

On 2017年12月05日 08:16, Willem de Bruijn wrote:

On Mon, Dec 4, 2017 at 4:31 AM, Jason Wang  wrote:

This patch introduces an eBPF based queue selection method. With this,
the policy could be offloaded to userspace completely through a new
ioctl TUNSETSTEERINGEBPF.

Signed-off-by: Jason Wang 
---
+static u16 tun_ebpf_select_queue(struct tun_struct *tun, struct sk_buff *skb)
+{
+   struct tun_steering_prog *prog;
+   u16 ret = 0;
+
+   prog = rcu_dereference(tun->steering_prog);
+   if (prog)
+   ret = bpf_prog_run_clear_cb(prog->prog, skb);

This dereferences tun->steering_prog for a second time. It is safe
in this load balancing case to assign a few extra packets to queue 0.
But the issue can also be avoided by replacing the function with a
direct call in tun_net_xmit:

struct tun_steering_prog *s = rcu_dereference(tun->steering_prog);
if (s)
ret = bpf_prog_run_clear_cb(s->prog, skb) % tun->numqueues;


Right.




  /* Net device start xmit */
-static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
+static void tun_automq_xmit(struct tun_struct *tun, struct sk_buff *skb)
  {
-   struct tun_struct *tun = netdev_priv(dev);
-   int txq = skb->queue_mapping;
-   struct tun_file *tfile;
-   u32 numqueues = 0;
-
-   rcu_read_lock();
-   tfile = rcu_dereference(tun->tfiles[txq]);
-   numqueues = READ_ONCE(tun->numqueues);
-
-   /* Drop packet if interface is not attached */
-   if (txq >= numqueues)
-   goto drop;
-
  #ifdef CONFIG_RPS
-   if (numqueues == 1 && static_key_false(_needed)) {
+   if (tun->numqueues == 1 && static_key_false(_needed)) {
 /* Select queue was not called for the skbuff, so we extract 
the
  * RPS hash and save it into the flow_table here.
  */
@@ -969,6 +986,26 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, 
struct net_device *dev)
 }
 }
  #endif
+}
+
+/* Net device start xmit */
+static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+   struct tun_struct *tun = netdev_priv(dev);
+   int txq = skb->queue_mapping;
+   struct tun_file *tfile;
+   u32 numqueues = 0;
+
+   rcu_read_lock();
+   tfile = rcu_dereference(tun->tfiles[txq]);
+   numqueues = READ_ONCE(tun->numqueues);

Now tun->numqueues is read twice, reversing commit fa35864e0bb7
("tuntap: Fix for a race in accessing numqueues"). I don't see anything
left that would cause a divide by zero after the relevant code was
converted from divide to multiple and subsequently even removed.

But if it's safe to read multiple times, might as well remove the READ_ONCE.


Good point, but READ_ONCE() is not something new, we'd better change 
this in another patch.





@@ -1551,7 +1588,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, 
struct tun_file *tfile,
 int copylen;
 bool zerocopy = false;
 int err;
-   u32 rxhash;
+   u32 rxhash = 0;
 int skb_xdp = 1;
 bool frags = tun_napi_frags_enabled(tun);

@@ -1739,7 +1776,10 @@ static ssize_t tun_get_user(struct tun_struct *tun, 
struct tun_file *tfile,
 rcu_read_unlock();
 }

-   rxhash = __skb_get_hash_symmetric(skb);
+   rcu_read_lock();
+   if (!rcu_dereference(tun->steering_prog))
+   rxhash = __skb_get_hash_symmetric(skb);
+   rcu_read_unlock();

 if (frags) {
 /* Exercise flow dissector code path. */
@@ -1783,7 +1823,9 @@ static ssize_t tun_get_user(struct tun_struct *tun, 
struct tun_file *tfile,
 u64_stats_update_end(>syncp);
 put_cpu_ptr(stats);

-   tun_flow_update(tun, rxhash, tfile);
+   if (rxhash)
+   tun_flow_update(tun, rxhash, tfile);
+

Nit: zero is a valid hash? In which case, an int64_t initialized to -1 is the
safer check.


Looks not? E.g looking at __flow_hash_from_keys() it did:

static inline u32 __flow_hash_from_keys(struct flow_keys *keys, u32 keyval)
{
    u32 hash;

    __flow_hash_consistentify(keys);

    hash = __flow_hash_words(flow_keys_hash_start(keys),
                 flow_keys_hash_length(keys), keyval);
    if (!hash)
        hash = 1;

    return hash;
}

Thanks

Re: [PATCH v2] sunxi-rsb: Include OF based modalias in device uevent

[Chen-Yu Tsai]

Hi,

On Tue, Nov 28, 2017 at 11:47 PM, Maxime Ripard
 wrote:
> On Mon, Nov 27, 2017 at 08:05:34PM +0100, Stefan Brüns wrote:
>> Include the OF-based modalias in the uevent sent when registering devices
>> on the sunxi RSB bus, so that user space has a chance to autoload the
>> kernel module for the device.
>>
>> Fixes a regression caused by commit 3f241bfa60bd ("arm64: allwinner: a64:
>> pine64: Use dcdc1 regulator for mmc0"). When the axp20x-rsb module for
>> the AXP803 PMIC is built as a module, it is not loaded and the system
>> ends up with an disfunctional MMC controller.
>>

Tags should be:

Fixes: d787dcdb9c8f ("bus: sunxi-rsb: Add driver for Allwinner Reduced
Serial Bus")
Cc: stable  # 4.4.x 7a3b7cd332db of: device:
Export of_device_{get_modalias, uvent_modalias} to modules

>> Cc: stable 
>> Signed-off-by: Stefan Brüns 
>
> Acked-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

Maxime, could you merge this as a fix to get it in fast?

ChenYu

Re: [PATCH v2] sunxi-rsb: Include OF based modalias in device uevent

[Chen-Yu Tsai]

Hi,

On Tue, Nov 28, 2017 at 11:47 PM, Maxime Ripard
 wrote:
> On Mon, Nov 27, 2017 at 08:05:34PM +0100, Stefan Brüns wrote:
>> Include the OF-based modalias in the uevent sent when registering devices
>> on the sunxi RSB bus, so that user space has a chance to autoload the
>> kernel module for the device.
>>
>> Fixes a regression caused by commit 3f241bfa60bd ("arm64: allwinner: a64:
>> pine64: Use dcdc1 regulator for mmc0"). When the axp20x-rsb module for
>> the AXP803 PMIC is built as a module, it is not loaded and the system
>> ends up with an disfunctional MMC controller.
>>

Tags should be:

Fixes: d787dcdb9c8f ("bus: sunxi-rsb: Add driver for Allwinner Reduced
Serial Bus")
Cc: stable  # 4.4.x 7a3b7cd332db of: device:
Export of_device_{get_modalias, uvent_modalias} to modules

>> Cc: stable 
>> Signed-off-by: Stefan Brüns 
>
> Acked-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

Maxime, could you merge this as a fix to get it in fast?

ChenYu

Re: [PATCH] checkpatch: warn for use of %px

[Joe Perches]

On Tue, 2017-12-05 at 08:17 +1100, Tobin C. Harding wrote:
> Usage of the new %px specifier potentially leaks sensitive
> inforamtion. Printing kernel addresses exposes the kernel layout in

information

> memory, this is potentially exploitable. We have tools in the kernel to
> help us do the right thing. We can have checkpatch warn developers of
> potential dangers of using %px.
> 
> Have checkpatch emit a warning for usage of specifier %px.
> 
> Suggested-by: Andrew Morton 
> Signed-off-by: Tobin C. Harding 
> Co-Developed-by: Joe Perches 
> 
> ---
> 
> Joe,
> 
> Are you happy with this tagging? Needs your signed-off-by still.

Maybe with a few corrections (below)
> 
> Andrew,
> 
> Is it okay to add your Suggested-by tag here?
> 
> I'm not entirely sure when one is supposed to add someones signed-off-by
> tag since the docs state that it should not be added without
> permission. I am also unsure where/when is the best time to request this
> permission.
[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -1612,6 +1612,17 @@ sub raw_line {
>   return $line;
>  }
>  
> +sub stat_real {
> + my ($linenr, $lc) = @_;
> +
> + my $stat_real = raw_line($linenr, 0);
> + for (my $count = $linenr + 1; $count <= $lc; $count++) {
> + $stat_real = $stat_real . "\n" . raw_line($count, 0);
> + }
> +
> + return $stat_real;
> +}

If you are going to make a subroutine of this
there are some other places it could be used too.

> +
>  sub cat_vet {
>   my ($vet) = @_;
>   my ($res, $coded);
> @@ -5747,24 +5758,35 @@ sub process {
>   defined $stat &&
>   $stat =~ /^\+(?![^\{]*\{\s*).*\b(\w+)\s*\(.*$String\s*,/s &&
>   $1 !~ /^_*volatile_*$/) {
> - my $bad_extension = "";
> + my ($specifier, $extension, $stat_real);

My preference is not to define multiple variables on a single line.
I'd rather have:
my $specifier;
my $extension;
my $stat_real;

> + my $bad_specifier = "";
>   my $lc = $stat =~ tr@\n@@;
>   $lc = $lc + $linenr;
>   for (my $count = $linenr; $count <= $lc; $count++) {
>   my $fmt = get_quoted_string($lines[$count - 1], 
> raw_line($count, 0));
>   $fmt =~ s/%%//g;
> - if ($fmt =~ 
> /(\%[\*\d\.]*p(?![\WFfSsBKRraEhMmIiUDdgVCbGNOx]).)/) {
> - $bad_extension = $1;
> - last;
> +
> + while ($fmt =~ /(\%[\*\d\.]*p(\w))/g) {
> + $specifier = $1;
> + $extension = $2;
> + if ($extension !~ 
> /[FfSsBKRraEhMmIiUDdgVCbGNOx]/) {
> + $bad_specifier = $specifier;
> + last;
> + }
> + if ($extension eq "x" && 
> !defined($stat_real)) {
> + if (!defined($stat_real)) {
> + $stat_real = 
> stat_real($linenr, $lc);
> + }
> + WARN("VSPRINTF_SPECIFIER_PX",
> +  "Using vsprintf specifier 
> '\%px' potentially exposes the kernel layout in memory, if you don't _realy_ 
> need the address please consider using '\%p'.\n" . "$here\n$stat_real\n");  

"kernel memory layout" not "kernel layout in memory"
"really" not "_realy_"

Re: [PATCH] checkpatch: warn for use of %px

[Joe Perches]

On Tue, 2017-12-05 at 08:17 +1100, Tobin C. Harding wrote:
> Usage of the new %px specifier potentially leaks sensitive
> inforamtion. Printing kernel addresses exposes the kernel layout in

information

> memory, this is potentially exploitable. We have tools in the kernel to
> help us do the right thing. We can have checkpatch warn developers of
> potential dangers of using %px.
> 
> Have checkpatch emit a warning for usage of specifier %px.
> 
> Suggested-by: Andrew Morton 
> Signed-off-by: Tobin C. Harding 
> Co-Developed-by: Joe Perches 
> 
> ---
> 
> Joe,
> 
> Are you happy with this tagging? Needs your signed-off-by still.

Maybe with a few corrections (below)
> 
> Andrew,
> 
> Is it okay to add your Suggested-by tag here?
> 
> I'm not entirely sure when one is supposed to add someones signed-off-by
> tag since the docs state that it should not be added without
> permission. I am also unsure where/when is the best time to request this
> permission.
[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -1612,6 +1612,17 @@ sub raw_line {
>   return $line;
>  }
>  
> +sub stat_real {
> + my ($linenr, $lc) = @_;
> +
> + my $stat_real = raw_line($linenr, 0);
> + for (my $count = $linenr + 1; $count <= $lc; $count++) {
> + $stat_real = $stat_real . "\n" . raw_line($count, 0);
> + }
> +
> + return $stat_real;
> +}

If you are going to make a subroutine of this
there are some other places it could be used too.

> +
>  sub cat_vet {
>   my ($vet) = @_;
>   my ($res, $coded);
> @@ -5747,24 +5758,35 @@ sub process {
>   defined $stat &&
>   $stat =~ /^\+(?![^\{]*\{\s*).*\b(\w+)\s*\(.*$String\s*,/s &&
>   $1 !~ /^_*volatile_*$/) {
> - my $bad_extension = "";
> + my ($specifier, $extension, $stat_real);

My preference is not to define multiple variables on a single line.
I'd rather have:
my $specifier;
my $extension;
my $stat_real;

> + my $bad_specifier = "";
>   my $lc = $stat =~ tr@\n@@;
>   $lc = $lc + $linenr;
>   for (my $count = $linenr; $count <= $lc; $count++) {
>   my $fmt = get_quoted_string($lines[$count - 1], 
> raw_line($count, 0));
>   $fmt =~ s/%%//g;
> - if ($fmt =~ 
> /(\%[\*\d\.]*p(?![\WFfSsBKRraEhMmIiUDdgVCbGNOx]).)/) {
> - $bad_extension = $1;
> - last;
> +
> + while ($fmt =~ /(\%[\*\d\.]*p(\w))/g) {
> + $specifier = $1;
> + $extension = $2;
> + if ($extension !~ 
> /[FfSsBKRraEhMmIiUDdgVCbGNOx]/) {
> + $bad_specifier = $specifier;
> + last;
> + }
> + if ($extension eq "x" && 
> !defined($stat_real)) {
> + if (!defined($stat_real)) {
> + $stat_real = 
> stat_real($linenr, $lc);
> + }
> + WARN("VSPRINTF_SPECIFIER_PX",
> +  "Using vsprintf specifier 
> '\%px' potentially exposes the kernel layout in memory, if you don't _realy_ 
> need the address please consider using '\%p'.\n" . "$here\n$stat_real\n");  

"kernel memory layout" not "kernel layout in memory"
"really" not "_realy_"

Re: [PATCH v9 3/5] perf utils: use pmu->is_uncore to detect PMU UNCORE devices

[Jin, Yao]

Hi,

I applied the diff but it's failed.

jinyao@skl:~/skl-ws/perf-dev/lck-4594/src$ patch -p1 < 1.pat
patching file tools/perf/util/pmu.c
patch:  malformed patch at line 41: *head, struct perf_pmu *pmu)

Could you send the patch as attachment to me in another mail thread?

to yao@linux.intel.com
cc yao@intel.com

Thanks
Jin Yao

On 12/5/2017 3:12 PM, Ganapatrao Kulkarni wrote:

diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 5ad8a18..57e38fd 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -538,6 +538,34 @@ static bool pmu_is_uncore(const char *name)
  }

  /*
+ *  PMU CORE devices have different name other than cpu in sysfs on some
+ *  platforms. looking for possible sysfs files to identify as core device.
+ */
+static int is_pmu_core(const char *name)
+{
+ struct stat st;
+ char path[PATH_MAX];
+ const char *sysfs = sysfs__mountpoint();
+
+ if (!sysfs)
+ return 0;
+
+ /* Look for cpu sysfs (x86 and others) */
+ scnprintf(path, PATH_MAX, "%s/bus/event_source/devices/cpu", sysfs);
+ if ((stat(path, ) == 0) &&
+ (strncmp(name, "cpu", strlen("cpu")) == 0))
+ return 1;
+
+ /* Look for cpu sysfs (specific to arm) */
+ scnprintf(path, PATH_MAX, "%s/bus/event_source/devices/%s/cpus",
+ sysfs, name);
+ if (stat(path, ) == 0)
+ return 1;
+
+ return 0;
+}
+
+/*
   * Return the CPU id as a raw string.
   *
   * Each architecture should provide a more precise id string that
@@ -641,7 +669,7 @@ static void pmu_add_cpu_aliases(struct list_head
*head, struct perf_pmu *pmu)
   break;
   }

- if (pmu->is_uncore) {
+ if (!is_pmu_core(name)) {
   /* check for uncore devices */
   if (pe->pmu == NULL)
   continue;

Re: [PATCH v9 3/5] perf utils: use pmu->is_uncore to detect PMU UNCORE devices

[Jin, Yao]

Hi,

I applied the diff but it's failed.

jinyao@skl:~/skl-ws/perf-dev/lck-4594/src$ patch -p1 < 1.pat
patching file tools/perf/util/pmu.c
patch:  malformed patch at line 41: *head, struct perf_pmu *pmu)

Could you send the patch as attachment to me in another mail thread?

to yao@linux.intel.com
cc yao@intel.com

Thanks
Jin Yao

On 12/5/2017 3:12 PM, Ganapatrao Kulkarni wrote:

diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 5ad8a18..57e38fd 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -538,6 +538,34 @@ static bool pmu_is_uncore(const char *name)
  }

  /*
+ *  PMU CORE devices have different name other than cpu in sysfs on some
+ *  platforms. looking for possible sysfs files to identify as core device.
+ */
+static int is_pmu_core(const char *name)
+{
+ struct stat st;
+ char path[PATH_MAX];
+ const char *sysfs = sysfs__mountpoint();
+
+ if (!sysfs)
+ return 0;
+
+ /* Look for cpu sysfs (x86 and others) */
+ scnprintf(path, PATH_MAX, "%s/bus/event_source/devices/cpu", sysfs);
+ if ((stat(path, ) == 0) &&
+ (strncmp(name, "cpu", strlen("cpu")) == 0))
+ return 1;
+
+ /* Look for cpu sysfs (specific to arm) */
+ scnprintf(path, PATH_MAX, "%s/bus/event_source/devices/%s/cpus",
+ sysfs, name);
+ if (stat(path, ) == 0)
+ return 1;
+
+ return 0;
+}
+
+/*
   * Return the CPU id as a raw string.
   *
   * Each architecture should provide a more precise id string that
@@ -641,7 +669,7 @@ static void pmu_add_cpu_aliases(struct list_head
*head, struct perf_pmu *pmu)
   break;
   }

- if (pmu->is_uncore) {
+ if (!is_pmu_core(name)) {
   /* check for uncore devices */
   if (pe->pmu == NULL)
   continue;

Re: [PATCH 4.4 00/27] 4.4.104-stable review

[Naresh Kamboju]

On 4 December 2017 at 21:29, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> This is the start of the stable review cycle for the 4.4.104 release.
> There are 27 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Dec  6 15:59:33 UTC 2017.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.104-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.4.104-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 998ef014deff90a607c74c706b5bed3115931b61
git describe: v4.4.103-28-g998ef014deff
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.103-28-g998ef014deff


No regressions (compared to build v4.4.103-28-ge1e2e6c522e1)

Boards, architectures and test suites:
-

juno-r2 - arm64
* boot - pass: 20,
* kselftest - fail: 1, pass: 27, skip: 25
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 28, skip: 36
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 936, skip: 159
* ltp-timers-tests - pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - pass: 26, skip: 28
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1035, skip: 67
* ltp-timers-tests - pass: 12,

x86_64
* boot - pass: 20,
* kselftest - pass: 39, skip: 31
* libhugetlbfs - pass: 76, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 956, skip: 164
* ltp-timers-tests - pass: 12,

And the arm64 hikey results.

Summary


kernel: 4.4.104-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.104-rc1-hikey-20171204-67
git commit: fc49d1746dc96bedfe5bf072eecbe84410972db0
git describe: 4.4.104-rc1-hikey-20171204-67
Test details: 
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.104-rc1-hikey-20171204-67


No regressions (compared to build 4.4.104-rc1-hikey-20171204-66)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 25, skip: 29
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 28, skip: 36
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 979, skip: 124
* ltp-timers-tests - pass: 12,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Tested-by: Naresh Kamboju <naresh.kamb...@linaro.org>

Re: [PATCH 4.4 00/27] 4.4.104-stable review

[Naresh Kamboju]

On 4 December 2017 at 21:29, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.4.104 release.
> There are 27 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Dec  6 15:59:33 UTC 2017.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.104-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.4.104-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 998ef014deff90a607c74c706b5bed3115931b61
git describe: v4.4.103-28-g998ef014deff
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.103-28-g998ef014deff


No regressions (compared to build v4.4.103-28-ge1e2e6c522e1)

Boards, architectures and test suites:
-

juno-r2 - arm64
* boot - pass: 20,
* kselftest - fail: 1, pass: 27, skip: 25
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 28, skip: 36
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 936, skip: 159
* ltp-timers-tests - pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - pass: 26, skip: 28
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1035, skip: 67
* ltp-timers-tests - pass: 12,

x86_64
* boot - pass: 20,
* kselftest - pass: 39, skip: 31
* libhugetlbfs - pass: 76, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 956, skip: 164
* ltp-timers-tests - pass: 12,

And the arm64 hikey results.

Summary


kernel: 4.4.104-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.104-rc1-hikey-20171204-67
git commit: fc49d1746dc96bedfe5bf072eecbe84410972db0
git describe: 4.4.104-rc1-hikey-20171204-67
Test details: 
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.104-rc1-hikey-20171204-67


No regressions (compared to build 4.4.104-rc1-hikey-20171204-66)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 25, skip: 29
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 28, skip: 36
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 979, skip: 124
* ltp-timers-tests - pass: 12,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Tested-by: Naresh Kamboju 

Re: [PATCH v2 net-next] net/tcp: trace all TCP/IP state transition with tcp_set_state tracepoint

[Yafang Shao]

2017-12-05 3:28 GMT+08:00 Marcelo Ricardo Leitner :
> On Sat, Dec 02, 2017 at 09:36:41AM +, Yafang Shao wrote:
>> The TCP/IP transition from TCP_LISTEN to TCP_SYN_RECV and some other
>> transitions are not traced with tcp_set_state tracepoint.
>>
>> In order to trace the whole tcp lifespans, two helpers are introduced,
>> void __tcp_set_state(struct sock *sk, int state)
>> void __sk_state_store(struct sock *sk, int newstate)
>>
>> When do TCP/IP state transition, we should use these two helpers or use
>> tcp_set_state() other than assigning a value to sk_state directly.
>>
>> Signed-off-by: Yafang Shao 
>>
>> ---
>> v2: test
>> ---
>>  include/net/tcp.h   |  2 ++
>>  net/ipv4/inet_connection_sock.c |  6 +++---
>>  net/ipv4/inet_hashtables.c  |  2 +-
>>  net/ipv4/tcp.c  | 12 
>>  4 files changed, 18 insertions(+), 4 deletions(-)
>>
>> diff --git a/include/net/tcp.h b/include/net/tcp.h
>> index 85ea578..4f2d015 100644
>> --- a/include/net/tcp.h
>> +++ b/include/net/tcp.h
>> @@ -1247,6 +1247,8 @@ static inline bool tcp_checksum_complete(struct 
>> sk_buff *skb)
>>   "Close Wait","Last ACK","Listen","Closing"
>>  };
>>  #endif
>> +void __sk_state_store(struct sock *sk, int newstate);
>> +void __tcp_set_state(struct sock *sk, int state);
>>  void tcp_set_state(struct sock *sk, int state);
>>
>>  void tcp_done(struct sock *sk);
>> diff --git a/net/ipv4/inet_connection_sock.c 
>> b/net/ipv4/inet_connection_sock.c
>> index 4ca46dc..f3967f1 100644
>> --- a/net/ipv4/inet_connection_sock.c
>> +++ b/net/ipv4/inet_connection_sock.c
>> @@ -783,7 +783,7 @@ struct sock *inet_csk_clone_lock(const struct sock *sk,
>>   if (newsk) {
>>   struct inet_connection_sock *newicsk = inet_csk(newsk);
>>
>> - newsk->sk_state = TCP_SYN_RECV;
>> + __tcp_set_state(newsk, TCP_SYN_RECV);
>>   newicsk->icsk_bind_hash = NULL;
>>
>>   inet_sk(newsk)->inet_dport = inet_rsk(req)->ir_rmt_port;
>> @@ -877,7 +877,7 @@ int inet_csk_listen_start(struct sock *sk, int backlog)
>>* It is OK, because this socket enters to hash table only
>>* after validation is complete.
>>*/
>> - sk_state_store(sk, TCP_LISTEN);
>> + __sk_state_store(sk, TCP_LISTEN);
>>   if (!sk->sk_prot->get_port(sk, inet->inet_num)) {
>>   inet->inet_sport = htons(inet->inet_num);
>>
>> @@ -888,7 +888,7 @@ int inet_csk_listen_start(struct sock *sk, int backlog)
>>   return 0;
>>   }
>>
>> - sk->sk_state = TCP_CLOSE;
>> + __tcp_set_state(sk, TCP_CLOSE);
>>   return err;
>>  }
>>  EXPORT_SYMBOL_GPL(inet_csk_listen_start);
>> diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
>> index e7d15fb..72c15b6 100644
>> --- a/net/ipv4/inet_hashtables.c
>> +++ b/net/ipv4/inet_hashtables.c
>> @@ -430,7 +430,7 @@ bool inet_ehash_nolisten(struct sock *sk, struct sock 
>> *osk)
>>   sock_prot_inuse_add(sock_net(sk), sk->sk_prot, 1);
>>   } else {
>>   percpu_counter_inc(sk->sk_prot->orphan_count);
>> - sk->sk_state = TCP_CLOSE;
>> + __tcp_set_state(sk, TCP_CLOSE);
>>   sock_set_flag(sk, SOCK_DEAD);
>>   inet_csk_destroy_sock(sk);
>>   }
>> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
>> index bf97317..2bc7e04 100644
>> --- a/net/ipv4/tcp.c
>> +++ b/net/ipv4/tcp.c
>> @@ -2036,6 +2036,18 @@ int tcp_recvmsg(struct sock *sk, struct msghdr *msg, 
>> size_t len, int nonblock,
>>  }
>>  EXPORT_SYMBOL(tcp_recvmsg);
>>
>> +void __sk_state_store(struct sock *sk, int newstate)
>> +{
>> + trace_tcp_set_state(sk, sk->sk_state, newstate);
>> + sk_state_store(sk, newstate);
>
> This sounds counter-intuitive, to have a __func() to call func(). It's
> usually the other way around.

Agree to that.

> There is only 1 call to sk_state_store in the stack, what about
> inverting these __ ?
>

Sounds like a good idea.

> I guess you applied the same standard as to the one below, but it's a
> different case.
>
>> +}
>> +
>> +void __tcp_set_state(struct sock *sk, int state)
>> +{
>> + trace_tcp_set_state(sk, sk->sk_state, state);
>> + sk->sk_state = state;
>> +}
>> +
>>  void tcp_set_state(struct sock *sk, int state)
>>  {
>>   int oldstate = sk->sk_state;
>> --
>> 1.8.3.1
>>

Re: [PATCH v2 net-next] net/tcp: trace all TCP/IP state transition with tcp_set_state tracepoint

[Yafang Shao]

2017-12-05 3:28 GMT+08:00 Marcelo Ricardo Leitner :
> On Sat, Dec 02, 2017 at 09:36:41AM +, Yafang Shao wrote:
>> The TCP/IP transition from TCP_LISTEN to TCP_SYN_RECV and some other
>> transitions are not traced with tcp_set_state tracepoint.
>>
>> In order to trace the whole tcp lifespans, two helpers are introduced,
>> void __tcp_set_state(struct sock *sk, int state)
>> void __sk_state_store(struct sock *sk, int newstate)
>>
>> When do TCP/IP state transition, we should use these two helpers or use
>> tcp_set_state() other than assigning a value to sk_state directly.
>>
>> Signed-off-by: Yafang Shao 
>>
>> ---
>> v2: test
>> ---
>>  include/net/tcp.h   |  2 ++
>>  net/ipv4/inet_connection_sock.c |  6 +++---
>>  net/ipv4/inet_hashtables.c  |  2 +-
>>  net/ipv4/tcp.c  | 12 
>>  4 files changed, 18 insertions(+), 4 deletions(-)
>>
>> diff --git a/include/net/tcp.h b/include/net/tcp.h
>> index 85ea578..4f2d015 100644
>> --- a/include/net/tcp.h
>> +++ b/include/net/tcp.h
>> @@ -1247,6 +1247,8 @@ static inline bool tcp_checksum_complete(struct 
>> sk_buff *skb)
>>   "Close Wait","Last ACK","Listen","Closing"
>>  };
>>  #endif
>> +void __sk_state_store(struct sock *sk, int newstate);
>> +void __tcp_set_state(struct sock *sk, int state);
>>  void tcp_set_state(struct sock *sk, int state);
>>
>>  void tcp_done(struct sock *sk);
>> diff --git a/net/ipv4/inet_connection_sock.c 
>> b/net/ipv4/inet_connection_sock.c
>> index 4ca46dc..f3967f1 100644
>> --- a/net/ipv4/inet_connection_sock.c
>> +++ b/net/ipv4/inet_connection_sock.c
>> @@ -783,7 +783,7 @@ struct sock *inet_csk_clone_lock(const struct sock *sk,
>>   if (newsk) {
>>   struct inet_connection_sock *newicsk = inet_csk(newsk);
>>
>> - newsk->sk_state = TCP_SYN_RECV;
>> + __tcp_set_state(newsk, TCP_SYN_RECV);
>>   newicsk->icsk_bind_hash = NULL;
>>
>>   inet_sk(newsk)->inet_dport = inet_rsk(req)->ir_rmt_port;
>> @@ -877,7 +877,7 @@ int inet_csk_listen_start(struct sock *sk, int backlog)
>>* It is OK, because this socket enters to hash table only
>>* after validation is complete.
>>*/
>> - sk_state_store(sk, TCP_LISTEN);
>> + __sk_state_store(sk, TCP_LISTEN);
>>   if (!sk->sk_prot->get_port(sk, inet->inet_num)) {
>>   inet->inet_sport = htons(inet->inet_num);
>>
>> @@ -888,7 +888,7 @@ int inet_csk_listen_start(struct sock *sk, int backlog)
>>   return 0;
>>   }
>>
>> - sk->sk_state = TCP_CLOSE;
>> + __tcp_set_state(sk, TCP_CLOSE);
>>   return err;
>>  }
>>  EXPORT_SYMBOL_GPL(inet_csk_listen_start);
>> diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
>> index e7d15fb..72c15b6 100644
>> --- a/net/ipv4/inet_hashtables.c
>> +++ b/net/ipv4/inet_hashtables.c
>> @@ -430,7 +430,7 @@ bool inet_ehash_nolisten(struct sock *sk, struct sock 
>> *osk)
>>   sock_prot_inuse_add(sock_net(sk), sk->sk_prot, 1);
>>   } else {
>>   percpu_counter_inc(sk->sk_prot->orphan_count);
>> - sk->sk_state = TCP_CLOSE;
>> + __tcp_set_state(sk, TCP_CLOSE);
>>   sock_set_flag(sk, SOCK_DEAD);
>>   inet_csk_destroy_sock(sk);
>>   }
>> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
>> index bf97317..2bc7e04 100644
>> --- a/net/ipv4/tcp.c
>> +++ b/net/ipv4/tcp.c
>> @@ -2036,6 +2036,18 @@ int tcp_recvmsg(struct sock *sk, struct msghdr *msg, 
>> size_t len, int nonblock,
>>  }
>>  EXPORT_SYMBOL(tcp_recvmsg);
>>
>> +void __sk_state_store(struct sock *sk, int newstate)
>> +{
>> + trace_tcp_set_state(sk, sk->sk_state, newstate);
>> + sk_state_store(sk, newstate);
>
> This sounds counter-intuitive, to have a __func() to call func(). It's
> usually the other way around.

Agree to that.

> There is only 1 call to sk_state_store in the stack, what about
> inverting these __ ?
>

Sounds like a good idea.

> I guess you applied the same standard as to the one below, but it's a
> different case.
>
>> +}
>> +
>> +void __tcp_set_state(struct sock *sk, int state)
>> +{
>> + trace_tcp_set_state(sk, sk->sk_state, state);
>> + sk->sk_state = state;
>> +}
>> +
>>  void tcp_set_state(struct sock *sk, int state)
>>  {
>>   int oldstate = sk->sk_state;
>> --
>> 1.8.3.1
>>

Re: [PATCH v9 3/5] perf utils: use pmu->is_uncore to detect PMU UNCORE devices

[Ganapatrao Kulkarni]

thanks Jin Yao for point this out.

looks like logic of leveraging uncore device type(which i have changed
in v9) does not go well
with some json events of x86.
can you please try below diff(logic used till v8), which keeps the
original logic of identifying core/cpu PMUs.


diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 5ad8a18..57e38fd 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -538,6 +538,34 @@ static bool pmu_is_uncore(const char *name)
 }

 /*
+ *  PMU CORE devices have different name other than cpu in sysfs on some
+ *  platforms. looking for possible sysfs files to identify as core device.
+ */
+static int is_pmu_core(const char *name)
+{
+ struct stat st;
+ char path[PATH_MAX];
+ const char *sysfs = sysfs__mountpoint();
+
+ if (!sysfs)
+ return 0;
+
+ /* Look for cpu sysfs (x86 and others) */
+ scnprintf(path, PATH_MAX, "%s/bus/event_source/devices/cpu", sysfs);
+ if ((stat(path, ) == 0) &&
+ (strncmp(name, "cpu", strlen("cpu")) == 0))
+ return 1;
+
+ /* Look for cpu sysfs (specific to arm) */
+ scnprintf(path, PATH_MAX, "%s/bus/event_source/devices/%s/cpus",
+ sysfs, name);
+ if (stat(path, ) == 0)
+ return 1;
+
+ return 0;
+}
+
+/*
  * Return the CPU id as a raw string.
  *
  * Each architecture should provide a more precise id string that
@@ -641,7 +669,7 @@ static void pmu_add_cpu_aliases(struct list_head
*head, struct perf_pmu *pmu)
  break;
  }

- if (pmu->is_uncore) {
+ if (!is_pmu_core(name)) {
  /* check for uncore devices */
  if (pe->pmu == NULL)
  continue;

i have tried this diff on my x86 PC(haswell) and looks to be ok.
please confirm your testing on skylake.

gkulkarni@gkFc25>perf>> ./perf stat --per-thread -p 12663 -M CPI,IPC sleep 1

 Performance counter stats for process id '12663':

bash-12663   278,886  inst_retired.any:u
bash-12663   482,284  cycles:u
bash-12663   278,886  inst_retired.any:u
bash-12663   483,597
cpu_clk_unhalted.thread:u

   1.000923760 seconds time elapsed


On Tue, Dec 5, 2017 at 7:42 AM, Jin, Yao  wrote:
> Hi Kulkarni, Arnaldo,
>
> This patch has been merged in perf/core branch today.
>
> But I see a regression issue when I run the 'perf stat'.
>
> With bisect checking, I locate to this patch.
>
> commit ad8737a08973f5dca632bdd63cf2abc99670e540
> Author: Ganapatrao Kulkarni 
> Date:   Tue Oct 17 00:02:20 2017 +0530
>
> perf pmu: Use pmu->is_uncore to detect UNCORE devices
>
> For example (on Intel skylake desktop),
>
> 1. The correct output should be (without this patch):
>
> root@skl:/tmp# perf stat --per-thread -p 1754 -M CPI,IPC
> ^C
>  Performance counter stats for process id '1754':
>
>   vmstat-1754  1,882,798  inst_retired.any #
> 0.8 CPI
>   vmstat-1754  1,589,720  cycles
>   vmstat-1754  1,882,798  inst_retired.any #
> 1.2 IPC
>   vmstat-1754  1,589,720  cpu_clk_unhalted.thread
>
>2.647443167 seconds time elapsed
>
> 2. With this patch, the output will be:
>
> root@skl:/tmp# perf stat --per-thread -p 1754 -M CPI,IPC
> ^C
>  Performance counter stats for process id '1754':
>
>   vmstat-1754  1,945,589  inst_retired.any
>   vmstat-1754  inst_retired.any
>   vmstat-1754  1,609,892  cycles
>   vmstat-1754  1,945,589  inst_retired.any
>   vmstat-1754  inst_retired.any
>   vmstat-1754  1,609,892  cpu_clk_unhalted.thread
>   vmstat-1754  cpu_clk_unhalted.thread
>
>3.051274166 seconds time elapsed
>
> Could you please help to take a look?
>
> Thanks
> Jin Yao
>
>
> On 10/17/2017 2:32 AM, Ganapatrao Kulkarni wrote:
>>
>> PMU CORE devices are identified using sysfs filename cpu, however
>> on some platforms(like arm/arm64), PMU CORE sysfs name is not cpu.
>> Hence cpu cannot be used to differentiate PMU CORE/UNCORE devices.
>>
>> commit:
>>   66ec1191 ("perf pmu: Unbreak perf record for arm/arm64 with events with
>> explicit PMU")
>>
>> has introduced pmu->is_uncore, which is set to PMU UNCORE devices only.
>> Adding changes to use pmu->is_uncore to identify UNCORE devices.
>>
>> Acked-by: Will Deacon 
>> Tested-by: Shaokun Zhang 
>> Signed-off-by: Ganapatrao Kulkarni 
>> ---
>>   tools/perf/util/pmu.c | 11 +++
>>   1 file changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
>> index 8b17db5..9110718 100644
>> --- a/tools/perf/util/pmu.c
>> +++ b/tools/perf/util/pmu.c
>> @@ -603,7 +603,6 @@ static void pmu_add_cpu_aliases(struct list_head
>> *head, struct perf_pmu *pmu)
>>  */
>> i = 0;
>> while (1) {
>> -   

Re: [PATCH v9 3/5] perf utils: use pmu->is_uncore to detect PMU UNCORE devices

[Ganapatrao Kulkarni]

thanks Jin Yao for point this out.

looks like logic of leveraging uncore device type(which i have changed
in v9) does not go well
with some json events of x86.
can you please try below diff(logic used till v8), which keeps the
original logic of identifying core/cpu PMUs.


diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 5ad8a18..57e38fd 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -538,6 +538,34 @@ static bool pmu_is_uncore(const char *name)
 }

 /*
+ *  PMU CORE devices have different name other than cpu in sysfs on some
+ *  platforms. looking for possible sysfs files to identify as core device.
+ */
+static int is_pmu_core(const char *name)
+{
+ struct stat st;
+ char path[PATH_MAX];
+ const char *sysfs = sysfs__mountpoint();
+
+ if (!sysfs)
+ return 0;
+
+ /* Look for cpu sysfs (x86 and others) */
+ scnprintf(path, PATH_MAX, "%s/bus/event_source/devices/cpu", sysfs);
+ if ((stat(path, ) == 0) &&
+ (strncmp(name, "cpu", strlen("cpu")) == 0))
+ return 1;
+
+ /* Look for cpu sysfs (specific to arm) */
+ scnprintf(path, PATH_MAX, "%s/bus/event_source/devices/%s/cpus",
+ sysfs, name);
+ if (stat(path, ) == 0)
+ return 1;
+
+ return 0;
+}
+
+/*
  * Return the CPU id as a raw string.
  *
  * Each architecture should provide a more precise id string that
@@ -641,7 +669,7 @@ static void pmu_add_cpu_aliases(struct list_head
*head, struct perf_pmu *pmu)
  break;
  }

- if (pmu->is_uncore) {
+ if (!is_pmu_core(name)) {
  /* check for uncore devices */
  if (pe->pmu == NULL)
  continue;

i have tried this diff on my x86 PC(haswell) and looks to be ok.
please confirm your testing on skylake.

gkulkarni@gkFc25>perf>> ./perf stat --per-thread -p 12663 -M CPI,IPC sleep 1

 Performance counter stats for process id '12663':

bash-12663   278,886  inst_retired.any:u
bash-12663   482,284  cycles:u
bash-12663   278,886  inst_retired.any:u
bash-12663   483,597
cpu_clk_unhalted.thread:u

   1.000923760 seconds time elapsed


On Tue, Dec 5, 2017 at 7:42 AM, Jin, Yao  wrote:
> Hi Kulkarni, Arnaldo,
>
> This patch has been merged in perf/core branch today.
>
> But I see a regression issue when I run the 'perf stat'.
>
> With bisect checking, I locate to this patch.
>
> commit ad8737a08973f5dca632bdd63cf2abc99670e540
> Author: Ganapatrao Kulkarni 
> Date:   Tue Oct 17 00:02:20 2017 +0530
>
> perf pmu: Use pmu->is_uncore to detect UNCORE devices
>
> For example (on Intel skylake desktop),
>
> 1. The correct output should be (without this patch):
>
> root@skl:/tmp# perf stat --per-thread -p 1754 -M CPI,IPC
> ^C
>  Performance counter stats for process id '1754':
>
>   vmstat-1754  1,882,798  inst_retired.any #
> 0.8 CPI
>   vmstat-1754  1,589,720  cycles
>   vmstat-1754  1,882,798  inst_retired.any #
> 1.2 IPC
>   vmstat-1754  1,589,720  cpu_clk_unhalted.thread
>
>2.647443167 seconds time elapsed
>
> 2. With this patch, the output will be:
>
> root@skl:/tmp# perf stat --per-thread -p 1754 -M CPI,IPC
> ^C
>  Performance counter stats for process id '1754':
>
>   vmstat-1754  1,945,589  inst_retired.any
>   vmstat-1754  inst_retired.any
>   vmstat-1754  1,609,892  cycles
>   vmstat-1754  1,945,589  inst_retired.any
>   vmstat-1754  inst_retired.any
>   vmstat-1754  1,609,892  cpu_clk_unhalted.thread
>   vmstat-1754  cpu_clk_unhalted.thread
>
>3.051274166 seconds time elapsed
>
> Could you please help to take a look?
>
> Thanks
> Jin Yao
>
>
> On 10/17/2017 2:32 AM, Ganapatrao Kulkarni wrote:
>>
>> PMU CORE devices are identified using sysfs filename cpu, however
>> on some platforms(like arm/arm64), PMU CORE sysfs name is not cpu.
>> Hence cpu cannot be used to differentiate PMU CORE/UNCORE devices.
>>
>> commit:
>>   66ec1191 ("perf pmu: Unbreak perf record for arm/arm64 with events with
>> explicit PMU")
>>
>> has introduced pmu->is_uncore, which is set to PMU UNCORE devices only.
>> Adding changes to use pmu->is_uncore to identify UNCORE devices.
>>
>> Acked-by: Will Deacon 
>> Tested-by: Shaokun Zhang 
>> Signed-off-by: Ganapatrao Kulkarni 
>> ---
>>   tools/perf/util/pmu.c | 11 +++
>>   1 file changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
>> index 8b17db5..9110718 100644
>> --- a/tools/perf/util/pmu.c
>> +++ b/tools/perf/util/pmu.c
>> @@ -603,7 +603,6 @@ static void pmu_add_cpu_aliases(struct list_head
>> *head, struct perf_pmu *pmu)
>>  */
>> i = 0;
>> while (1) {
>> -   const char *pname;
>> pe = >table[i++];
>> if (!pe->name) {
>> @@ -612,9 +611,13 @@ static void 

[PATCH RESEND] arm64: fault: avoid send SIGBUS two times

[Dongjiu Geng]

If APEI handling the memory error is failed, the do_mem_abort()
and do_sea() will all deliver SIGBUS. In fact, sending one time
can be enough, so correct it.

Signed-off-by: Dongjiu Geng 
---
 arch/arm64/mm/fault.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index fcf2ede3..9e3f7ca 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -570,7 +570,6 @@ static int do_sea(unsigned long addr, unsigned int esr, 
struct pt_regs *regs)
 {
struct siginfo info;
const struct fault_info *inf;
-   int ret = 0;
 
inf = esr_to_fault_info(esr);
pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
@@ -585,7 +584,7 @@ static int do_sea(unsigned long addr, unsigned int esr, 
struct pt_regs *regs)
if (interrupts_enabled(regs))
nmi_enter();
 
-   ret = ghes_notify_sea();
+   ghes_notify_sea();
 
if (interrupts_enabled(regs))
nmi_exit();
@@ -600,7 +599,7 @@ static int do_sea(unsigned long addr, unsigned int esr, 
struct pt_regs *regs)
info.si_addr  = (void __user *)addr;
arm64_notify_die("", regs, , esr);
 
-   return ret;
+   return 0;
 }
 
 static const struct fault_info fault_info[] = {
-- 
2.10.1

[PATCH RESEND] arm64: fault: avoid send SIGBUS two times

[Dongjiu Geng]

If APEI handling the memory error is failed, the do_mem_abort()
and do_sea() will all deliver SIGBUS. In fact, sending one time
can be enough, so correct it.

Signed-off-by: Dongjiu Geng 
---
 arch/arm64/mm/fault.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index fcf2ede3..9e3f7ca 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -570,7 +570,6 @@ static int do_sea(unsigned long addr, unsigned int esr, 
struct pt_regs *regs)
 {
struct siginfo info;
const struct fault_info *inf;
-   int ret = 0;
 
inf = esr_to_fault_info(esr);
pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
@@ -585,7 +584,7 @@ static int do_sea(unsigned long addr, unsigned int esr, 
struct pt_regs *regs)
if (interrupts_enabled(regs))
nmi_enter();
 
-   ret = ghes_notify_sea();
+   ghes_notify_sea();
 
if (interrupts_enabled(regs))
nmi_exit();
@@ -600,7 +599,7 @@ static int do_sea(unsigned long addr, unsigned int esr, 
struct pt_regs *regs)
info.si_addr  = (void __user *)addr;
arm64_notify_die("", regs, , esr);
 
-   return ret;
+   return 0;
 }
 
 static const struct fault_info fault_info[] = {
-- 
2.10.1

Re: [PATCH 4.9 00/38] 4.9.67-stable review

[Naresh Kamboju]

On 4 December 2017 at 21:29, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.9.67 release.
> There are 38 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Dec  6 15:59:56 UTC 2017.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.67-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.9.67-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 3efaa252aaafecdd666059be175f88ebd95ea236
git describe: v4.9.66-39-g3efaa252aaaf
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.66-39-g3efaa252aaaf


No regressions (compared to build v4.9.66-39-ga89dba36bba8)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 34, skip: 20
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 982, skip: 121
* ltp-timers-tests - pass: 12,

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 34, skip: 19
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 939, skip: 156
* ltp-timers-tests - pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - pass: 31, skip: 23
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1036, skip: 66
* ltp-timers-tests - pass: 12,

x86_64
* boot - pass: 20,
* kselftest - pass: 49, skip: 20
* libhugetlbfs - pass: 76, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 63,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 18,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 2,
* ltp-ipc-tests - pass: 8,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 957, skip: 163
* ltp-timers-tests - pass: 11,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Tested-by: Naresh Kamboju 

Re: [PATCH 4.9 00/38] 4.9.67-stable review

[Naresh Kamboju]

On 4 December 2017 at 21:29, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.9.67 release.
> There are 38 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Dec  6 15:59:56 UTC 2017.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.67-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.9.67-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 3efaa252aaafecdd666059be175f88ebd95ea236
git describe: v4.9.66-39-g3efaa252aaaf
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.66-39-g3efaa252aaaf


No regressions (compared to build v4.9.66-39-ga89dba36bba8)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 34, skip: 20
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 982, skip: 121
* ltp-timers-tests - pass: 12,

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 34, skip: 19
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 939, skip: 156
* ltp-timers-tests - pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - pass: 31, skip: 23
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1036, skip: 66
* ltp-timers-tests - pass: 12,

x86_64
* boot - pass: 20,
* kselftest - pass: 49, skip: 20
* libhugetlbfs - pass: 76, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 63,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 18,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 2,
* ltp-ipc-tests - pass: 8,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 957, skip: 163
* ltp-timers-tests - pass: 11,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Tested-by: Naresh Kamboju 

Re: [PATCH v2] mmap.2: MAP_FIXED updated documentation

[Michal Hocko]

On Mon 04-12-17 18:52:27, John Hubbard wrote:
> On 12/04/2017 03:31 AM, Mike Rapoport wrote:
> > On Sun, Dec 03, 2017 at 06:14:11PM -0800, john.hubb...@gmail.com wrote:
> >> From: John Hubbard 
> >>
> [...]
> >> +.IP
> >> +Given the above limitations, one of the very few ways to use this option
> >> +safely is: mmap() a region, without specifying MAP_FIXED. Then, within 
> >> that
> >> +region, call mmap(MAP_FIXED) to suballocate regions. This avoids both the
> >> +portability problem (because the first mmap call lets the kernel pick the
> >> +address), and the address space corruption problem (because the region 
> >> being
> >> +overwritten is already owned by the calling thread).
> > 
> > Maybe "address space corruption problem caused by implicit calls to mmap"?
> > The region allocated with the first mmap is not exactly owned by the
> > thread and a multi-thread application can still corrupt its memory if
> > different threads use mmap(MAP_FIXED) for overlapping regions.
> > 
> > My 2 cents.
> > 
> 
> Hi Mike,
> 
> Yes, thanks for picking through this, and I agree that the above is 
> misleading.
> It should definitely not use the word "owned" at all. Re-doing the whole 
> paragraph in order to make it all fit together nicely, I get this:
> 
> "Given the above limitations, one of the very few ways to use this option
> safely is: mmap() an enclosing region, without specifying MAP_FIXED.
> Then, within that region, call mmap(MAP_FIXED) to suballocate regions
> within the enclosing region. This avoids both the portability problem 
> (because the first mmap call lets the kernel pick the address), and the 
> address space corruption problem (because implicit calls to mmap will 
> not affect the already-mapped enclosing region)."
> 
> ...how's that sound to you? I'll post a v3 soon with this.

It sounds to me you are trying to tell way to much while actually being
a bit misleading. Even sub-range MAP_FIXED is not multi-thread safe.

Really the more corner cases you will try to cover the worse the end
result will end up. I would just try to be simple here and mention the
address space corruption issues you've had earlier and be done with it.
Maybe add a note that some architectures might need a special alignement
and fail if it is not the case but nothing really specific.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2] mmap.2: MAP_FIXED updated documentation

[Michal Hocko]

On Mon 04-12-17 18:52:27, John Hubbard wrote:
> On 12/04/2017 03:31 AM, Mike Rapoport wrote:
> > On Sun, Dec 03, 2017 at 06:14:11PM -0800, john.hubb...@gmail.com wrote:
> >> From: John Hubbard 
> >>
> [...]
> >> +.IP
> >> +Given the above limitations, one of the very few ways to use this option
> >> +safely is: mmap() a region, without specifying MAP_FIXED. Then, within 
> >> that
> >> +region, call mmap(MAP_FIXED) to suballocate regions. This avoids both the
> >> +portability problem (because the first mmap call lets the kernel pick the
> >> +address), and the address space corruption problem (because the region 
> >> being
> >> +overwritten is already owned by the calling thread).
> > 
> > Maybe "address space corruption problem caused by implicit calls to mmap"?
> > The region allocated with the first mmap is not exactly owned by the
> > thread and a multi-thread application can still corrupt its memory if
> > different threads use mmap(MAP_FIXED) for overlapping regions.
> > 
> > My 2 cents.
> > 
> 
> Hi Mike,
> 
> Yes, thanks for picking through this, and I agree that the above is 
> misleading.
> It should definitely not use the word "owned" at all. Re-doing the whole 
> paragraph in order to make it all fit together nicely, I get this:
> 
> "Given the above limitations, one of the very few ways to use this option
> safely is: mmap() an enclosing region, without specifying MAP_FIXED.
> Then, within that region, call mmap(MAP_FIXED) to suballocate regions
> within the enclosing region. This avoids both the portability problem 
> (because the first mmap call lets the kernel pick the address), and the 
> address space corruption problem (because implicit calls to mmap will 
> not affect the already-mapped enclosing region)."
> 
> ...how's that sound to you? I'll post a v3 soon with this.

It sounds to me you are trying to tell way to much while actually being
a bit misleading. Even sub-range MAP_FIXED is not multi-thread safe.

Really the more corner cases you will try to cover the worse the end
result will end up. I would just try to be simple here and mention the
address space corruption issues you've had earlier and be done with it.
Maybe add a note that some architectures might need a special alignement
and fail if it is not the case but nothing really specific.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] skb_array: fix NULL-pointer exception

[Jason Wang]

On 2017年12月05日 12:40, Michael S. Tsirkin wrote:

On Tue, Dec 05, 2017 at 11:11:14AM +0800, Jason Wang wrote:


On 2017年12月04日 22:24, George Cherian wrote:

While running a multiple VM testscase with each VM running iperf
traffic between others the following kernel NULL pointer exception
was seen.

Race appears when the tun driver instance of one VM calls skb_array_produce
(from tun_net_xmit) and the the destined VM's skb_array_consume
(from tun_ring_recv), which could run concurrently on another core. Due to
which the sock_wfree gets called again

from the tun_ring_recv context.

OK, so is the implication that there are two concurrent callers for 
tun_ring_recv
on the same device?


I guess not since VM is used (unless there's some misconfiguration).




The fix is to add write/read barrier calls to be sure that we get proper
values in the tun_ring_recv context.

Crash log
[35321.580227] Unable to handle kernel NULL pointer dereference at virtual 
address 0060
[35321.596720] pgd = 809ee552f000
[35321.603723] [0060] *pgd=009f514ac003, *pud=009f54f7c003, 
*pmd=
[35321.620588] Internal error: Oops: 9606 1 SMP
[35321.630461] Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE 
nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 
nf_defrag_ipv4 xt_4
[35321.728501] CPU: 114 PID: 5560 Comm: qemu-system-aar Not tainted 
4.11.8-4k-vhe-lse+ #3
[35321.744510] Hardware name: Cavium Inc. Unknown/Unknown, BIOS 1.0 07/24/2017
[35321.758602] task: 80bed7fca880 task.stack: 80beb5128000
[35321.770600] PC is at sock_wfree+0x24/0x80
[35321.778746] LR is at skb_release_head_state+0x68/0xf8
[35321.788979] pc : [] lr : [] pstate: 
40400149
[35321.803930] sp : 80beb512bc30
[35321.810648] x29: 80beb512bc30 x28: 80bed7fca880
[35321.821400] x27: 004e x26: 
[35321.832156] x25: 000c x24: 
[35321.842947] x23: 809ece3e4900 x22: 80beb512be00
[35321.853729] x21: 09138000 x20: 0144
[35321.864507] x19:  x18: 0014
[35321.875276] x17: 9d9689a0 x16: 0828b3f8
[35321.886048] x15: 504d7b00 x14: e90ab50c48680a08
[35321.896824] x13: 010117773f52 x12: 1080d422c00e5db6
[35321.907595] x11: 68c322bd3930cf7a x10: a8c0d07aa8c0ad16
[35321.918352] x9 : 1da4ed90 x8 : b50c48680a080101
[35321.929099] x7 : 17770c521080 x6 : 1d6c13f2
[35321.939865] x5 : 1d6c13f2 x4 : 000e
[35321.950619] x3 : 00085ff97d82 x2 : 
[35321.961376] x1 : 08a772d8 x0 : 0500
[35321.975193] Process qemu-system-aar (pid: 5560, stack limit = 
0x80beb5128000)
[35321.990347] Stack: (0x80beb512bc30 to 0x80beb512c000)
[35322.001982] bc20: 80beb512bc50 08a79238
[35322.017817] bc40: 809e8fd7be00 004e 80beb512bc70 
08a79488
[35322.033651] bc60: 809e8fd7be00 0881307c 80beb512bc90 
08a79678
[35322.049489] bc80: 809e8fd7be00 80beb512be00 80beb512bcb0 
08812f24
[35322.065321] bca0: 809e8fd7be00 004e 80beb512bd50 
088133f0
[35322.081165] bcc0: 809ece3e4900 00011000 80beb512bdd8 
80beb512be00
[35322.097001] bce0: 1d6c13a4 0015 0124 
003f
[35322.112866] bd00: 08bc2000 0847b5ac 0002 
80be0008
[35322.128701] bd20: 00220001 80bed7fc0010 08100c38 

[35322.144539] bd40:  00040b08 80beb512bd80 
08288f80
[35322.160395] bd60: 09138000 809ee7cd3500 00011000 
80beb512beb0
[35322.176255] bd80: 80beb512be30 0828a224 00011000 
809ee7cd3500
[35322.192109] bda0: 1d6c13a4 80beb512beb0 00011000 

[35322.207974] bdc0:  1d6c13a4 00011000 
809ee7cd3500
[35322.223822] bde0: 004e   

[35322.239661] be00: 80be 004e 00010fb2 
80beb512bdc8
[35322.255519] be20: 0001 00040b08 80beb512be70 
0828b464
[35322.271392] be40: 09138000 809ee7cd3501 809ee7cd3500 
1d6c13a4
[35322.287255] be60: 00011000 0015  
080833f0
[35322.303090] be80:  80bef0071000  
9d9689cc
[35322.318951] bea0: 8000 80bef0071000 004e 
00040b08
[35322.334771] bec0: 000e 1d6c13a4 00011000 
9cc89108
[35322.350640] bee0: 0002 9cc89000 9cc896f0 

[35322.366500] bf00: 003f 1da4ed90 a8c0d07aa8c0ad16 
68c322bd3930cf7a
[35322.382358] bf20: 1080d422c00e5db6 010117773f52 e90ab50c48680a08 

Re: [PATCH] skb_array: fix NULL-pointer exception

[Jason Wang]

On 2017年12月05日 12:40, Michael S. Tsirkin wrote:

On Tue, Dec 05, 2017 at 11:11:14AM +0800, Jason Wang wrote:


On 2017年12月04日 22:24, George Cherian wrote:

While running a multiple VM testscase with each VM running iperf
traffic between others the following kernel NULL pointer exception
was seen.

Race appears when the tun driver instance of one VM calls skb_array_produce
(from tun_net_xmit) and the the destined VM's skb_array_consume
(from tun_ring_recv), which could run concurrently on another core. Due to
which the sock_wfree gets called again

from the tun_ring_recv context.

OK, so is the implication that there are two concurrent callers for 
tun_ring_recv
on the same device?


I guess not since VM is used (unless there's some misconfiguration).




The fix is to add write/read barrier calls to be sure that we get proper
values in the tun_ring_recv context.

Crash log
[35321.580227] Unable to handle kernel NULL pointer dereference at virtual 
address 0060
[35321.596720] pgd = 809ee552f000
[35321.603723] [0060] *pgd=009f514ac003, *pud=009f54f7c003, 
*pmd=
[35321.620588] Internal error: Oops: 9606 1 SMP
[35321.630461] Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE 
nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 
nf_defrag_ipv4 xt_4
[35321.728501] CPU: 114 PID: 5560 Comm: qemu-system-aar Not tainted 
4.11.8-4k-vhe-lse+ #3
[35321.744510] Hardware name: Cavium Inc. Unknown/Unknown, BIOS 1.0 07/24/2017
[35321.758602] task: 80bed7fca880 task.stack: 80beb5128000
[35321.770600] PC is at sock_wfree+0x24/0x80
[35321.778746] LR is at skb_release_head_state+0x68/0xf8
[35321.788979] pc : [] lr : [] pstate: 
40400149
[35321.803930] sp : 80beb512bc30
[35321.810648] x29: 80beb512bc30 x28: 80bed7fca880
[35321.821400] x27: 004e x26: 
[35321.832156] x25: 000c x24: 
[35321.842947] x23: 809ece3e4900 x22: 80beb512be00
[35321.853729] x21: 09138000 x20: 0144
[35321.864507] x19:  x18: 0014
[35321.875276] x17: 9d9689a0 x16: 0828b3f8
[35321.886048] x15: 504d7b00 x14: e90ab50c48680a08
[35321.896824] x13: 010117773f52 x12: 1080d422c00e5db6
[35321.907595] x11: 68c322bd3930cf7a x10: a8c0d07aa8c0ad16
[35321.918352] x9 : 1da4ed90 x8 : b50c48680a080101
[35321.929099] x7 : 17770c521080 x6 : 1d6c13f2
[35321.939865] x5 : 1d6c13f2 x4 : 000e
[35321.950619] x3 : 00085ff97d82 x2 : 
[35321.961376] x1 : 08a772d8 x0 : 0500
[35321.975193] Process qemu-system-aar (pid: 5560, stack limit = 
0x80beb5128000)
[35321.990347] Stack: (0x80beb512bc30 to 0x80beb512c000)
[35322.001982] bc20: 80beb512bc50 08a79238
[35322.017817] bc40: 809e8fd7be00 004e 80beb512bc70 
08a79488
[35322.033651] bc60: 809e8fd7be00 0881307c 80beb512bc90 
08a79678
[35322.049489] bc80: 809e8fd7be00 80beb512be00 80beb512bcb0 
08812f24
[35322.065321] bca0: 809e8fd7be00 004e 80beb512bd50 
088133f0
[35322.081165] bcc0: 809ece3e4900 00011000 80beb512bdd8 
80beb512be00
[35322.097001] bce0: 1d6c13a4 0015 0124 
003f
[35322.112866] bd00: 08bc2000 0847b5ac 0002 
80be0008
[35322.128701] bd20: 00220001 80bed7fc0010 08100c38 

[35322.144539] bd40:  00040b08 80beb512bd80 
08288f80
[35322.160395] bd60: 09138000 809ee7cd3500 00011000 
80beb512beb0
[35322.176255] bd80: 80beb512be30 0828a224 00011000 
809ee7cd3500
[35322.192109] bda0: 1d6c13a4 80beb512beb0 00011000 

[35322.207974] bdc0:  1d6c13a4 00011000 
809ee7cd3500
[35322.223822] bde0: 004e   

[35322.239661] be00: 80be 004e 00010fb2 
80beb512bdc8
[35322.255519] be20: 0001 00040b08 80beb512be70 
0828b464
[35322.271392] be40: 09138000 809ee7cd3501 809ee7cd3500 
1d6c13a4
[35322.287255] be60: 00011000 0015  
080833f0
[35322.303090] be80:  80bef0071000  
9d9689cc
[35322.318951] bea0: 8000 80bef0071000 004e 
00040b08
[35322.334771] bec0: 000e 1d6c13a4 00011000 
9cc89108
[35322.350640] bee0: 0002 9cc89000 9cc896f0 

[35322.366500] bf00: 003f 1da4ed90 a8c0d07aa8c0ad16 
68c322bd3930cf7a
[35322.382358] bf20: 1080d422c00e5db6 010117773f52 e90ab50c48680a08 

Re: [PATCH v2] mmap.2: MAP_FIXED updated documentation

[Michal Hocko]

On Mon 04-12-17 18:14:18, John Hubbard wrote:
> On 12/04/2017 02:55 AM, Cyril Hrubis wrote:
> > Hi!
> > I know that we are not touching the rest of the existing description for
> > MAP_FIXED however the second sentence in the manual page says that "addr
> > must be a multiple of the page size." Which however is misleading as
> > this is not enough on some architectures. Code in the wild seems to
> > (mis)use SHMLBA for aligment purposes but I'm not sure that we should
> > advise something like that in the manpages.
> > 
> > So what about something as:
> > 
> > "addr must be suitably aligned, for most architectures multiple of page
> > size is sufficient, however some may impose additional restrictions for
> > page mapping addresses."
> > 
> 
> Hi Cyril,
> 
> Right, so I've been looking into this today, and I think we can go a bit
> further than that, even. The kernel, as far back as the *original* git
> commit in 2005, implements mmap on ARM by requiring that the address is
> aligned to SHMLBA:
> 
> arch/arm/mm/mmap.c:50:
> 
>   if (flags & MAP_FIXED) {
>   if (aliasing && flags & MAP_SHARED &&
>   (addr - (pgoff << PAGE_SHIFT)) & (SHMLBA - 1))
>   return -EINVAL;
>   return addr;
>   }
> 
> So, given that this has been the implementation for the last 12+ years (and
> probably the whole time, in fact), I think we can be bold enough to use this
> wording for the second sentence of MAP_FIXED:
> 
> "addr must be a multiple of SHMLBA (), which in turn is either
> the system page size (on many architectures) or a multiple of the system
> page size (on some architectures)."
> 
> What do you think?

I am not sure this is a good idea. This is pulling way too many
implementation details into the man page IMHO. Note that your wording is
even incorrect because this applies only to shared mappings and on some
architectures it even requires special memory regions. We do not want
all that in the man page...

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2] mmap.2: MAP_FIXED updated documentation

[Michal Hocko]

On Mon 04-12-17 18:14:18, John Hubbard wrote:
> On 12/04/2017 02:55 AM, Cyril Hrubis wrote:
> > Hi!
> > I know that we are not touching the rest of the existing description for
> > MAP_FIXED however the second sentence in the manual page says that "addr
> > must be a multiple of the page size." Which however is misleading as
> > this is not enough on some architectures. Code in the wild seems to
> > (mis)use SHMLBA for aligment purposes but I'm not sure that we should
> > advise something like that in the manpages.
> > 
> > So what about something as:
> > 
> > "addr must be suitably aligned, for most architectures multiple of page
> > size is sufficient, however some may impose additional restrictions for
> > page mapping addresses."
> > 
> 
> Hi Cyril,
> 
> Right, so I've been looking into this today, and I think we can go a bit
> further than that, even. The kernel, as far back as the *original* git
> commit in 2005, implements mmap on ARM by requiring that the address is
> aligned to SHMLBA:
> 
> arch/arm/mm/mmap.c:50:
> 
>   if (flags & MAP_FIXED) {
>   if (aliasing && flags & MAP_SHARED &&
>   (addr - (pgoff << PAGE_SHIFT)) & (SHMLBA - 1))
>   return -EINVAL;
>   return addr;
>   }
> 
> So, given that this has been the implementation for the last 12+ years (and
> probably the whole time, in fact), I think we can be bold enough to use this
> wording for the second sentence of MAP_FIXED:
> 
> "addr must be a multiple of SHMLBA (), which in turn is either
> the system page size (on many architectures) or a multiple of the system
> page size (on some architectures)."
> 
> What do you think?

I am not sure this is a good idea. This is pulling way too many
implementation details into the man page IMHO. Note that your wording is
even incorrect because this applies only to shared mappings and on some
architectures it even requires special memory regions. We do not want
all that in the man page...

-- 
Michal Hocko
SUSE Labs

Re: [PATCH 4.14 00/95] 4.14.4-stable review

[Naresh Kamboju]

On 4 December 2017 at 21:29, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.14.4 release.
> There are 95 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Dec  6 16:00:27 UTC 2017.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.14.4-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 95aa1a118d82e935ec7065345cbaff945d4100bf
git describe: v4.14.3-96-g95aa1a118d82
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.3-96-g95aa1a118d82


No regressions (compared to build v4.14.3-96-gc2bf04f2ec62)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 39, skip: 14
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 982, skip: 121
* ltp-timers-tests - pass: 12,

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 38, skip: 14
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 939, skip: 156
* ltp-timers-tests - pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - pass: 35, skip: 18
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1036, skip: 66
* ltp-timers-tests - pass: 12,

x86_64
* boot - pass: 20,
* kselftest - pass: 54, skip: 13
* libhugetlbfs - pass: 76, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 1,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 957, skip: 163
* ltp-timers-tests - pass: 12,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Tested-by: Naresh Kamboju 

Re: [PATCH 4.14 00/95] 4.14.4-stable review

[Naresh Kamboju]

On 4 December 2017 at 21:29, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.14.4 release.
> There are 95 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Dec  6 16:00:27 UTC 2017.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.14.4-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 95aa1a118d82e935ec7065345cbaff945d4100bf
git describe: v4.14.3-96-g95aa1a118d82
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.3-96-g95aa1a118d82


No regressions (compared to build v4.14.3-96-gc2bf04f2ec62)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 39, skip: 14
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 14,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 982, skip: 121
* ltp-timers-tests - pass: 12,

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 38, skip: 14
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 939, skip: 156
* ltp-timers-tests - pass: 12,

x15 - arm
* boot - pass: 20,
* kselftest - pass: 35, skip: 18
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 60,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1036, skip: 66
* ltp-timers-tests - pass: 12,

x86_64
* boot - pass: 20,
* kselftest - pass: 54, skip: 13
* libhugetlbfs - pass: 76, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 1
* ltp-fs_bind-tests - pass: 1,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 957, skip: 163
* ltp-timers-tests - pass: 12,

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Tested-by: Naresh Kamboju 

[PATCH] arm64: avoid send SIGBUS two times

[Dongjiu Geng]

If APEI handling the memory error is failed,
the SIGBUS will be sent twice. In fact, send
one time can be enough, so correct it.

Signed-off-by: Dongjiu Geng 
---
 arch/arm64/mm/fault.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index fcf2ede3..9e3f7ca 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -570,7 +570,6 @@ static int do_sea(unsigned long addr, unsigned int esr, 
struct pt_regs *regs)
 {
struct siginfo info;
const struct fault_info *inf;
-   int ret = 0;
 
inf = esr_to_fault_info(esr);
pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
@@ -585,7 +584,7 @@ static int do_sea(unsigned long addr, unsigned int esr, 
struct pt_regs *regs)
if (interrupts_enabled(regs))
nmi_enter();
 
-   ret = ghes_notify_sea();
+   ghes_notify_sea();
 
if (interrupts_enabled(regs))
nmi_exit();
@@ -600,7 +599,7 @@ static int do_sea(unsigned long addr, unsigned int esr, 
struct pt_regs *regs)
info.si_addr  = (void __user *)addr;
arm64_notify_die("", regs, , esr);
 
-   return ret;
+   return 0;
 }
 
 static const struct fault_info fault_info[] = {
-- 
2.10.1

[PATCH] arm64: avoid send SIGBUS two times

[Dongjiu Geng]

If APEI handling the memory error is failed,
the SIGBUS will be sent twice. In fact, send
one time can be enough, so correct it.

Signed-off-by: Dongjiu Geng 
---
 arch/arm64/mm/fault.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index fcf2ede3..9e3f7ca 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -570,7 +570,6 @@ static int do_sea(unsigned long addr, unsigned int esr, 
struct pt_regs *regs)
 {
struct siginfo info;
const struct fault_info *inf;
-   int ret = 0;
 
inf = esr_to_fault_info(esr);
pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
@@ -585,7 +584,7 @@ static int do_sea(unsigned long addr, unsigned int esr, 
struct pt_regs *regs)
if (interrupts_enabled(regs))
nmi_enter();
 
-   ret = ghes_notify_sea();
+   ghes_notify_sea();
 
if (interrupts_enabled(regs))
nmi_exit();
@@ -600,7 +599,7 @@ static int do_sea(unsigned long addr, unsigned int esr, 
struct pt_regs *regs)
info.si_addr  = (void __user *)addr;
arm64_notify_die("", regs, , esr);
 
-   return ret;
+   return 0;
 }
 
 static const struct fault_info fault_info[] = {
-- 
2.10.1

Re: [PATCH] thermal/drivers/hisi: disable multi alarm support for hi3660 SoC

[Daniel Lezcano]

On 05/12/2017 03:02, Eduardo Valentin wrote:
> Hello,
> 
> On Thu, Oct 19, 2017 at 09:31:24AM +0800, Wangtao (Kevin, Kirin) wrote:
>>
>>
>> 在 2017/10/18 23:54, Daniel Lezcano 写道:
>>> On 18/10/2017 11:15, Tao Wang wrote:
 From: Kevin Wangtao 

 multi alarm interrupt forced a re-trigger of power_allocator_throttle
 which changes the PID's actual sampling rate, this isn't optimal for
 IPA, it is best to disable multi alarm support now and sort out this
 issue later.

 Signed-off-by: Kevin Wangtao 
>>>
>>> Did you test the series with this change?
>> Yes
> 
> Is this patch still valid with the latest linus master?

No, it was folded in the next iteration.

All patches for hisilicon are up-to-date.

Thanks.

 -- Daniel


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH] thermal/drivers/hisi: disable multi alarm support for hi3660 SoC

[Daniel Lezcano]

On 05/12/2017 03:02, Eduardo Valentin wrote:
> Hello,
> 
> On Thu, Oct 19, 2017 at 09:31:24AM +0800, Wangtao (Kevin, Kirin) wrote:
>>
>>
>> 在 2017/10/18 23:54, Daniel Lezcano 写道:
>>> On 18/10/2017 11:15, Tao Wang wrote:
 From: Kevin Wangtao 

 multi alarm interrupt forced a re-trigger of power_allocator_throttle
 which changes the PID's actual sampling rate, this isn't optimal for
 IPA, it is best to disable multi alarm support now and sort out this
 issue later.

 Signed-off-by: Kevin Wangtao 
>>>
>>> Did you test the series with this change?
>> Yes
> 
> Is this patch still valid with the latest linus master?

No, it was folded in the next iteration.

All patches for hisilicon are up-to-date.

Thanks.

 -- Daniel


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH] SCSI: delay run queue if device is blocked in scsi_dev_queue_ready()

[Ming Lei]

On Tue, Dec 05, 2017 at 01:16:24PM +0800, Ming Lei wrote:
> On Mon, Dec 04, 2017 at 11:48:07PM +, Holger Hoffstätte wrote:
> > On Tue, 05 Dec 2017 06:45:08 +0800, Ming Lei wrote:
> > 
> > > On Mon, Dec 04, 2017 at 03:09:20PM +, Bart Van Assche wrote:
> > >> On Sun, 2017-12-03 at 00:31 +0800, Ming Lei wrote:
> > >> > Fixes: 0df21c86bdbf ("scsi: implement .get_budget and .put_budget for 
> > >> > blk-mq")
> > >> 
> > >> It might be safer to revert commit 0df21c86bdbf instead of trying to fix 
> > >> all
> > >> issues introduced by that commit for kernel version v4.15 ...
> > > 
> > > What are all issues in v4.15-rc? Up to now, it is the only issue reported,
> > > and can be fixed by this simple patch, which one can be thought as cleanup
> > > too.
> > 
> > Even with this patch I've encountered at least one hang that
> > seemed related. I'm using most of block/scsi-4.15 on top of 4.14 and
> > the hang in question was on a rotating disk. It could be solved by 
> > activating
> > a different scheduler on the hanging device; all hanging sync/df processes 
> > got
> > unstuck and all was fine again, which leads me to believe that there is at 
> > least
> > one more rare condition where delaying requests (as done in the budget 
> > patch)
> > leads to a hang.
> > 
> > This happened with mq-deadline which I was testing specifically to avoid
> > any BFQ-related side effects.
> 
> OK, this looks a new report.
> 
> Without any log, we can't make any progress, and even we can't guess
> what the issue is related with.
> 
> Could you post your dmesg log(include the hang process stack trace)? And
> dump the debugfs log by the following script when this hang happens?
> 
>   http://people.redhat.com/minlei/tests/tools/dump-blk-info
> 
> BTW, you just need to pass the disk name to the script, such as: /dev/sda.

Thinking of the issue further, this patch only covers case of
scsi_set_blocked(), but don't consider the case in which .get_budget()
is called inside blk_mq_dispatch_rq_list() for request coming from
hctx->dispatch_list.

If .get_budget() is called in both blk_mq_do_dispatch_sched() and
blk_mq_do_dispatch_ctx(), we don't need to run queue if the queue
is idle. But if it is called from blk_mq_dispatch_rq_list() for request
coming from hctx->dispatch_list, we have to run queue if queue is
idle, as before.

So please ignore this patch, and will submit V2 for cover both cases.

Thanks,
Ming

Re: [PATCH] SCSI: delay run queue if device is blocked in scsi_dev_queue_ready()

[Ming Lei]

On Tue, Dec 05, 2017 at 01:16:24PM +0800, Ming Lei wrote:
> On Mon, Dec 04, 2017 at 11:48:07PM +, Holger Hoffstätte wrote:
> > On Tue, 05 Dec 2017 06:45:08 +0800, Ming Lei wrote:
> > 
> > > On Mon, Dec 04, 2017 at 03:09:20PM +, Bart Van Assche wrote:
> > >> On Sun, 2017-12-03 at 00:31 +0800, Ming Lei wrote:
> > >> > Fixes: 0df21c86bdbf ("scsi: implement .get_budget and .put_budget for 
> > >> > blk-mq")
> > >> 
> > >> It might be safer to revert commit 0df21c86bdbf instead of trying to fix 
> > >> all
> > >> issues introduced by that commit for kernel version v4.15 ...
> > > 
> > > What are all issues in v4.15-rc? Up to now, it is the only issue reported,
> > > and can be fixed by this simple patch, which one can be thought as cleanup
> > > too.
> > 
> > Even with this patch I've encountered at least one hang that
> > seemed related. I'm using most of block/scsi-4.15 on top of 4.14 and
> > the hang in question was on a rotating disk. It could be solved by 
> > activating
> > a different scheduler on the hanging device; all hanging sync/df processes 
> > got
> > unstuck and all was fine again, which leads me to believe that there is at 
> > least
> > one more rare condition where delaying requests (as done in the budget 
> > patch)
> > leads to a hang.
> > 
> > This happened with mq-deadline which I was testing specifically to avoid
> > any BFQ-related side effects.
> 
> OK, this looks a new report.
> 
> Without any log, we can't make any progress, and even we can't guess
> what the issue is related with.
> 
> Could you post your dmesg log(include the hang process stack trace)? And
> dump the debugfs log by the following script when this hang happens?
> 
>   http://people.redhat.com/minlei/tests/tools/dump-blk-info
> 
> BTW, you just need to pass the disk name to the script, such as: /dev/sda.

Thinking of the issue further, this patch only covers case of
scsi_set_blocked(), but don't consider the case in which .get_budget()
is called inside blk_mq_dispatch_rq_list() for request coming from
hctx->dispatch_list.

If .get_budget() is called in both blk_mq_do_dispatch_sched() and
blk_mq_do_dispatch_ctx(), we don't need to run queue if the queue
is idle. But if it is called from blk_mq_dispatch_rq_list() for request
coming from hctx->dispatch_list, we have to run queue if queue is
idle, as before.

So please ignore this patch, and will submit V2 for cover both cases.

Thanks,
Ming

Re: [patch V4 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses

[Heiko Carstens]

On Mon, Dec 04, 2017 at 10:19:28PM +0100, Thomas Gleixner wrote:
> +3. Syntax:
> +
> +   A  is either an SPDX short form license
> +   identifier found on the SPDX License List, or when multiple licenses
> +   apply, an expression consisting of keywords "AND", "OR", and "WITH"
> +   separating SPDX short form license identifiers surrounded by "(", ")".

Here it is stated that SPDX identifiers using the keyword WITH must be
surrounded by braces.

> +  // SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note)
> +  // SPDX-License-Identifier: (GPL-2.0+ WITH Linux-syscall-note)

Just like this example.

> +   File format examples::
> +
> +  SPDX-Exception-Identifier: Linux-syscall-note
> +  SPDX-URL: https://spdx.org/licenses/Linux-syscall-note.html
> +  SPDX-Licenses: GPL-2.0, GPL-2.0+, GPL-1.0+, LGPL-2.0, LGPL-2.0+, 
> LGPL-2.1, LGPL-2.1+
> +  Usage-Guidance:
> +This exception is used together with one of the above SPDX-Licenses
> + to mark user-space API (uapi) header files so they can be included
> + into non GPL compliant user-space application code.
> +To use this exception add it with the keyword WITH to one of the
> + identifiers in the SPDX-Licenses tag:
> +   SPDX-License-Identifier:  WITH Linux-syscall-note

But here it comes without braces.

> +  Exception-Text:
> +Full exception text
> +
> +   ::
> +
> +  SPDX-Exception-Identifier: GCC-exception-2.0
> +  SPDX-URL: https://spdx.org/licenses/GCC-exception-2.0.html
> +  SPDX-Licenses: GPL-2.0, GPL-2.0+
> +  Usage-Guidance:
> +The "GCC Runtime Library exception 2.0" is used together with one
> + of the above SPDX-Licenses for code imported from the GCC runtime
> + library.
> +To use this exception add it with the keyword WITH to one of the
> + identifiers in the SPDX-Licenses tag:
> +   SPDX-License-Identifier:  WITH GCC-exception-2.0

Here as well.

The whole kernel now got SPDX-License-Identifiers that look like this:

SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note

So this looks inconsistent to me, or did I miss something?

Re: [patch V4 01/11] Documentation: Add license-rules.rst to describe how to properly identify file licenses

[Heiko Carstens]

On Mon, Dec 04, 2017 at 10:19:28PM +0100, Thomas Gleixner wrote:
> +3. Syntax:
> +
> +   A  is either an SPDX short form license
> +   identifier found on the SPDX License List, or when multiple licenses
> +   apply, an expression consisting of keywords "AND", "OR", and "WITH"
> +   separating SPDX short form license identifiers surrounded by "(", ")".

Here it is stated that SPDX identifiers using the keyword WITH must be
surrounded by braces.

> +  // SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note)
> +  // SPDX-License-Identifier: (GPL-2.0+ WITH Linux-syscall-note)

Just like this example.

> +   File format examples::
> +
> +  SPDX-Exception-Identifier: Linux-syscall-note
> +  SPDX-URL: https://spdx.org/licenses/Linux-syscall-note.html
> +  SPDX-Licenses: GPL-2.0, GPL-2.0+, GPL-1.0+, LGPL-2.0, LGPL-2.0+, 
> LGPL-2.1, LGPL-2.1+
> +  Usage-Guidance:
> +This exception is used together with one of the above SPDX-Licenses
> + to mark user-space API (uapi) header files so they can be included
> + into non GPL compliant user-space application code.
> +To use this exception add it with the keyword WITH to one of the
> + identifiers in the SPDX-Licenses tag:
> +   SPDX-License-Identifier:  WITH Linux-syscall-note

But here it comes without braces.

> +  Exception-Text:
> +Full exception text
> +
> +   ::
> +
> +  SPDX-Exception-Identifier: GCC-exception-2.0
> +  SPDX-URL: https://spdx.org/licenses/GCC-exception-2.0.html
> +  SPDX-Licenses: GPL-2.0, GPL-2.0+
> +  Usage-Guidance:
> +The "GCC Runtime Library exception 2.0" is used together with one
> + of the above SPDX-Licenses for code imported from the GCC runtime
> + library.
> +To use this exception add it with the keyword WITH to one of the
> + identifiers in the SPDX-Licenses tag:
> +   SPDX-License-Identifier:  WITH GCC-exception-2.0

Here as well.

The whole kernel now got SPDX-License-Identifiers that look like this:

SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note

So this looks inconsistent to me, or did I miss something?

Re: [PATCH V2] thermal/drivers/hisi: Switch to interrupt mode

[Daniel Lezcano]

On 05/12/2017 03:00, Eduardo Valentin wrote:
> Hello,
> 
> On Thu, Sep 28, 2017 at 09:32:20AM +0200, Daniel Lezcano wrote:
>> On Thu, Sep 28, 2017 at 02:57:52PM +0800, Leo Yan wrote:
>>> Hi Daniel,
>>>
>>> On Thu, Sep 28, 2017 at 07:13:44AM +0200, Daniel Lezcano wrote:
 At this moment, we have both the interrupt setup and the polling enabled. 
 The
 interrupt does nothing more than forcing an update while the temperature is
 polled every second.

 We can do much better than that, threshold is set to 65C in the DT and the
 passive cooling device enters in the dance when 75C is reached. We need to
 sample the temperature at 65C in order to let the IPA gather enough values 
 for
 the PID computation. If the SoC is running at a temperature below 65C, we 
 will
 be constantly polling for nothing.

 This patch disables the sensor when the temperature is below 65C and 
 enables it
 when passing the threshold. It results the thermal sensor driver will have 
 no
 activity most of the time.

 Cc: Keerthy 
 Cc: Leo Yang 
>>>
>>> s/Yang/Yan :) Have tested this patch on Hikey at my side:
>>
>> Oops sorry :)
>>
>>> Reviewed-by: Leo Yan 
>>> Tested-by: Leo Yan 
>>
> 
> Is this still needed after the latest rework done?

No longer needed.



-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH V2] thermal/drivers/hisi: Switch to interrupt mode

[Daniel Lezcano]

On 05/12/2017 03:00, Eduardo Valentin wrote:
> Hello,
> 
> On Thu, Sep 28, 2017 at 09:32:20AM +0200, Daniel Lezcano wrote:
>> On Thu, Sep 28, 2017 at 02:57:52PM +0800, Leo Yan wrote:
>>> Hi Daniel,
>>>
>>> On Thu, Sep 28, 2017 at 07:13:44AM +0200, Daniel Lezcano wrote:
 At this moment, we have both the interrupt setup and the polling enabled. 
 The
 interrupt does nothing more than forcing an update while the temperature is
 polled every second.

 We can do much better than that, threshold is set to 65C in the DT and the
 passive cooling device enters in the dance when 75C is reached. We need to
 sample the temperature at 65C in order to let the IPA gather enough values 
 for
 the PID computation. If the SoC is running at a temperature below 65C, we 
 will
 be constantly polling for nothing.

 This patch disables the sensor when the temperature is below 65C and 
 enables it
 when passing the threshold. It results the thermal sensor driver will have 
 no
 activity most of the time.

 Cc: Keerthy 
 Cc: Leo Yang 
>>>
>>> s/Yang/Yan :) Have tested this patch on Hikey at my side:
>>
>> Oops sorry :)
>>
>>> Reviewed-by: Leo Yan 
>>> Tested-by: Leo Yan 
>>
> 
> Is this still needed after the latest rework done?

No longer needed.



-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

[PATCH 1/2] ARM: dts: keystone-k2g: Add UART 1 and 2 instances

[Vignesh R]

From: Franklin S Cooper Jr 

Add DT nodes for two other UART instances of 66AK2G SoC.

Also add power domain and clock domain nodes to UART 0

Signed-off-by: Franklin S Cooper Jr 
Signed-off-by: Vignesh R 
---
 arch/arm/boot/dts/keystone-k2g.dtsi | 29 -
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi 
b/arch/arm/boot/dts/keystone-k2g.dtsi
index ef82c0a6e607..3c48a9f5c882 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -28,6 +28,8 @@
 
aliases {
serial0 = 
+   serial1 = 
+   serial2 = 
i2c0 = 
i2c1 = 
i2c2 = 
@@ -114,7 +116,32 @@
reg-io-width = <4>;
reg = <0x02530c00 0x100>;
interrupts = ;
-   clock-frequency = <2>;
+   clocks = <_clks 0x2c 0>;
+   power-domains = <_pds 0x2c>;
+   status = "disabled";
+   };
+
+   uart1: serial@02531000 {
+   compatible = "ti,da830-uart", "ns16550a";
+   current-speed = <115200>;
+   reg-shift = <2>;
+   reg-io-width = <4>;
+   reg = <0x02531000 0x100>;
+   interrupts = ;
+   clocks = <_clks 0x2d 0>;
+   power-domains = <_pds 0x2d>;
+   status = "disabled";
+   };
+
+   uart2: serial@02531400 {
+   compatible = "ti,da830-uart", "ns16550a";
+   current-speed = <115200>;
+   reg-shift = <2>;
+   reg-io-width = <4>;
+   reg = <0x02531400 0x100>;
+   interrupts = ;
+   clocks = <_clks 0x2e 0>;
+   power-domains = <_pds 0x2e>;
status = "disabled";
};
 
-- 
2.15.0

[PATCH 1/2] ARM: dts: keystone-k2g: Add UART 1 and 2 instances

[Vignesh R]

From: Franklin S Cooper Jr 

Add DT nodes for two other UART instances of 66AK2G SoC.

Also add power domain and clock domain nodes to UART 0

Signed-off-by: Franklin S Cooper Jr 
Signed-off-by: Vignesh R 
---
 arch/arm/boot/dts/keystone-k2g.dtsi | 29 -
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi 
b/arch/arm/boot/dts/keystone-k2g.dtsi
index ef82c0a6e607..3c48a9f5c882 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -28,6 +28,8 @@
 
aliases {
serial0 = 
+   serial1 = 
+   serial2 = 
i2c0 = 
i2c1 = 
i2c2 = 
@@ -114,7 +116,32 @@
reg-io-width = <4>;
reg = <0x02530c00 0x100>;
interrupts = ;
-   clock-frequency = <2>;
+   clocks = <_clks 0x2c 0>;
+   power-domains = <_pds 0x2c>;
+   status = "disabled";
+   };
+
+   uart1: serial@02531000 {
+   compatible = "ti,da830-uart", "ns16550a";
+   current-speed = <115200>;
+   reg-shift = <2>;
+   reg-io-width = <4>;
+   reg = <0x02531000 0x100>;
+   interrupts = ;
+   clocks = <_clks 0x2d 0>;
+   power-domains = <_pds 0x2d>;
+   status = "disabled";
+   };
+
+   uart2: serial@02531400 {
+   compatible = "ti,da830-uart", "ns16550a";
+   current-speed = <115200>;
+   reg-shift = <2>;
+   reg-io-width = <4>;
+   reg = <0x02531400 0x100>;
+   interrupts = ;
+   clocks = <_clks 0x2e 0>;
+   power-domains = <_pds 0x2e>;
status = "disabled";
};
 
-- 
2.15.0

Re: [PATCH] thermal/drivers/hisi: Remove confusing error message

[Daniel Lezcano]

On 05/12/2017 02:52, Eduardo Valentin wrote:
> Hello,
> 
> Catching up on old patches.
> On Fri, Jul 07, 2017 at 05:03:52PM +0200, Daniel Lezcano wrote:
>> The sensor id is unknown at init time and we use all id in the authorized
>> MAX_SENSORS interval to register the sensor. On this SoC there is one
>> thermal-zone with one sensor on it. No need to spit on the console everytime 
>> we
>> failed to register thermal sensors, information which is deliberaly known as 
>> it
>> is part of the discovery process.
>>
>>  hisi_thermal f7030700.tsensor: failed to register sensor id 0: -19
>>  hisi_thermal f7030700.tsensor: failed to register thermal sensor: -19
>>  hisi_thermal f7030700.tsensor: failed to register sensor id 1: -19
>>  hisi_thermal f7030700.tsensor: failed to register thermal sensor: -19
>>  hisi_thermal f7030700.tsensor: failed to register sensor id 3: -19
>>  hisi_thermal f7030700.tsensor: failed to register thermal sensor: -19
>>
>> Remove the error messages
> 
> Is this still needed? I am assuming no.

Right, no longer needed.

  -- Daniel

-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

[PATCH 0/2] 66AK2G: Add DT entry for UART1 and UART2

[Vignesh R]

This series adds DT entry for the remaining two UART instances on 66AK2G
SoC.

Based on linux-next.

Franklin S Cooper Jr (2):
  ARM: dts: keystone-k2g: Add UART 1 and 2 instances
  ARM: dts: keystone-k2g-evm: Enable UART 2

 arch/arm/boot/dts/keystone-k2g-evm.dts | 13 +
 arch/arm/boot/dts/keystone-k2g.dtsi| 29 -
 2 files changed, 41 insertions(+), 1 deletion(-)

-- 
2.15.0

[PATCH 2/2] ARM: dts: keystone-k2g-evm: Enable UART 2

[Vignesh R]

From: Franklin S Cooper Jr 

66AK2G GP EVM has a Baseboard Management Controller (BMC) on board.
This controller handles things like setting the SoCs boot mode along
with controlling the on board character LCD display module.

Enable UART2 which communicates with the BMC. This enables userspace
applications to display something on the onboard LCD controlled by the
BMC.

Signed-off-by: Franklin S Cooper Jr 
Signed-off-by: Vignesh R 
---
 arch/arm/boot/dts/keystone-k2g-evm.dts | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/keystone-k2g-evm.dts 
b/arch/arm/boot/dts/keystone-k2g-evm.dts
index 8d100217e38f..9737730ddc21 100644
--- a/arch/arm/boot/dts/keystone-k2g-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2g-evm.dts
@@ -115,6 +115,13 @@
K2G_CORE_IOPAD(0x121c) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_csn0.qspi_csn0 */
>;
};
+
+   uart2_pins: pinmux_uart2_pins {
+   pinctrl-single,pins = <
+   K2G_CORE_IOPAD(0x11ec) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0)  /* uart2_rxd.uart2_rxd */
+   K2G_CORE_IOPAD(0x11f0) (BUFFER_CLASS_B | PIN_PULLDOWN | 
MUX_MODE0)  /* uart2_txd.uart2_txd */
+   >;
+   };
 };
 
  {
@@ -263,3 +270,9 @@
};
};
 };
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+};
-- 
2.15.0

Re: [PATCH] thermal/drivers/hisi: Remove confusing error message

[Daniel Lezcano]

On 05/12/2017 02:52, Eduardo Valentin wrote:
> Hello,
> 
> Catching up on old patches.
> On Fri, Jul 07, 2017 at 05:03:52PM +0200, Daniel Lezcano wrote:
>> The sensor id is unknown at init time and we use all id in the authorized
>> MAX_SENSORS interval to register the sensor. On this SoC there is one
>> thermal-zone with one sensor on it. No need to spit on the console everytime 
>> we
>> failed to register thermal sensors, information which is deliberaly known as 
>> it
>> is part of the discovery process.
>>
>>  hisi_thermal f7030700.tsensor: failed to register sensor id 0: -19
>>  hisi_thermal f7030700.tsensor: failed to register thermal sensor: -19
>>  hisi_thermal f7030700.tsensor: failed to register sensor id 1: -19
>>  hisi_thermal f7030700.tsensor: failed to register thermal sensor: -19
>>  hisi_thermal f7030700.tsensor: failed to register sensor id 3: -19
>>  hisi_thermal f7030700.tsensor: failed to register thermal sensor: -19
>>
>> Remove the error messages
> 
> Is this still needed? I am assuming no.

Right, no longer needed.

  -- Daniel

-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

[PATCH 0/2] 66AK2G: Add DT entry for UART1 and UART2

[Vignesh R]

This series adds DT entry for the remaining two UART instances on 66AK2G
SoC.

Based on linux-next.

Franklin S Cooper Jr (2):
  ARM: dts: keystone-k2g: Add UART 1 and 2 instances
  ARM: dts: keystone-k2g-evm: Enable UART 2

 arch/arm/boot/dts/keystone-k2g-evm.dts | 13 +
 arch/arm/boot/dts/keystone-k2g.dtsi| 29 -
 2 files changed, 41 insertions(+), 1 deletion(-)

-- 
2.15.0

[PATCH 2/2] ARM: dts: keystone-k2g-evm: Enable UART 2

[Vignesh R]

From: Franklin S Cooper Jr 

66AK2G GP EVM has a Baseboard Management Controller (BMC) on board.
This controller handles things like setting the SoCs boot mode along
with controlling the on board character LCD display module.

Enable UART2 which communicates with the BMC. This enables userspace
applications to display something on the onboard LCD controlled by the
BMC.

Signed-off-by: Franklin S Cooper Jr 
Signed-off-by: Vignesh R 
---
 arch/arm/boot/dts/keystone-k2g-evm.dts | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/keystone-k2g-evm.dts 
b/arch/arm/boot/dts/keystone-k2g-evm.dts
index 8d100217e38f..9737730ddc21 100644
--- a/arch/arm/boot/dts/keystone-k2g-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2g-evm.dts
@@ -115,6 +115,13 @@
K2G_CORE_IOPAD(0x121c) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_csn0.qspi_csn0 */
>;
};
+
+   uart2_pins: pinmux_uart2_pins {
+   pinctrl-single,pins = <
+   K2G_CORE_IOPAD(0x11ec) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0)  /* uart2_rxd.uart2_rxd */
+   K2G_CORE_IOPAD(0x11f0) (BUFFER_CLASS_B | PIN_PULLDOWN | 
MUX_MODE0)  /* uart2_txd.uart2_txd */
+   >;
+   };
 };
 
  {
@@ -263,3 +270,9 @@
};
};
 };
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+};
-- 
2.15.0

Re: [PATCH v4 3/5] remoteproc: Pass type of shutdown to subdev remove

[Bjorn Andersson]

On Fri 01 Dec 06:50 PST 2017, Arnaud Pouliquen wrote:

> hello Bjorn,
> 
> Sorry for these late remarks/questions
> 

No worries, I'm happy to see you reading the patch!

> 
> On 11/30/2017 02:16 AM, Bjorn Andersson wrote:
[..]
> > diff --git a/drivers/remoteproc/qcom_common.c 
> > b/drivers/remoteproc/qcom_common.c
[..]
> > @@ -785,17 +785,17 @@ static int rproc_probe_subdevices(struct rproc *rproc)
> >  
> >  unroll_registration:
> > list_for_each_entry_continue_reverse(subdev, >subdevs, node)
> > -   subdev->remove(subdev);
> > +   subdev->remove(subdev, false);
> Why do you need to do a non graceful remove in this case? This could
> lead to side effect like memory leakage...
> 

Regardless of this being true or false resources should always be
reclaimed.

The reason for introducing this is that the modem in the Qualcomm
platforms implements persistent storage and it's preferred to tell it to
flush the latest data to the storage server (on the Linux side) before
pulling the plug. But in the case of a firmware crash this mechanism
will not be operational and there's no point in attempting this
"graceful shutdown".

[..]
> > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> > index 44e630eb3d94..20a9467744ea 100644
> > --- a/include/linux/remoteproc.h
> > +++ b/include/linux/remoteproc.h
> > @@ -456,7 +456,7 @@ struct rproc_subdev {
> > struct list_head node;
> >  
> > int (*probe)(struct rproc_subdev *subdev);
> > -   void (*remove)(struct rproc_subdev *subdev);
> > +   void (*remove)(struct rproc_subdev *subdev, bool graceful);
> What about adding a new ops instead of a parameter, like a recovery
> callback?
> 

I think that for symmetry purposes it should be probe/remove in both
code paths. A possible alternative to the proposal would be to introduce
an operation "request_shutdown()" the would be called in the proposed
graceful code path.


However, in the Qualcomm SMD and GLINK (conceptually equivalent to
virtio-rpmsg) it is possible to open and close communication channels
and it's conceivable to see that the graceful case would close all
channels cleanly while the non-graceful case would just remove the rpmsg
devices (and leave the channel states/memory as is).

In this case a "request_shutdown()" would complicate things, compared to
the boolean.

Regards,
Bjorn

Re: [PATCH v4 3/5] remoteproc: Pass type of shutdown to subdev remove

[Bjorn Andersson]

On Fri 01 Dec 06:50 PST 2017, Arnaud Pouliquen wrote:

> hello Bjorn,
> 
> Sorry for these late remarks/questions
> 

No worries, I'm happy to see you reading the patch!

> 
> On 11/30/2017 02:16 AM, Bjorn Andersson wrote:
[..]
> > diff --git a/drivers/remoteproc/qcom_common.c 
> > b/drivers/remoteproc/qcom_common.c
[..]
> > @@ -785,17 +785,17 @@ static int rproc_probe_subdevices(struct rproc *rproc)
> >  
> >  unroll_registration:
> > list_for_each_entry_continue_reverse(subdev, >subdevs, node)
> > -   subdev->remove(subdev);
> > +   subdev->remove(subdev, false);
> Why do you need to do a non graceful remove in this case? This could
> lead to side effect like memory leakage...
> 

Regardless of this being true or false resources should always be
reclaimed.

The reason for introducing this is that the modem in the Qualcomm
platforms implements persistent storage and it's preferred to tell it to
flush the latest data to the storage server (on the Linux side) before
pulling the plug. But in the case of a firmware crash this mechanism
will not be operational and there's no point in attempting this
"graceful shutdown".

[..]
> > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> > index 44e630eb3d94..20a9467744ea 100644
> > --- a/include/linux/remoteproc.h
> > +++ b/include/linux/remoteproc.h
> > @@ -456,7 +456,7 @@ struct rproc_subdev {
> > struct list_head node;
> >  
> > int (*probe)(struct rproc_subdev *subdev);
> > -   void (*remove)(struct rproc_subdev *subdev);
> > +   void (*remove)(struct rproc_subdev *subdev, bool graceful);
> What about adding a new ops instead of a parameter, like a recovery
> callback?
> 

I think that for symmetry purposes it should be probe/remove in both
code paths. A possible alternative to the proposal would be to introduce
an operation "request_shutdown()" the would be called in the proposed
graceful code path.


However, in the Qualcomm SMD and GLINK (conceptually equivalent to
virtio-rpmsg) it is possible to open and close communication channels
and it's conceivable to see that the graceful case would close all
channels cleanly while the non-graceful case would just remove the rpmsg
devices (and leave the channel states/memory as is).

In this case a "request_shutdown()" would complicate things, compared to
the boolean.

Regards,
Bjorn

[PATCH v2 2/2] regulator: sc2731: Add regulator driver to support Spreadtrum SC2731 PMIC

[Erick Chen]

Add regulator driver for Spreadtrum SC2731 device.
It has 17 general purpose LDOs, BUCKs generator and
digital output to control regulators.

Signed-off-by: Erick Chen 
Reviewed-by: Baolin Wang 
---
Changes since v1:
- Remove of_device_id table.
- Change subsys_init() to module_init().
- Change the file's license format.
---
 drivers/regulator/Kconfig|7 +
 drivers/regulator/Makefile   |1 +
 drivers/regulator/sc2731-regulator.c |  256 ++
 3 files changed, 264 insertions(+)
 create mode 100644 drivers/regulator/sc2731-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 96cd55f..b27417c 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -744,6 +744,13 @@ config REGULATOR_S5M8767
 via I2C bus. S5M8767A have 9 Bucks and 28 LDOs output and
 supports DVS mode with 8bits of output voltage control.
 
+config REGULATOR_SC2731
+   tristate "Spreadtrum SC2731 power regulator driver"
+   depends on MFD_SC27XX_PMIC || COMPILE_TEST
+   help
+ This driver provides support for the voltage regulators on the
+ SC2731 PMIC.
+
 config REGULATOR_SKY81452
tristate "Skyworks Solutions SKY81452 voltage regulator"
depends on MFD_SKY81452
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 80ffc57..19fea09 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -95,6 +95,7 @@ obj-$(CONFIG_REGULATOR_RT5033)+= rt5033-regulator.o
 obj-$(CONFIG_REGULATOR_S2MPA01) += s2mpa01.o
 obj-$(CONFIG_REGULATOR_S2MPS11) += s2mps11.o
 obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
+obj-$(CONFIG_REGULATOR_SC2731) += sc2731-regulator.o
 obj-$(CONFIG_REGULATOR_SKY81452) += sky81452-regulator.o
 obj-$(CONFIG_REGULATOR_STM32_VREFBUF) += stm32-vrefbuf.o
 obj-$(CONFIG_REGULATOR_STW481X_VMMC) += stw481x-vmmc.o
diff --git a/drivers/regulator/sc2731-regulator.c 
b/drivers/regulator/sc2731-regulator.c
new file mode 100644
index 000..794fcd5
--- /dev/null
+++ b/drivers/regulator/sc2731-regulator.c
@@ -0,0 +1,256 @@
+ //SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017 Spreadtrum Communications Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * SC2731 regulator lock register
+ */
+#define SC2731_PWR_WR_PROT_VALUE   0xf0c
+#define SC2731_WR_UNLOCK   0x6e7f
+
+/*
+ * SC2731 enable register
+ */
+#define SC2731_POWER_PD_SW 0xc28
+#define SC2731_LDO_CAMA0_PD0xcfc
+#define SC2731_LDO_CAMA1_PD0xd04
+#define SC2731_LDO_CAMMOT_PD   0xd0c
+#define SC2731_LDO_VLDO_PD 0xd6c
+#define SC2731_LDO_EMMCCORE_PD 0xd2c
+#define SC2731_LDO_SDCORE_PD   0xd74
+#define SC2731_LDO_SDIO_PD 0xd70
+#define SC2731_LDO_WIFIPA_PD   0xd4c
+#define SC2731_LDO_USB33_PD0xd5c
+#define SC2731_LDO_CAMD0_PD0xd7c
+#define SC2731_LDO_CAMD1_PD0xd84
+#define SC2731_LDO_CON_PD  0xd8c
+#define SC2731_LDO_CAMIO_PD0xd94
+#define SC2731_LDO_SRAM_PD 0xd78
+
+/*
+ * SC2731 enable mask
+ */
+#define SC2731_DCDC_CPU0_PD_MASK   BIT(4)
+#define SC2731_DCDC_CPU1_PD_MASK   BIT(3)
+#define SC2731_DCDC_RF_PD_MASK BIT(11)
+#define SC2731_LDO_CAMA0_PD_MASK   BIT(0)
+#define SC2731_LDO_CAMA1_PD_MASK   BIT(0)
+#define SC2731_LDO_CAMMOT_PD_MASK  BIT(0)
+#define SC2731_LDO_VLDO_PD_MASKBIT(0)
+#define SC2731_LDO_EMMCCORE_PD_MASKBIT(0)
+#define SC2731_LDO_SDCORE_PD_MASK  BIT(0)
+#define SC2731_LDO_SDIO_PD_MASKBIT(0)
+#define SC2731_LDO_WIFIPA_PD_MASK  BIT(0)
+#define SC2731_LDO_USB33_PD_MASK   BIT(0)
+#define SC2731_LDO_CAMD0_PD_MASK   BIT(0)
+#define SC2731_LDO_CAMD1_PD_MASK   BIT(0)
+#define SC2731_LDO_CON_PD_MASK BIT(0)
+#define SC2731_LDO_CAMIO_PD_MASK   BIT(0)
+#define SC2731_LDO_SRAM_PD_MASKBIT(0)
+
+/*
+ * SC2731 vsel register
+ */
+#define SC2731_DCDC_CPU0_VOL   0xc54
+#define SC2731_DCDC_CPU1_VOL   0xc64
+#define SC2731_DCDC_RF_VOL 0xcb8
+#define SC2731_LDO_CAMA0_VOL   0xd00
+#define SC2731_LDO_CAMA1_VOL   0xd08
+#define SC2731_LDO_CAMMOT_VOL  0xd10
+#define SC2731_LDO_VLDO_VOL0xd28
+#define SC2731_LDO_EMMCCORE_VOL0xd30
+#define SC2731_LDO_SDCORE_VOL  0xd38
+#define SC2731_LDO_SDIO_VOL0xd40
+#define SC2731_LDO_WIFIPA_VOL  0xd50
+#define SC2731_LDO_USB33_VOL   0xd60
+#define SC2731_LDO_CAMD0_VOL   0xd80
+#define SC2731_LDO_CAMD1_VOL   0xd88
+#define SC2731_LDO_CON_VOL 0xd90
+#define SC2731_LDO_CAMIO_VOL   0xd98
+#define SC2731_LDO_SRAM_VOL0xdB0
+
+/*
+ * SC2731 vsel register mask
+ */
+#define SC2731_DCDC_CPU0_VOL_MASK  GENMASK(8, 0)

[PATCH v2 2/2] regulator: sc2731: Add regulator driver to support Spreadtrum SC2731 PMIC

[Erick Chen]

Add regulator driver for Spreadtrum SC2731 device.
It has 17 general purpose LDOs, BUCKs generator and
digital output to control regulators.

Signed-off-by: Erick Chen 
Reviewed-by: Baolin Wang 
---
Changes since v1:
- Remove of_device_id table.
- Change subsys_init() to module_init().
- Change the file's license format.
---
 drivers/regulator/Kconfig|7 +
 drivers/regulator/Makefile   |1 +
 drivers/regulator/sc2731-regulator.c |  256 ++
 3 files changed, 264 insertions(+)
 create mode 100644 drivers/regulator/sc2731-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 96cd55f..b27417c 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -744,6 +744,13 @@ config REGULATOR_S5M8767
 via I2C bus. S5M8767A have 9 Bucks and 28 LDOs output and
 supports DVS mode with 8bits of output voltage control.
 
+config REGULATOR_SC2731
+   tristate "Spreadtrum SC2731 power regulator driver"
+   depends on MFD_SC27XX_PMIC || COMPILE_TEST
+   help
+ This driver provides support for the voltage regulators on the
+ SC2731 PMIC.
+
 config REGULATOR_SKY81452
tristate "Skyworks Solutions SKY81452 voltage regulator"
depends on MFD_SKY81452
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 80ffc57..19fea09 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -95,6 +95,7 @@ obj-$(CONFIG_REGULATOR_RT5033)+= rt5033-regulator.o
 obj-$(CONFIG_REGULATOR_S2MPA01) += s2mpa01.o
 obj-$(CONFIG_REGULATOR_S2MPS11) += s2mps11.o
 obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
+obj-$(CONFIG_REGULATOR_SC2731) += sc2731-regulator.o
 obj-$(CONFIG_REGULATOR_SKY81452) += sky81452-regulator.o
 obj-$(CONFIG_REGULATOR_STM32_VREFBUF) += stm32-vrefbuf.o
 obj-$(CONFIG_REGULATOR_STW481X_VMMC) += stw481x-vmmc.o
diff --git a/drivers/regulator/sc2731-regulator.c 
b/drivers/regulator/sc2731-regulator.c
new file mode 100644
index 000..794fcd5
--- /dev/null
+++ b/drivers/regulator/sc2731-regulator.c
@@ -0,0 +1,256 @@
+ //SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017 Spreadtrum Communications Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * SC2731 regulator lock register
+ */
+#define SC2731_PWR_WR_PROT_VALUE   0xf0c
+#define SC2731_WR_UNLOCK   0x6e7f
+
+/*
+ * SC2731 enable register
+ */
+#define SC2731_POWER_PD_SW 0xc28
+#define SC2731_LDO_CAMA0_PD0xcfc
+#define SC2731_LDO_CAMA1_PD0xd04
+#define SC2731_LDO_CAMMOT_PD   0xd0c
+#define SC2731_LDO_VLDO_PD 0xd6c
+#define SC2731_LDO_EMMCCORE_PD 0xd2c
+#define SC2731_LDO_SDCORE_PD   0xd74
+#define SC2731_LDO_SDIO_PD 0xd70
+#define SC2731_LDO_WIFIPA_PD   0xd4c
+#define SC2731_LDO_USB33_PD0xd5c
+#define SC2731_LDO_CAMD0_PD0xd7c
+#define SC2731_LDO_CAMD1_PD0xd84
+#define SC2731_LDO_CON_PD  0xd8c
+#define SC2731_LDO_CAMIO_PD0xd94
+#define SC2731_LDO_SRAM_PD 0xd78
+
+/*
+ * SC2731 enable mask
+ */
+#define SC2731_DCDC_CPU0_PD_MASK   BIT(4)
+#define SC2731_DCDC_CPU1_PD_MASK   BIT(3)
+#define SC2731_DCDC_RF_PD_MASK BIT(11)
+#define SC2731_LDO_CAMA0_PD_MASK   BIT(0)
+#define SC2731_LDO_CAMA1_PD_MASK   BIT(0)
+#define SC2731_LDO_CAMMOT_PD_MASK  BIT(0)
+#define SC2731_LDO_VLDO_PD_MASKBIT(0)
+#define SC2731_LDO_EMMCCORE_PD_MASKBIT(0)
+#define SC2731_LDO_SDCORE_PD_MASK  BIT(0)
+#define SC2731_LDO_SDIO_PD_MASKBIT(0)
+#define SC2731_LDO_WIFIPA_PD_MASK  BIT(0)
+#define SC2731_LDO_USB33_PD_MASK   BIT(0)
+#define SC2731_LDO_CAMD0_PD_MASK   BIT(0)
+#define SC2731_LDO_CAMD1_PD_MASK   BIT(0)
+#define SC2731_LDO_CON_PD_MASK BIT(0)
+#define SC2731_LDO_CAMIO_PD_MASK   BIT(0)
+#define SC2731_LDO_SRAM_PD_MASKBIT(0)
+
+/*
+ * SC2731 vsel register
+ */
+#define SC2731_DCDC_CPU0_VOL   0xc54
+#define SC2731_DCDC_CPU1_VOL   0xc64
+#define SC2731_DCDC_RF_VOL 0xcb8
+#define SC2731_LDO_CAMA0_VOL   0xd00
+#define SC2731_LDO_CAMA1_VOL   0xd08
+#define SC2731_LDO_CAMMOT_VOL  0xd10
+#define SC2731_LDO_VLDO_VOL0xd28
+#define SC2731_LDO_EMMCCORE_VOL0xd30
+#define SC2731_LDO_SDCORE_VOL  0xd38
+#define SC2731_LDO_SDIO_VOL0xd40
+#define SC2731_LDO_WIFIPA_VOL  0xd50
+#define SC2731_LDO_USB33_VOL   0xd60
+#define SC2731_LDO_CAMD0_VOL   0xd80
+#define SC2731_LDO_CAMD1_VOL   0xd88
+#define SC2731_LDO_CON_VOL 0xd90
+#define SC2731_LDO_CAMIO_VOL   0xd98
+#define SC2731_LDO_SRAM_VOL0xdB0
+
+/*
+ * SC2731 vsel register mask
+ */
+#define SC2731_DCDC_CPU0_VOL_MASK  GENMASK(8, 0)
+#define SC2731_DCDC_CPU1_VOL_MASK  GENMASK(8, 0)

[PATCH v2 1/2] dt-bindings: regulator: Add Spreadtrum SC2731 regulator documentation

[Erick Chen]

This patch adds support for the Spreadtrum SC2731
voltage regulator device.

Signed-off-by: Erick Chen 
---
Changes since v1:
- Remove reg property.
- Remove regulators sub-node.
---
 .../bindings/regulator/sprd,sc2731-regulator.txt   |   43 
 1 file changed, 43 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/sprd,sc2731-regulator.txt

diff --git 
a/Documentation/devicetree/bindings/regulator/sprd,sc2731-regulator.txt 
b/Documentation/devicetree/bindings/regulator/sprd,sc2731-regulator.txt
new file mode 100644
index 000..63dc078
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/sprd,sc2731-regulator.txt
@@ -0,0 +1,43 @@
+Spreadtrum SC2731 Voltage regulators
+
+The SC2731 integrates low-voltage and low quiescent current DCDC/LDO.
+14 LDO and 3 DCDCs are designed for external use. All DCDCs/LDOs have
+their own bypass (power-down) control signals. External tantalum or MLCC
+ceramic capacitors are recommended to use with these LDOs.
+
+Required properties:
+ - compatible: should be "sprd,sc27xx-regulator".
+
+List of regulators provided by this controller. It is named according to
+its regulator type, BUCK_ and LDO_. The definition for each
+of these nodes is defined using the standard binding for regulators at
+Documentation/devicetree/bindings/regulator/regulator.txt.
+
+The valid names for regulators are:
+BUCK:
+   BUCK_CPU0, BUCK_CPU1, BUCK_RF
+LDO:
+   LDO_CAMA0, LDO_CAMA1, LDO_CAMMOT, LDO_VLDO, LDO_EMMCCORE, LDO_SDCORE,
+   LDO_SDIO, LDO_WIFIPA, LDO_USB33, LDO_CAMD0, LDO_CAMD1, LDO_CON,
+   LDO_CAMIO, LDO_SRAM
+
+Example:
+   regulators {
+   compatible = "sprd,sc27xx-regulator";
+
+   vddarm0: BUCK_CPU0 {
+   regulator-name = "vddarm0";
+   regulator-min-microvolt = <40>;
+   regulator-max-microvolt = <1996875>;
+   regulator-ramp-delay = <25000>;
+   regulator-always-on;
+   };
+
+   vddcama0: LDO_CAMA0 {
+   regulator-name = "vddcama0";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <375>;
+   regulator-enable-ramp-delay = <100>;
+   };
+   ...
+   };
-- 
1.7.9.5

[PATCH v2 1/2] dt-bindings: regulator: Add Spreadtrum SC2731 regulator documentation

[Erick Chen]

This patch adds support for the Spreadtrum SC2731
voltage regulator device.

Signed-off-by: Erick Chen 
---
Changes since v1:
- Remove reg property.
- Remove regulators sub-node.
---
 .../bindings/regulator/sprd,sc2731-regulator.txt   |   43 
 1 file changed, 43 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/sprd,sc2731-regulator.txt

diff --git 
a/Documentation/devicetree/bindings/regulator/sprd,sc2731-regulator.txt 
b/Documentation/devicetree/bindings/regulator/sprd,sc2731-regulator.txt
new file mode 100644
index 000..63dc078
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/sprd,sc2731-regulator.txt
@@ -0,0 +1,43 @@
+Spreadtrum SC2731 Voltage regulators
+
+The SC2731 integrates low-voltage and low quiescent current DCDC/LDO.
+14 LDO and 3 DCDCs are designed for external use. All DCDCs/LDOs have
+their own bypass (power-down) control signals. External tantalum or MLCC
+ceramic capacitors are recommended to use with these LDOs.
+
+Required properties:
+ - compatible: should be "sprd,sc27xx-regulator".
+
+List of regulators provided by this controller. It is named according to
+its regulator type, BUCK_ and LDO_. The definition for each
+of these nodes is defined using the standard binding for regulators at
+Documentation/devicetree/bindings/regulator/regulator.txt.
+
+The valid names for regulators are:
+BUCK:
+   BUCK_CPU0, BUCK_CPU1, BUCK_RF
+LDO:
+   LDO_CAMA0, LDO_CAMA1, LDO_CAMMOT, LDO_VLDO, LDO_EMMCCORE, LDO_SDCORE,
+   LDO_SDIO, LDO_WIFIPA, LDO_USB33, LDO_CAMD0, LDO_CAMD1, LDO_CON,
+   LDO_CAMIO, LDO_SRAM
+
+Example:
+   regulators {
+   compatible = "sprd,sc27xx-regulator";
+
+   vddarm0: BUCK_CPU0 {
+   regulator-name = "vddarm0";
+   regulator-min-microvolt = <40>;
+   regulator-max-microvolt = <1996875>;
+   regulator-ramp-delay = <25000>;
+   regulator-always-on;
+   };
+
+   vddcama0: LDO_CAMA0 {
+   regulator-name = "vddcama0";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <375>;
+   regulator-enable-ramp-delay = <100>;
+   };
+   ...
+   };
-- 
1.7.9.5

RE: [Bug fix] octeon-i2c driver updates

[Zhang, Sean C. (NSB - CN/Hangzhou)]

Hi Jan,

Thanks for your comments, I get your point for the second point (retry of START 
after recovery).

Hi David,
For the issue as the first one, would you give your further comments? Thanks in 
advance.

I have an environment with CN6780 (TWSI core has property: compatible = 
"cavium,octeon-3860-twsi"),
And encounter below problem:
During i2c-octeon driver probing, this TWSI core original status is 0x20 (this 
may induced by uboot),
And octeon_i2c_init_lowlevel() function in octeon_i2c_probe() is not enough to 
recover the I2C bus,
If go without full recovery of octeon_i2c_recovery(), the following 
octeon_i2c_hlc_write(), 
octeon_i2c_hlc_read(), octeon_i2c_hlc_comp_read() and 
octeon_i2c_hlc_comp_write() will goes error,
because these functions has no bus recovery step.
While after replace octeon_i2c_init_lowlevel() with octeon_i2c_recovery() in 
octeon_i2c_probe(), the
problem has gone.

Once more, this octeon_i2c_recovery() can also recover dead lock (I2C slave 
device stuck low SCL) issue,
so I think use octeon_i2c_recovery() instead will be stronger.

BR,
Sean Zhang


-Original Message-
From: Jan Glauber [mailto:jan.glau...@caviumnetworks.com] 
Sent: Friday, December 01, 2017 6:07 PM
To: Zhang, Sean C. (NSB - CN/Hangzhou) 
Cc: david.da...@cavium.com; w...@the-dreams.de; linux-...@vger.kernel.org; 
linux-kernel@vger.kernel.org
Subject: Re: [Bug fix] octeon-i2c driver updates

Hi Sean,

as you try to solve two different issues I suggest that you create one
patch per issue.

For the second point (retry of START after recovery) I would still like
to hear Wolfram's opinion. I would assume that any i2c user should
be well aware of -EAGAIN, so I wonder if it is worth the additional
complexity of the retry logic.

Also, the first issue changes Octeon MIPS which I'm not able to test,
so David needs to be involved here.

thanks,
Jan

On Thu, Nov 30, 2017 at 01:56:09AM +, Zhang, Sean C. (NSB - CN/Hangzhou) 
wrote:
> Hi Jan,
> 
> Any other comments for this patch?
> 
> BR,
> Sean Zhang
> 
> -Original Message-
> From: Zhang, Sean C. (NSB - CN/Hangzhou) 
> Sent: Monday, November 27, 2017 4:38 PM
> To: 'Jan Glauber' 
> Cc: david.da...@cavium.com; w...@the-dreams.de; linux-...@vger.kernel.org; 
> linux-kernel@vger.kernel.org
> Subject: RE: [Bug fix] octeon-i2c driver updates
> 
> Hi Jan,
> 
> There are two points in this patch.
> 
> Point 1. As you see, replaced octeon_i2c_init_lowlevel() by recover bus 
> status if TWSI controller is not IDLE.
> Please take a scenario like this: when system soft reset without I2C slave 
> reset, maybe make this I2C bus
> dead lock occurred (I2C slave device stuck low SCL) in chance. Then during 
> system goes up and I2C slave 
> device creating process, if this I2C slave device has a register with less 
> than 8 bytes to read, but I2C bus was
> still stuck low SCL by last system reset, then the read will failed and this 
> I2C slave device cannot be created.
> If bus recovered before the reading process, this failure can be fixed.
> 
> Function flow explanation shown as below:
> 
> a. System reset without I2C slave device reset
> --make SCL stuck low by I2C slave device
> ..
> b. octeon_i2c_probe（）
> -- octeon_i2c_init_lowlevel  //reset TWSI core, but SCL still stuck low by.
> ..
> 
> c. Another I2C slave device creating process
> octeon_i2c_xfer()
> -- octeon_i2c_hlc_comp_read() //failed due to SCL stuck low.
> 
> If full recovery executed in octeon_i2c_probe（), above failure can be avoided.
> 
> 
> Point 2. octeon_i2c_recovery() is used in octeon_i2c_start() error branch, in 
> the case of octeon_i2c_recovery()
> successful, octeon_i2c_start() will return -EAGAIN, and then 
> octeon_i2c_xfer() return with error. I understand this like
> this: if octeon_i2c_recovery() successful, then i2c START signal can be sent 
> again, and all following step can be continue,
> octeon_i2c_xfer() should not return error from this condition.
> 
> BR,
> Sean Zhang
> 
> -Original Message-
> From: Jan Glauber [mailto:jan.glau...@caviumnetworks.com] 
> Sent: Friday, November 24, 2017 9:10 PM
> To: Zhang, Sean C. (NSB - CN/Hangzhou) 
> Cc: david.da...@cavium.com; w...@the-dreams.de; linux-...@vger.kernel.org; 
> linux-kernel@vger.kernel.org
> Subject: Re: [Bug fix] octeon-i2c driver updates
> 
> On Thu, Nov 23, 2017 at 11:42:36AM +, Zhang, Sean C. (NSB - CN/Hangzhou) 
> wrote:
> > Dear Maintainer,
> > 
> > For octeon TWSI controller, I found below two cases, maybe can be improved.
> 
> Hi Sean,
> 
> form the description below this looks like you're fixing a bug. Can you
> elaborate on when the I2C bus dead lock occurs. Is it always happening?
> 
> What I don't like about the patch is that you're removing
> octeon_i2c_init_lowlevel() from the probe and replacing it by _always_
> going through a full recovery. Why is this neccessary?
> 
> Regards,
> Jan
> 
> > 
> > 

RE: [Bug fix] octeon-i2c driver updates

[Zhang, Sean C. (NSB - CN/Hangzhou)]

Hi Jan,

Thanks for your comments, I get your point for the second point (retry of START 
after recovery).

Hi David,
For the issue as the first one, would you give your further comments? Thanks in 
advance.

I have an environment with CN6780 (TWSI core has property: compatible = 
"cavium,octeon-3860-twsi"),
And encounter below problem:
During i2c-octeon driver probing, this TWSI core original status is 0x20 (this 
may induced by uboot),
And octeon_i2c_init_lowlevel() function in octeon_i2c_probe() is not enough to 
recover the I2C bus,
If go without full recovery of octeon_i2c_recovery(), the following 
octeon_i2c_hlc_write(), 
octeon_i2c_hlc_read(), octeon_i2c_hlc_comp_read() and 
octeon_i2c_hlc_comp_write() will goes error,
because these functions has no bus recovery step.
While after replace octeon_i2c_init_lowlevel() with octeon_i2c_recovery() in 
octeon_i2c_probe(), the
problem has gone.

Once more, this octeon_i2c_recovery() can also recover dead lock (I2C slave 
device stuck low SCL) issue,
so I think use octeon_i2c_recovery() instead will be stronger.

BR,
Sean Zhang


-Original Message-
From: Jan Glauber [mailto:jan.glau...@caviumnetworks.com] 
Sent: Friday, December 01, 2017 6:07 PM
To: Zhang, Sean C. (NSB - CN/Hangzhou) 
Cc: david.da...@cavium.com; w...@the-dreams.de; linux-...@vger.kernel.org; 
linux-kernel@vger.kernel.org
Subject: Re: [Bug fix] octeon-i2c driver updates

Hi Sean,

as you try to solve two different issues I suggest that you create one
patch per issue.

For the second point (retry of START after recovery) I would still like
to hear Wolfram's opinion. I would assume that any i2c user should
be well aware of -EAGAIN, so I wonder if it is worth the additional
complexity of the retry logic.

Also, the first issue changes Octeon MIPS which I'm not able to test,
so David needs to be involved here.

thanks,
Jan

On Thu, Nov 30, 2017 at 01:56:09AM +, Zhang, Sean C. (NSB - CN/Hangzhou) 
wrote:
> Hi Jan,
> 
> Any other comments for this patch?
> 
> BR,
> Sean Zhang
> 
> -Original Message-
> From: Zhang, Sean C. (NSB - CN/Hangzhou) 
> Sent: Monday, November 27, 2017 4:38 PM
> To: 'Jan Glauber' 
> Cc: david.da...@cavium.com; w...@the-dreams.de; linux-...@vger.kernel.org; 
> linux-kernel@vger.kernel.org
> Subject: RE: [Bug fix] octeon-i2c driver updates
> 
> Hi Jan,
> 
> There are two points in this patch.
> 
> Point 1. As you see, replaced octeon_i2c_init_lowlevel() by recover bus 
> status if TWSI controller is not IDLE.
> Please take a scenario like this: when system soft reset without I2C slave 
> reset, maybe make this I2C bus
> dead lock occurred (I2C slave device stuck low SCL) in chance. Then during 
> system goes up and I2C slave 
> device creating process, if this I2C slave device has a register with less 
> than 8 bytes to read, but I2C bus was
> still stuck low SCL by last system reset, then the read will failed and this 
> I2C slave device cannot be created.
> If bus recovered before the reading process, this failure can be fixed.
> 
> Function flow explanation shown as below:
> 
> a. System reset without I2C slave device reset
> --make SCL stuck low by I2C slave device
> ..
> b. octeon_i2c_probe（）
> -- octeon_i2c_init_lowlevel  //reset TWSI core, but SCL still stuck low by.
> ..
> 
> c. Another I2C slave device creating process
> octeon_i2c_xfer()
> -- octeon_i2c_hlc_comp_read() //failed due to SCL stuck low.
> 
> If full recovery executed in octeon_i2c_probe（), above failure can be avoided.
> 
> 
> Point 2. octeon_i2c_recovery() is used in octeon_i2c_start() error branch, in 
> the case of octeon_i2c_recovery()
> successful, octeon_i2c_start() will return -EAGAIN, and then 
> octeon_i2c_xfer() return with error. I understand this like
> this: if octeon_i2c_recovery() successful, then i2c START signal can be sent 
> again, and all following step can be continue,
> octeon_i2c_xfer() should not return error from this condition.
> 
> BR,
> Sean Zhang
> 
> -Original Message-
> From: Jan Glauber [mailto:jan.glau...@caviumnetworks.com] 
> Sent: Friday, November 24, 2017 9:10 PM
> To: Zhang, Sean C. (NSB - CN/Hangzhou) 
> Cc: david.da...@cavium.com; w...@the-dreams.de; linux-...@vger.kernel.org; 
> linux-kernel@vger.kernel.org
> Subject: Re: [Bug fix] octeon-i2c driver updates
> 
> On Thu, Nov 23, 2017 at 11:42:36AM +, Zhang, Sean C. (NSB - CN/Hangzhou) 
> wrote:
> > Dear Maintainer,
> > 
> > For octeon TWSI controller, I found below two cases, maybe can be improved.
> 
> Hi Sean,
> 
> form the description below this looks like you're fixing a bug. Can you
> elaborate on when the I2C bus dead lock occurs. Is it always happening?
> 
> What I don't like about the patch is that you're removing
> octeon_i2c_init_lowlevel() from the probe and replacing it by _always_
> going through a full recovery. Why is this neccessary?
> 
> Regards,
> Jan
> 
> > 
> > >From 09d9f0ce658d7f6a50d1af352dde619c29bc8bcf Mon Sep 17 00:00:00 2001
> > From: hgt463 
> > 

[PATCH] writeback: fix comment in __mark_inode_dirty

[Wang Long]

Signed-off-by: Wang Long 
---
 fs/fs-writeback.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index cea4836..8d477cf 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -2209,7 +2209,7 @@ void __mark_inode_dirty(struct inode *inode, int flags)
trace_writeback_dirty_inode_enqueue(inode);
 
/*
-* If this is the first dirty inode for this bdi,
+* If this is the first dirty inode for this wb,
 * we have to wake-up the corresponding bdi thread
 * to make sure background write-back happens
 * later.
-- 
1.8.3.1

[PATCH] writeback: fix comment in __mark_inode_dirty

[Wang Long]

Signed-off-by: Wang Long 
---
 fs/fs-writeback.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index cea4836..8d477cf 100644
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -2209,7 +2209,7 @@ void __mark_inode_dirty(struct inode *inode, int flags)
trace_writeback_dirty_inode_enqueue(inode);
 
/*
-* If this is the first dirty inode for this bdi,
+* If this is the first dirty inode for this wb,
 * we have to wake-up the corresponding bdi thread
 * to make sure background write-back happens
 * later.
-- 
1.8.3.1

Re: [PATCH v3 12/16] iommu/vt-d: report unrecoverable device faults

[Lu Baolu]

Hi,

On 11/18/2017 02:55 AM, Jacob Pan wrote:
> Currently, when device DMA faults are detected by IOMMU the fault
> reasons are printed but the driver of the offending device is

"... but the driver of the offending device is not involved in ..."

Best regards,
Lu Baolu

> involved in fault handling.
> This patch uses per device fault reporting API to send fault event
> data for further processing.
> Offending device is identified by the source ID in VT-d fault reason
> report registers.
>
> Signed-off-by: Liu, Yi L 
> Signed-off-by: Jacob Pan 
> Signed-off-by: Ashok Raj 
> ---
>  drivers/iommu/dmar.c | 94 
> +++-
>  1 file changed, 93 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
> index 38ee91b..b1f67fc2 100644
> --- a/drivers/iommu/dmar.c
> +++ b/drivers/iommu/dmar.c
> @@ -1555,6 +1555,31 @@ static const char *irq_remap_fault_reasons[] =
>   "Blocked an interrupt request due to source-id verification failure",
>  };
>  
> +/* fault data and status */
> +enum intel_iommu_fault_reason {
> + INTEL_IOMMU_FAULT_REASON_SW,
> + INTEL_IOMMU_FAULT_REASON_ROOT_NOT_PRESENT,
> + INTEL_IOMMU_FAULT_REASON_CONTEXT_NOT_PRESENT,
> + INTEL_IOMMU_FAULT_REASON_CONTEXT_INVALID,
> + INTEL_IOMMU_FAULT_REASON_BEYOND_ADDR_WIDTH,
> + INTEL_IOMMU_FAULT_REASON_PTE_WRITE_ACCESS,
> + INTEL_IOMMU_FAULT_REASON_PTE_READ_ACCESS,
> + INTEL_IOMMU_FAULT_REASON_NEXT_PT_INVALID,
> + INTEL_IOMMU_FAULT_REASON_ROOT_ADDR_INVALID,
> + INTEL_IOMMU_FAULT_REASON_CONTEXT_PTR_INVALID,
> + INTEL_IOMMU_FAULT_REASON_NONE_ZERO_RTP,
> + INTEL_IOMMU_FAULT_REASON_NONE_ZERO_CTP,
> + INTEL_IOMMU_FAULT_REASON_NONE_ZERO_PTE,
> + NR_INTEL_IOMMU_FAULT_REASON,
> +};
> +
> +/* fault reasons that are allowed to be reported outside IOMMU subsystem */
> +#define INTEL_IOMMU_FAULT_REASON_ALLOWED \
> + ((1ULL << INTEL_IOMMU_FAULT_REASON_BEYOND_ADDR_WIDTH) | \
> + (1ULL << INTEL_IOMMU_FAULT_REASON_PTE_WRITE_ACCESS) |   \
> + (1ULL << INTEL_IOMMU_FAULT_REASON_PTE_READ_ACCESS))
> +
> +
>  static const char *dmar_get_fault_reason(u8 fault_reason, int *fault_type)
>  {
>   if (fault_reason >= 0x20 && (fault_reason - 0x20 <
> @@ -1635,6 +1660,69 @@ void dmar_msi_read(int irq, struct msi_msg *msg)
>   raw_spin_unlock_irqrestore(>register_lock, flag);
>  }
>  
> +static enum iommu_fault_reason to_iommu_fault_reason(u8 reason)
> +{
> + if (reason >= NR_INTEL_IOMMU_FAULT_REASON) {
> + pr_warn("unknown DMAR fault reason %d\n", reason);
> + return IOMMU_FAULT_REASON_UNKNOWN;
> + }
> + switch (reason) {
> + case INTEL_IOMMU_FAULT_REASON_SW:
> + case INTEL_IOMMU_FAULT_REASON_ROOT_NOT_PRESENT:
> + case INTEL_IOMMU_FAULT_REASON_CONTEXT_NOT_PRESENT:
> + case INTEL_IOMMU_FAULT_REASON_CONTEXT_INVALID:
> + case INTEL_IOMMU_FAULT_REASON_BEYOND_ADDR_WIDTH:
> + case INTEL_IOMMU_FAULT_REASON_ROOT_ADDR_INVALID:
> + case INTEL_IOMMU_FAULT_REASON_CONTEXT_PTR_INVALID:
> + return IOMMU_FAULT_REASON_INTERNAL;
> + case INTEL_IOMMU_FAULT_REASON_NEXT_PT_INVALID:
> + case INTEL_IOMMU_FAULT_REASON_PTE_WRITE_ACCESS:
> + case INTEL_IOMMU_FAULT_REASON_PTE_READ_ACCESS:
> + return IOMMU_FAULT_REASON_PERMISSION;
> + default:
> + return IOMMU_FAULT_REASON_UNKNOWN;
> + }
> +}
> +
> +static void report_fault_to_device(struct intel_iommu *iommu, u64 addr, int 
> type,
> + int fault_type, enum intel_iommu_fault_reason 
> reason, u16 sid)
> +{
> + struct iommu_fault_event event;
> + struct pci_dev *pdev;
> + u8 bus, devfn;
> +
> + /* check if fault reason is worth reporting outside IOMMU */
> + if (!((1 << reason) & INTEL_IOMMU_FAULT_REASON_ALLOWED)) {
> + pr_debug("Fault reason %d not allowed to report to device\n",
> + reason);
> + return;
> + }
> +
> + bus = PCI_BUS_NUM(sid);
> + devfn = PCI_DEVFN(PCI_SLOT(sid), PCI_FUNC(sid));
> + /*
> +  * we need to check if the fault reporting is requested for the
> +  * offending device.
> +  */
> + pdev = pci_get_bus_and_slot(bus, devfn);
> + if (!pdev) {
> + pr_warn("No PCI device found for source ID %x\n", sid);
> + return;
> + }
> + /*
> +  * unrecoverable fault is reported per IOMMU, notifier handler can
> +  * resolve PCI device based on source ID.
> +  */
> + event.reason = to_iommu_fault_reason(reason);
> + event.addr = addr;
> + event.type = IOMMU_FAULT_DMA_UNRECOV;
> + event.prot = type ? IOMMU_READ : IOMMU_WRITE;
> + dev_warn(>dev, "report device unrecoverable fault: %d, %x, %d\n",
> + event.reason, sid, event.type);
> + iommu_report_device_fault(>dev, );
> +

Re: [PATCH v3 12/16] iommu/vt-d: report unrecoverable device faults

[Lu Baolu]

Hi,

On 11/18/2017 02:55 AM, Jacob Pan wrote:
> Currently, when device DMA faults are detected by IOMMU the fault
> reasons are printed but the driver of the offending device is

"... but the driver of the offending device is not involved in ..."

Best regards,
Lu Baolu

> involved in fault handling.
> This patch uses per device fault reporting API to send fault event
> data for further processing.
> Offending device is identified by the source ID in VT-d fault reason
> report registers.
>
> Signed-off-by: Liu, Yi L 
> Signed-off-by: Jacob Pan 
> Signed-off-by: Ashok Raj 
> ---
>  drivers/iommu/dmar.c | 94 
> +++-
>  1 file changed, 93 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
> index 38ee91b..b1f67fc2 100644
> --- a/drivers/iommu/dmar.c
> +++ b/drivers/iommu/dmar.c
> @@ -1555,6 +1555,31 @@ static const char *irq_remap_fault_reasons[] =
>   "Blocked an interrupt request due to source-id verification failure",
>  };
>  
> +/* fault data and status */
> +enum intel_iommu_fault_reason {
> + INTEL_IOMMU_FAULT_REASON_SW,
> + INTEL_IOMMU_FAULT_REASON_ROOT_NOT_PRESENT,
> + INTEL_IOMMU_FAULT_REASON_CONTEXT_NOT_PRESENT,
> + INTEL_IOMMU_FAULT_REASON_CONTEXT_INVALID,
> + INTEL_IOMMU_FAULT_REASON_BEYOND_ADDR_WIDTH,
> + INTEL_IOMMU_FAULT_REASON_PTE_WRITE_ACCESS,
> + INTEL_IOMMU_FAULT_REASON_PTE_READ_ACCESS,
> + INTEL_IOMMU_FAULT_REASON_NEXT_PT_INVALID,
> + INTEL_IOMMU_FAULT_REASON_ROOT_ADDR_INVALID,
> + INTEL_IOMMU_FAULT_REASON_CONTEXT_PTR_INVALID,
> + INTEL_IOMMU_FAULT_REASON_NONE_ZERO_RTP,
> + INTEL_IOMMU_FAULT_REASON_NONE_ZERO_CTP,
> + INTEL_IOMMU_FAULT_REASON_NONE_ZERO_PTE,
> + NR_INTEL_IOMMU_FAULT_REASON,
> +};
> +
> +/* fault reasons that are allowed to be reported outside IOMMU subsystem */
> +#define INTEL_IOMMU_FAULT_REASON_ALLOWED \
> + ((1ULL << INTEL_IOMMU_FAULT_REASON_BEYOND_ADDR_WIDTH) | \
> + (1ULL << INTEL_IOMMU_FAULT_REASON_PTE_WRITE_ACCESS) |   \
> + (1ULL << INTEL_IOMMU_FAULT_REASON_PTE_READ_ACCESS))
> +
> +
>  static const char *dmar_get_fault_reason(u8 fault_reason, int *fault_type)
>  {
>   if (fault_reason >= 0x20 && (fault_reason - 0x20 <
> @@ -1635,6 +1660,69 @@ void dmar_msi_read(int irq, struct msi_msg *msg)
>   raw_spin_unlock_irqrestore(>register_lock, flag);
>  }
>  
> +static enum iommu_fault_reason to_iommu_fault_reason(u8 reason)
> +{
> + if (reason >= NR_INTEL_IOMMU_FAULT_REASON) {
> + pr_warn("unknown DMAR fault reason %d\n", reason);
> + return IOMMU_FAULT_REASON_UNKNOWN;
> + }
> + switch (reason) {
> + case INTEL_IOMMU_FAULT_REASON_SW:
> + case INTEL_IOMMU_FAULT_REASON_ROOT_NOT_PRESENT:
> + case INTEL_IOMMU_FAULT_REASON_CONTEXT_NOT_PRESENT:
> + case INTEL_IOMMU_FAULT_REASON_CONTEXT_INVALID:
> + case INTEL_IOMMU_FAULT_REASON_BEYOND_ADDR_WIDTH:
> + case INTEL_IOMMU_FAULT_REASON_ROOT_ADDR_INVALID:
> + case INTEL_IOMMU_FAULT_REASON_CONTEXT_PTR_INVALID:
> + return IOMMU_FAULT_REASON_INTERNAL;
> + case INTEL_IOMMU_FAULT_REASON_NEXT_PT_INVALID:
> + case INTEL_IOMMU_FAULT_REASON_PTE_WRITE_ACCESS:
> + case INTEL_IOMMU_FAULT_REASON_PTE_READ_ACCESS:
> + return IOMMU_FAULT_REASON_PERMISSION;
> + default:
> + return IOMMU_FAULT_REASON_UNKNOWN;
> + }
> +}
> +
> +static void report_fault_to_device(struct intel_iommu *iommu, u64 addr, int 
> type,
> + int fault_type, enum intel_iommu_fault_reason 
> reason, u16 sid)
> +{
> + struct iommu_fault_event event;
> + struct pci_dev *pdev;
> + u8 bus, devfn;
> +
> + /* check if fault reason is worth reporting outside IOMMU */
> + if (!((1 << reason) & INTEL_IOMMU_FAULT_REASON_ALLOWED)) {
> + pr_debug("Fault reason %d not allowed to report to device\n",
> + reason);
> + return;
> + }
> +
> + bus = PCI_BUS_NUM(sid);
> + devfn = PCI_DEVFN(PCI_SLOT(sid), PCI_FUNC(sid));
> + /*
> +  * we need to check if the fault reporting is requested for the
> +  * offending device.
> +  */
> + pdev = pci_get_bus_and_slot(bus, devfn);
> + if (!pdev) {
> + pr_warn("No PCI device found for source ID %x\n", sid);
> + return;
> + }
> + /*
> +  * unrecoverable fault is reported per IOMMU, notifier handler can
> +  * resolve PCI device based on source ID.
> +  */
> + event.reason = to_iommu_fault_reason(reason);
> + event.addr = addr;
> + event.type = IOMMU_FAULT_DMA_UNRECOV;
> + event.prot = type ? IOMMU_READ : IOMMU_WRITE;
> + dev_warn(>dev, "report device unrecoverable fault: %d, %x, %d\n",
> + event.reason, sid, event.type);
> + iommu_report_device_fault(>dev, );
> + pci_dev_put(pdev);
> +}
> +
>  static int dmar_fault_do_one(struct 

Re: [alsa-devel] [PATCH v4 06/15] soundwire: Add IO transfer

[Vinod Koul]

On Sun, Dec 03, 2017 at 09:01:41PM -0600, Pierre-Louis Bossart wrote:
> On 12/3/17 11:04 AM, Vinod Koul wrote:
> >On Fri, Dec 01, 2017 at 05:27:31PM -0600, Pierre-Louis Bossart wrote:

Sorry looks like I missed replying to this one earlier.

> >>>+static inline int find_response_code(enum sdw_command_response resp)
> >>>+{
> >>>+  switch (resp) {
> >>>+  case SDW_CMD_OK:
> >>>+  return 0;
> >>>+
> >>>+  case SDW_CMD_IGNORED:
> >>>+  return -ENODATA;
> >>>+
> >>>+  case SDW_CMD_TIMEOUT:
> >>>+  return -ETIMEDOUT;
> >>>+
> >>>+  default:
> >>>+  return -EIO;
> >>
> >>the 'default' case will handle both SDW_CMD_FAIL (which is a bus event
> >>usually due to bus clash or parity issues) and SDW_CMD_FAIL_OTHER (which is
> >>an imp-def IP event).
> >>
> >>Do they really belong in the same basket? From a debug perspective there is
> >>quite a bit of information lost.
> >
> >at higher level the error handling is same. the information is not lost as
> >it is expected that you would log it at error source.
> 
> I don't understand this. It's certainly not the same for me if you detect an
> electric problem or if the IP is in the weeds. Logging at the source is fine
> but this filtering prevents higher levels from doing anything different.

The point is higher levels like here cant do much than bail out and complain.

Can you point out what would be different behaviour in each of these cases?

> >>>+static inline int do_transfer(struct sdw_bus *bus, struct sdw_msg *msg)
> >>>+{
> >>>+  int retry = bus->prop.err_threshold;
> >>>+  enum sdw_command_response resp;
> >>>+  int ret = 0, i;
> >>>+
> >>>+  for (i = 0; i <= retry; i++) {
> >>>+  resp = bus->ops->xfer_msg(bus, msg);
> >>>+  ret = find_response_code(resp);
> >>>+
> >>>+  /* if cmd is ok or ignored return */
> >>>+  if (ret == 0 || ret == -ENODATA)
> >>
> >>Can you document why you don't retry on a CMD_IGNORED? I know there was a
> >>reason, I just can't remember it.
> >
> >CMD_IGNORED can be okay on broadcast. User of this API can retry all they
> >want!
> 
> So you retry if this is a CMD_FAILED but let higher levels retry for
> CMD_IGNORED, sorry I don't see the logic.

Yes that is right.

If I am doing a broadcast read, lets say for Device Id registers, why in the
world would I want to retry? CMD_IGNORED is a valid response and required to
stop enumeration cycle in that case.

But if I am not expecting a CMD_IGNORED response, I can very well go ahead
and retry from caller. The context is with caller and they can choose to do
appropriate handling.

And I have clarified this couple of times to you already, not sure how many
more times I would have to do that.

> >>Now that I think of it, the retry on TIMEOUT makes no sense to me. The retry
> >>was intended for bus-level issues, where maybe a single bit error causes an
> >>issue without consequences, but the TIMEOUT is a completely different beast,
> >>it's the master IP that doesn't answer really, a completely different case.
> >
> >well in those cases where you have blue wires, it actually helps :)
> 
> Blue wires are not supposed to change electrical behavior. TIMEOUT is only
> an internal SOC level issue, so no I don't get how this helps.
> 
> You have a retry count that is provided in the BIOS/firmware through disco
> properties and it's meant to bus errors. You are abusing the definitions. A
> command failed is supposed to be detected at the frame rate, which is
> typically 20us. a timeout is likely a 100s of ms value, so if you retry on
> top it's going to lock up the bus.

The world is not perfect! A guy debugging setups needs all the help. I do
not see any reason for not to retry. Bus is anyway locked up while a
transfer is ongoing (we serialize transfers).

Now if you feel this should be abhorred, I can change this for timeout.

> >>>+enum sdw_command_response {
> >>>+  SDW_CMD_OK = 0,
> >>>+  SDW_CMD_IGNORED = 1,
> >>>+  SDW_CMD_FAIL = 2,
> >>>+  SDW_CMD_TIMEOUT = 4,
> >>>+  SDW_CMD_FAIL_OTHER = 8,
> >>
> >>Humm, I can't recall if/why this is a mask? does it need to be?
> >
> >mask, not following!
> >
> >Taking a wild guess that you are asking about last error, which is for SW
> >errors like malloc fail etc...
> 
> no, I was asking why this is declared as if it was used for a bitmask, why
> not 0,1,2,3,4?

Oh okay, I think it was something to do with bits for errors, but don see it
helping so I can change it either way...

-- 
~Vinod

Re: [alsa-devel] [PATCH v4 06/15] soundwire: Add IO transfer

[Vinod Koul]

On Sun, Dec 03, 2017 at 09:01:41PM -0600, Pierre-Louis Bossart wrote:
> On 12/3/17 11:04 AM, Vinod Koul wrote:
> >On Fri, Dec 01, 2017 at 05:27:31PM -0600, Pierre-Louis Bossart wrote:

Sorry looks like I missed replying to this one earlier.

> >>>+static inline int find_response_code(enum sdw_command_response resp)
> >>>+{
> >>>+  switch (resp) {
> >>>+  case SDW_CMD_OK:
> >>>+  return 0;
> >>>+
> >>>+  case SDW_CMD_IGNORED:
> >>>+  return -ENODATA;
> >>>+
> >>>+  case SDW_CMD_TIMEOUT:
> >>>+  return -ETIMEDOUT;
> >>>+
> >>>+  default:
> >>>+  return -EIO;
> >>
> >>the 'default' case will handle both SDW_CMD_FAIL (which is a bus event
> >>usually due to bus clash or parity issues) and SDW_CMD_FAIL_OTHER (which is
> >>an imp-def IP event).
> >>
> >>Do they really belong in the same basket? From a debug perspective there is
> >>quite a bit of information lost.
> >
> >at higher level the error handling is same. the information is not lost as
> >it is expected that you would log it at error source.
> 
> I don't understand this. It's certainly not the same for me if you detect an
> electric problem or if the IP is in the weeds. Logging at the source is fine
> but this filtering prevents higher levels from doing anything different.

The point is higher levels like here cant do much than bail out and complain.

Can you point out what would be different behaviour in each of these cases?

> >>>+static inline int do_transfer(struct sdw_bus *bus, struct sdw_msg *msg)
> >>>+{
> >>>+  int retry = bus->prop.err_threshold;
> >>>+  enum sdw_command_response resp;
> >>>+  int ret = 0, i;
> >>>+
> >>>+  for (i = 0; i <= retry; i++) {
> >>>+  resp = bus->ops->xfer_msg(bus, msg);
> >>>+  ret = find_response_code(resp);
> >>>+
> >>>+  /* if cmd is ok or ignored return */
> >>>+  if (ret == 0 || ret == -ENODATA)
> >>
> >>Can you document why you don't retry on a CMD_IGNORED? I know there was a
> >>reason, I just can't remember it.
> >
> >CMD_IGNORED can be okay on broadcast. User of this API can retry all they
> >want!
> 
> So you retry if this is a CMD_FAILED but let higher levels retry for
> CMD_IGNORED, sorry I don't see the logic.

Yes that is right.

If I am doing a broadcast read, lets say for Device Id registers, why in the
world would I want to retry? CMD_IGNORED is a valid response and required to
stop enumeration cycle in that case.

But if I am not expecting a CMD_IGNORED response, I can very well go ahead
and retry from caller. The context is with caller and they can choose to do
appropriate handling.

And I have clarified this couple of times to you already, not sure how many
more times I would have to do that.

> >>Now that I think of it, the retry on TIMEOUT makes no sense to me. The retry
> >>was intended for bus-level issues, where maybe a single bit error causes an
> >>issue without consequences, but the TIMEOUT is a completely different beast,
> >>it's the master IP that doesn't answer really, a completely different case.
> >
> >well in those cases where you have blue wires, it actually helps :)
> 
> Blue wires are not supposed to change electrical behavior. TIMEOUT is only
> an internal SOC level issue, so no I don't get how this helps.
> 
> You have a retry count that is provided in the BIOS/firmware through disco
> properties and it's meant to bus errors. You are abusing the definitions. A
> command failed is supposed to be detected at the frame rate, which is
> typically 20us. a timeout is likely a 100s of ms value, so if you retry on
> top it's going to lock up the bus.

The world is not perfect! A guy debugging setups needs all the help. I do
not see any reason for not to retry. Bus is anyway locked up while a
transfer is ongoing (we serialize transfers).

Now if you feel this should be abhorred, I can change this for timeout.

> >>>+enum sdw_command_response {
> >>>+  SDW_CMD_OK = 0,
> >>>+  SDW_CMD_IGNORED = 1,
> >>>+  SDW_CMD_FAIL = 2,
> >>>+  SDW_CMD_TIMEOUT = 4,
> >>>+  SDW_CMD_FAIL_OTHER = 8,
> >>
> >>Humm, I can't recall if/why this is a mask? does it need to be?
> >
> >mask, not following!
> >
> >Taking a wild guess that you are asking about last error, which is for SW
> >errors like malloc fail etc...
> 
> no, I was asking why this is declared as if it was used for a bitmask, why
> not 0,1,2,3,4?

Oh okay, I think it was something to do with bits for errors, but don see it
helping so I can change it either way...

-- 
~Vinod

[PATCH v3] scripts: leaking_addresses: add support for 32-bit kernel addresses

[kaiwan . billimoria]

Currently, leaking_addresses.pl only supports scanning 64 bit
architectures. This is due to how the regular expressions are formed. We
can do better than this. 32 architectures can be supported if we take
into consideration the kernel virtual address split (via the PAGE_OFFSET
kernel configurable).

Add support for ix86 32 bit architectures.
 - Add command line option for page offset.
 - Add command line option for kernel configuration file.
 - Parse kernel config file for page offset (CONFIG_PAGE_OFFSET).
 - Use page offset when checking for kernel virtual addresses.


Signed-off-by: Kaiwan N Billimoria 
---

Note- This patch represents co development by Tobin and Kaiwan (plus 
suggestions from 
Alexander Kapshuk). Applies on Tobin's tree 'leaks' branch on top of commit 
680db1ef560f
(leaking_addresses: fix typo function not called).


 scripts/leaking_addresses.pl | 169 +--
 1 file changed, 148 insertions(+), 21 deletions(-)

diff --git a/scripts/leaking_addresses.pl b/scripts/leaking_addresses.pl
index 2d5336b3e1ea..6b015980d117 100755
--- a/scripts/leaking_addresses.pl
+++ b/scripts/leaking_addresses.pl
@@ -24,6 +24,7 @@ use Cwd 'abs_path';
 use Term::ANSIColor qw(:constants);
 use Getopt::Long qw(:config no_auto_abbrev);
 use Config;
+use feature 'state';
 
 my $P = $0;
 my $V = '0.01';
@@ -37,18 +38,20 @@ my $TIMEOUT = 10;
 # Script can only grep for kernel addresses on the following architectures. If
 # your architecture is not listed here and has a grep'able kernel address 
please
 # consider submitting a patch.
-my @SUPPORTED_ARCHITECTURES = ('x86_64', 'ppc64');
+my @SUPPORTED_ARCHITECTURES = ('x86_64', 'ppc64',  'i[3456]86');
 
 # Command line options.
 my $help = 0;
 my $debug = 0;
-my $raw = 0;
-my $output_raw = "";   # Write raw results to file.
-my $input_raw = "";# Read raw results from file instead of scanning.
+my $raw = 0;   # Show raw output.
+my $output_raw = "";   # Write raw results to file.
+my $input_raw = "";# Read raw results from file instead of 
scanning.
+my $suppress_dmesg = 0;   # Don't show dmesg in output.
+my $squash_by_path = 0;   # Summary report grouped by absolute 
path.
+my $squash_by_filename = 0;# Summary report grouped by filename.
 
-my $suppress_dmesg = 0;# Don't show dmesg in output.
-my $squash_by_path = 0;# Summary report grouped by absolute 
path.
-my $squash_by_filename = 0;# Summary report grouped by filename.
+my $page_offset_32bit = 0; # 32-bit: value of CONFIG_PAGE_OFFSET
+my $kernel_config_file = "";   # Kernel configuration file.
 
 # Do not parse these files (absolute path).
 my @skip_parse_files_abs = ('/proc/kmsg',
@@ -97,14 +100,16 @@ Version: $V
 
 Options:
 
-   -o, --output-raw=  Save results for future processing.
-   -i, --input-raw=   Read results from file instead of scanning.
-   --rawShow raw results (default).
-   --suppress-dmesg Do not show dmesg results.
-   --squash-by-path Show one result per unique path.
-   --squash-by-filename Show one result per unique filename.
-   -d, --debug  Display debugging output.
-   -h, --help, --versionDisplay this help and exit.
+   -o, --output-raw= Save results for future processing.
+   -i, --input-raw=  Read results from file instead of 
scanning.
+   --raw   Show raw results (default).
+   --suppress-dmesgDo not show dmesg results.
+   --squash-by-pathShow one result per unique path.
+   --squash-by-filenameShow one result per unique filename.
+   --page-offset-32bit=   PAGE_OFFSET value (for 32-bit kernels).
+   --kernel-config-file= Kernel configuration file (e.g 
/boot/config)
+   -d, --debug Display debugging output.
+   -h, --help, --version   Display this help and exit.
 
 Examples:
 
@@ -117,7 +122,10 @@ Examples:
# View summary report.
$0 --input-raw scan.out --squash-by-filename
 
-Scans the running (64 bit) kernel for potential leaking addresses.
+   # Scan kernel on a 32-bit system with a 2GB:2GB virtual address split.
+   $0 --page-offset-32bit=0x8000
+
+Scans the running kernel for potential leaking addresses.
 
 EOM
exit($exitcode);
@@ -133,6 +141,8 @@ GetOptions(
'squash-by-path'=> \$squash_by_path,
'squash-by-filename'=> \$squash_by_filename,
'raw'   => \$raw,
+   'page-offset-32bit=o'   => \$page_offset_32bit,
+   'kernel-config-file=s'  => \$kernel_config_file,
 ) or help(1);
 
 help(0) if ($help);
@@ -148,6 +158,7 @@ if (!$input_raw and ($squash_by_path or 
$squash_by_filename)) {
exit(128);
 }
 
+show_detected_architecture() if $debug;
 if 

[PATCH v3] scripts: leaking_addresses: add support for 32-bit kernel addresses

[kaiwan . billimoria]

Currently, leaking_addresses.pl only supports scanning 64 bit
architectures. This is due to how the regular expressions are formed. We
can do better than this. 32 architectures can be supported if we take
into consideration the kernel virtual address split (via the PAGE_OFFSET
kernel configurable).

Add support for ix86 32 bit architectures.
 - Add command line option for page offset.
 - Add command line option for kernel configuration file.
 - Parse kernel config file for page offset (CONFIG_PAGE_OFFSET).
 - Use page offset when checking for kernel virtual addresses.


Signed-off-by: Kaiwan N Billimoria 
---

Note- This patch represents co development by Tobin and Kaiwan (plus 
suggestions from 
Alexander Kapshuk). Applies on Tobin's tree 'leaks' branch on top of commit 
680db1ef560f
(leaking_addresses: fix typo function not called).


 scripts/leaking_addresses.pl | 169 +--
 1 file changed, 148 insertions(+), 21 deletions(-)

diff --git a/scripts/leaking_addresses.pl b/scripts/leaking_addresses.pl
index 2d5336b3e1ea..6b015980d117 100755
--- a/scripts/leaking_addresses.pl
+++ b/scripts/leaking_addresses.pl
@@ -24,6 +24,7 @@ use Cwd 'abs_path';
 use Term::ANSIColor qw(:constants);
 use Getopt::Long qw(:config no_auto_abbrev);
 use Config;
+use feature 'state';
 
 my $P = $0;
 my $V = '0.01';
@@ -37,18 +38,20 @@ my $TIMEOUT = 10;
 # Script can only grep for kernel addresses on the following architectures. If
 # your architecture is not listed here and has a grep'able kernel address 
please
 # consider submitting a patch.
-my @SUPPORTED_ARCHITECTURES = ('x86_64', 'ppc64');
+my @SUPPORTED_ARCHITECTURES = ('x86_64', 'ppc64',  'i[3456]86');
 
 # Command line options.
 my $help = 0;
 my $debug = 0;
-my $raw = 0;
-my $output_raw = "";   # Write raw results to file.
-my $input_raw = "";# Read raw results from file instead of scanning.
+my $raw = 0;   # Show raw output.
+my $output_raw = "";   # Write raw results to file.
+my $input_raw = "";# Read raw results from file instead of 
scanning.
+my $suppress_dmesg = 0;   # Don't show dmesg in output.
+my $squash_by_path = 0;   # Summary report grouped by absolute 
path.
+my $squash_by_filename = 0;# Summary report grouped by filename.
 
-my $suppress_dmesg = 0;# Don't show dmesg in output.
-my $squash_by_path = 0;# Summary report grouped by absolute 
path.
-my $squash_by_filename = 0;# Summary report grouped by filename.
+my $page_offset_32bit = 0; # 32-bit: value of CONFIG_PAGE_OFFSET
+my $kernel_config_file = "";   # Kernel configuration file.
 
 # Do not parse these files (absolute path).
 my @skip_parse_files_abs = ('/proc/kmsg',
@@ -97,14 +100,16 @@ Version: $V
 
 Options:
 
-   -o, --output-raw=  Save results for future processing.
-   -i, --input-raw=   Read results from file instead of scanning.
-   --rawShow raw results (default).
-   --suppress-dmesg Do not show dmesg results.
-   --squash-by-path Show one result per unique path.
-   --squash-by-filename Show one result per unique filename.
-   -d, --debug  Display debugging output.
-   -h, --help, --versionDisplay this help and exit.
+   -o, --output-raw= Save results for future processing.
+   -i, --input-raw=  Read results from file instead of 
scanning.
+   --raw   Show raw results (default).
+   --suppress-dmesgDo not show dmesg results.
+   --squash-by-pathShow one result per unique path.
+   --squash-by-filenameShow one result per unique filename.
+   --page-offset-32bit=   PAGE_OFFSET value (for 32-bit kernels).
+   --kernel-config-file= Kernel configuration file (e.g 
/boot/config)
+   -d, --debug Display debugging output.
+   -h, --help, --version   Display this help and exit.
 
 Examples:
 
@@ -117,7 +122,10 @@ Examples:
# View summary report.
$0 --input-raw scan.out --squash-by-filename
 
-Scans the running (64 bit) kernel for potential leaking addresses.
+   # Scan kernel on a 32-bit system with a 2GB:2GB virtual address split.
+   $0 --page-offset-32bit=0x8000
+
+Scans the running kernel for potential leaking addresses.
 
 EOM
exit($exitcode);
@@ -133,6 +141,8 @@ GetOptions(
'squash-by-path'=> \$squash_by_path,
'squash-by-filename'=> \$squash_by_filename,
'raw'   => \$raw,
+   'page-offset-32bit=o'   => \$page_offset_32bit,
+   'kernel-config-file=s'  => \$kernel_config_file,
 ) or help(1);
 
 help(0) if ($help);
@@ -148,6 +158,7 @@ if (!$input_raw and ($squash_by_path or 
$squash_by_filename)) {
exit(128);
 }
 
+show_detected_architecture() if $debug;
 if (!is_supported_architecture()) 

Re: [PATCH 4.14 00/95] 4.14.4-stable review

[Greg Kroah-Hartman]

On Mon, Dec 04, 2017 at 01:29:42PM -0700, Shuah Khan wrote:
> On 12/04/2017 08:59 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.4 release.
> > There are 95 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Dec  6 16:00:27 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.14.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Great, thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH 4.14 00/95] 4.14.4-stable review

[Greg Kroah-Hartman]

On Mon, Dec 04, 2017 at 01:29:42PM -0700, Shuah Khan wrote:
> On 12/04/2017 08:59 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.4 release.
> > There are 95 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Dec  6 16:00:27 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz
> > or in the git tree and branch at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.14.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Great, thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH 4.14 00/95] 4.14.4-stable review

[Greg Kroah-Hartman]

On Mon, Dec 04, 2017 at 03:46:31PM -0800, Guenter Roeck wrote:
> On Mon, Dec 04, 2017 at 04:59:24PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.4 release.
> > There are 95 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Dec  6 16:00:27 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 145 pass: 145 fail: 0
> Qemu test results:
>   total: 123 pass: 123 fail: 0
> 
> Details are available at http://kerneltests.org/builders.

Great, thanks for testing all of these and letting me know.

greg k-h

[PATCH v3 08/14] nubus: Clean up whitespace

[Finn Thain]

Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
 include/linux/nubus.h | 54 +--
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/include/linux/nubus.h b/include/linux/nubus.h
index 46e4d983feac..84f2e0fa1898 100644
--- a/include/linux/nubus.h
+++ b/include/linux/nubus.h
@@ -28,9 +28,9 @@ struct nubus_dirent {
 };
 
 struct nubus_board {
-   struct nubus_board* next;
-   struct nubus_dev* first_dev;
-   
+   struct nubus_board *next;
+   struct nubus_dev *first_dev;
+
/* Only 9-E actually exist, though 0-8 are also theoretically
   possible, and 0 is a special case which represents the
   motherboard and onboard peripherals (Ethernet, video) */
@@ -39,10 +39,10 @@ struct nubus_board {
char name[64];
 
/* Format block */
-   unsigned char* fblock;
+   unsigned char *fblock;
/* Root directory (does *not* always equal fblock + doffset!) */
-   unsigned char* directory;
-   
+   unsigned char *directory;
+
unsigned long slot_addr;
/* Offset to root directory (sometimes) */
unsigned long doffset;
@@ -60,7 +60,7 @@ struct nubus_board {
 
 struct nubus_dev {
/* Next link in device list */
-   struct nubus_dev* next;
+   struct nubus_dev *next;
 
/* The functional resource ID of this device */
unsigned char resid;
@@ -70,17 +70,17 @@ struct nubus_dev {
unsigned short type;
unsigned short dr_sw;
unsigned short dr_hw;
-   
+
/* Functional directory */
-   unsigned char* directory;
+   unsigned char *directory;
/* Much of our info comes from here */
-   struct nubus_board* board;
+   struct nubus_board *board;
 };
 
 /* This is all NuBus devices (used to find devices later on) */
-extern struct nubus_dev* nubus_devices;
+extern struct nubus_dev *nubus_devices;
 /* This is all NuBus cards */
-extern struct nubus_board* nubus_boards;
+extern struct nubus_board *nubus_boards;
 
 /* Generic NuBus interface functions, modelled after the PCI interface */
 #ifdef CONFIG_PROC_FS
@@ -91,38 +91,38 @@ static inline void nubus_proc_init(void) {}
 
 int nubus_proc_attach_device(struct nubus_dev *dev);
 /* If we need more precision we can add some more of these */
-struct nubus_dev* nubus_find_type(unsigned short category,
+struct nubus_dev *nubus_find_type(unsigned short category,
  unsigned short type,
- const struct nubus_dev* from);
+ const struct nubus_dev *from);
 /* Might have more than one device in a slot, you know... */
-struct nubus_dev* nubus_find_slot(unsigned int slot,
- const struct nubus_dev* from);
+struct nubus_dev *nubus_find_slot(unsigned int slot,
+ const struct nubus_dev *from);
 
 /* These are somewhat more NuBus-specific.  They all return 0 for
success and -1 for failure, as you'd expect. */
 
 /* The root directory which contains the board and functional
directories */
-int nubus_get_root_dir(const struct nubus_board* board,
-  struct nubus_dir* dir);
+int nubus_get_root_dir(const struct nubus_board *board,
+  struct nubus_dir *dir);
 /* The board directory */
 int nubus_get_board_dir(const struct nubus_board* board,
struct nubus_dir* dir);
 /* The functional directory */
-int nubus_get_func_dir(const struct nubus_dev* dev,
-  struct nubus_dir* dir);
+int nubus_get_func_dir(const struct nubus_dev *dev,
+  struct nubus_dir *dir);
 
 /* These work on any directory gotten via the above */
-int nubus_readdir(struct nubus_dir* dir,
- struct nubus_dirent* ent);
-int nubus_find_rsrc(struct nubus_dir* dir,
+int nubus_readdir(struct nubus_dir *dir,
+ struct nubus_dirent *ent);
+int nubus_find_rsrc(struct nubus_dir *dir,
unsigned char rsrc_type,
-   struct nubus_dirent* ent);
-int nubus_rewinddir(struct nubus_dir* dir);
+   struct nubus_dirent *ent);
+int nubus_rewinddir(struct nubus_dir *dir);
 
 /* Things to do with directory entries */
-int nubus_get_subdir(const struct nubus_dirent* ent,
-struct nubus_dir* dir);
+int nubus_get_subdir(const struct nubus_dirent *ent,
+struct nubus_dir *dir);
 void nubus_get_rsrc_mem(void *dest, const struct nubus_dirent *dirent,
 unsigned int len);
 void nubus_get_rsrc_str(char *dest, const struct nubus_dirent *dirent,
-- 
2.13.6

Re: [PATCH 4.14 00/95] 4.14.4-stable review

[Greg Kroah-Hartman]

On Mon, Dec 04, 2017 at 03:46:31PM -0800, Guenter Roeck wrote:
> On Mon, Dec 04, 2017 at 04:59:24PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.4 release.
> > There are 95 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Dec  6 16:00:27 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 145 pass: 145 fail: 0
> Qemu test results:
>   total: 123 pass: 123 fail: 0
> 
> Details are available at http://kerneltests.org/builders.

Great, thanks for testing all of these and letting me know.

greg k-h

[PATCH v3 08/14] nubus: Clean up whitespace

[Finn Thain]

Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
 include/linux/nubus.h | 54 +--
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/include/linux/nubus.h b/include/linux/nubus.h
index 46e4d983feac..84f2e0fa1898 100644
--- a/include/linux/nubus.h
+++ b/include/linux/nubus.h
@@ -28,9 +28,9 @@ struct nubus_dirent {
 };
 
 struct nubus_board {
-   struct nubus_board* next;
-   struct nubus_dev* first_dev;
-   
+   struct nubus_board *next;
+   struct nubus_dev *first_dev;
+
/* Only 9-E actually exist, though 0-8 are also theoretically
   possible, and 0 is a special case which represents the
   motherboard and onboard peripherals (Ethernet, video) */
@@ -39,10 +39,10 @@ struct nubus_board {
char name[64];
 
/* Format block */
-   unsigned char* fblock;
+   unsigned char *fblock;
/* Root directory (does *not* always equal fblock + doffset!) */
-   unsigned char* directory;
-   
+   unsigned char *directory;
+
unsigned long slot_addr;
/* Offset to root directory (sometimes) */
unsigned long doffset;
@@ -60,7 +60,7 @@ struct nubus_board {
 
 struct nubus_dev {
/* Next link in device list */
-   struct nubus_dev* next;
+   struct nubus_dev *next;
 
/* The functional resource ID of this device */
unsigned char resid;
@@ -70,17 +70,17 @@ struct nubus_dev {
unsigned short type;
unsigned short dr_sw;
unsigned short dr_hw;
-   
+
/* Functional directory */
-   unsigned char* directory;
+   unsigned char *directory;
/* Much of our info comes from here */
-   struct nubus_board* board;
+   struct nubus_board *board;
 };
 
 /* This is all NuBus devices (used to find devices later on) */
-extern struct nubus_dev* nubus_devices;
+extern struct nubus_dev *nubus_devices;
 /* This is all NuBus cards */
-extern struct nubus_board* nubus_boards;
+extern struct nubus_board *nubus_boards;
 
 /* Generic NuBus interface functions, modelled after the PCI interface */
 #ifdef CONFIG_PROC_FS
@@ -91,38 +91,38 @@ static inline void nubus_proc_init(void) {}
 
 int nubus_proc_attach_device(struct nubus_dev *dev);
 /* If we need more precision we can add some more of these */
-struct nubus_dev* nubus_find_type(unsigned short category,
+struct nubus_dev *nubus_find_type(unsigned short category,
  unsigned short type,
- const struct nubus_dev* from);
+ const struct nubus_dev *from);
 /* Might have more than one device in a slot, you know... */
-struct nubus_dev* nubus_find_slot(unsigned int slot,
- const struct nubus_dev* from);
+struct nubus_dev *nubus_find_slot(unsigned int slot,
+ const struct nubus_dev *from);
 
 /* These are somewhat more NuBus-specific.  They all return 0 for
success and -1 for failure, as you'd expect. */
 
 /* The root directory which contains the board and functional
directories */
-int nubus_get_root_dir(const struct nubus_board* board,
-  struct nubus_dir* dir);
+int nubus_get_root_dir(const struct nubus_board *board,
+  struct nubus_dir *dir);
 /* The board directory */
 int nubus_get_board_dir(const struct nubus_board* board,
struct nubus_dir* dir);
 /* The functional directory */
-int nubus_get_func_dir(const struct nubus_dev* dev,
-  struct nubus_dir* dir);
+int nubus_get_func_dir(const struct nubus_dev *dev,
+  struct nubus_dir *dir);
 
 /* These work on any directory gotten via the above */
-int nubus_readdir(struct nubus_dir* dir,
- struct nubus_dirent* ent);
-int nubus_find_rsrc(struct nubus_dir* dir,
+int nubus_readdir(struct nubus_dir *dir,
+ struct nubus_dirent *ent);
+int nubus_find_rsrc(struct nubus_dir *dir,
unsigned char rsrc_type,
-   struct nubus_dirent* ent);
-int nubus_rewinddir(struct nubus_dir* dir);
+   struct nubus_dirent *ent);
+int nubus_rewinddir(struct nubus_dir *dir);
 
 /* Things to do with directory entries */
-int nubus_get_subdir(const struct nubus_dirent* ent,
-struct nubus_dir* dir);
+int nubus_get_subdir(const struct nubus_dirent *ent,
+struct nubus_dir *dir);
 void nubus_get_rsrc_mem(void *dest, const struct nubus_dirent *dirent,
 unsigned int len);
 void nubus_get_rsrc_str(char *dest, const struct nubus_dirent *dirent,
-- 
2.13.6

Re: [PATCH 4.14 00/95] 4.14.4-stable review

[Greg Kroah-Hartman]

On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
> 
> 
> > On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman  
> > wrote:
> > 
> > This is the start of the stable review cycle for the 4.14.4 release.
> > There are 95 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Dec  6 16:00:27 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz
> > or in the git tree and branch at:
> >  git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.14.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled, booted and ran the following package unit tests without regressions 
> on x86_64
> 
> boringssl : 
>go test target:0/0/5764/5764/5764 PASS
>ssl_test : 10 pass
>crypto_test : 28 pass
> e2fsprogs:
>make check : 340 pass
> sqlite
>make test : 143914 pass
> drm
>make check : 15 pass
>modetest, drmdevice : pass
> alsa-lib
>make check : 2 pass
> bluez
>make check : 25 pass
> libusb
>stress : 4 pass

How do the above tests stress the kernel?  Aren't they just
verifications that the source code in the package is correct?

I guess it proves something, but have you ever seen the above regress in
_any_ kernel release?

I know the drm developers have a huge test suite that they use to verify
their kernel changes, why not use that?

thanks,

greg k-h

Re: [PATCH 4.14 00/95] 4.14.4-stable review

[Greg Kroah-Hartman]

On Mon, Dec 04, 2017 at 03:12:45PM -0600, Tom Gall wrote:
> 
> 
> > On Dec 4, 2017, at 9:59 AM, Greg Kroah-Hartman  
> > wrote:
> > 
> > This is the start of the stable review cycle for the 4.14.4 release.
> > There are 95 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Dec  6 16:00:27 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.4-rc1.gz
> > or in the git tree and branch at:
> >  git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.14.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled, booted and ran the following package unit tests without regressions 
> on x86_64
> 
> boringssl : 
>go test target:0/0/5764/5764/5764 PASS
>ssl_test : 10 pass
>crypto_test : 28 pass
> e2fsprogs:
>make check : 340 pass
> sqlite
>make test : 143914 pass
> drm
>make check : 15 pass
>modetest, drmdevice : pass
> alsa-lib
>make check : 2 pass
> bluez
>make check : 25 pass
> libusb
>stress : 4 pass

How do the above tests stress the kernel?  Aren't they just
verifications that the source code in the package is correct?

I guess it proves something, but have you ever seen the above regress in
_any_ kernel release?

I know the drm developers have a huge test suite that they use to verify
their kernel changes, why not use that?

thanks,

greg k-h

[PATCH v3 04/14] nubus: Fix log spam

[Finn Thain]

Testing shows that a single Radius PrecisionColor 24X display board,
which has 95 functional resources, produces over a thousand lines of
log messages. Suppress these messages with pr_debug().
Remove some redundant messages relating to nubus_get_subdir() calls.
Fix the format block debug messages as the sequence of entries is
backwards (my bad).
Move the "scanning slots" message to its proper location.

Fixes: 71ae40e4cf33 ("nubus: Clean up printk calls")
Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
 drivers/nubus/nubus.c | 128 ++
 1 file changed, 55 insertions(+), 73 deletions(-)

diff --git a/drivers/nubus/nubus.c b/drivers/nubus/nubus.c
index 3c1d386a4640..2475b48c29d4 100644
--- a/drivers/nubus/nubus.c
+++ b/drivers/nubus/nubus.c
@@ -353,15 +353,15 @@ static int __init nubus_show_display_resource(struct 
nubus_dev *dev,
 {
switch (ent->type) {
case NUBUS_RESID_GAMMADIR:
-   pr_info("gamma directory offset: 0x%06x\n", ent->data);
+   pr_debug("gamma directory offset: 0x%06x\n", ent->data);
break;
case 0x0080 ... 0x0085:
-   pr_info("mode %02X info offset: 0x%06x\n",
-  ent->type, ent->data);
+   pr_debug("mode 0x%02x info offset: 0x%06x\n",
+   ent->type, ent->data);
break;
default:
-   pr_info("unknown resource %02X, data 0x%06x\n",
-  ent->type, ent->data);
+   pr_debug("unknown resource 0x%02x, data 0x%06x\n",
+   ent->type, ent->data);
}
return 0;
 }
@@ -375,12 +375,12 @@ static int __init nubus_show_network_resource(struct 
nubus_dev *dev,
char addr[6];
 
nubus_get_rsrc_mem(addr, ent, 6);
-   pr_info("MAC address: %pM\n", addr);
+   pr_debug("MAC address: %pM\n", addr);
break;
}
default:
-   pr_info("unknown resource %02X, data 0x%06x\n",
-  ent->type, ent->data);
+   pr_debug("unknown resource 0x%02x, data 0x%06x\n",
+   ent->type, ent->data);
}
return 0;
 }
@@ -394,8 +394,8 @@ static int __init nubus_show_cpu_resource(struct nubus_dev 
*dev,
unsigned long meminfo[2];
 
nubus_get_rsrc_mem(, ent, 8);
-   pr_info("memory: [ 0x%08lx 0x%08lx ]\n",
-  meminfo[0], meminfo[1]);
+   pr_debug("memory: [ 0x%08lx 0x%08lx ]\n",
+   meminfo[0], meminfo[1]);
break;
}
case NUBUS_RESID_ROMINFO:
@@ -403,13 +403,13 @@ static int __init nubus_show_cpu_resource(struct 
nubus_dev *dev,
unsigned long rominfo[2];
 
nubus_get_rsrc_mem(, ent, 8);
-   pr_info("ROM:[ 0x%08lx 0x%08lx ]\n",
-  rominfo[0], rominfo[1]);
+   pr_debug("ROM:[ 0x%08lx 0x%08lx ]\n",
+   rominfo[0], rominfo[1]);
break;
}
default:
-   pr_info("unknown resource %02X, data 0x%06x\n",
-  ent->type, ent->data);
+   pr_debug("unknown resource 0x%02x, data 0x%06x\n",
+   ent->type, ent->data);
}
return 0;
 }
@@ -428,8 +428,8 @@ static int __init nubus_show_private_resource(struct 
nubus_dev *dev,
nubus_show_cpu_resource(dev, ent);
break;
default:
-   pr_info("unknown resource %02X, data 0x%06x\n",
-  ent->type, ent->data);
+   pr_debug("unknown resource 0x%02x, data 0x%06x\n",
+   ent->type, ent->data);
}
return 0;
 }
@@ -442,12 +442,9 @@ nubus_get_functional_resource(struct nubus_board *board, 
int slot,
struct nubus_dirent ent;
struct nubus_dev *dev;
 
-   pr_info("  Function 0x%02x:\n", parent->type);
+   pr_debug("  Functional resource 0x%02x:\n", parent->type);
nubus_get_subdir(parent, );
 
-   pr_debug("%s: parent is 0x%p, dir is 0x%p\n",
-__func__, parent->base, dir.base);
-
/* Actually we should probably panic if this fails */
if ((dev = kzalloc(sizeof(*dev), GFP_ATOMIC)) == NULL)
return NULL;
@@ -466,14 +463,14 @@ nubus_get_functional_resource(struct nubus_board *board, 
int slot,
dev->type = nbtdata[1];
dev->dr_sw= nbtdata[2];
dev->dr_hw= nbtdata[3];
-   pr_info("type: [cat 0x%x type 0x%x sw 0x%x hw 
0x%x]\n",
-   nbtdata[0], nbtdata[1], nbtdata[2], nbtdata[3]);
+   pr_debug("type: 

[PATCH v3 04/14] nubus: Fix log spam

[Finn Thain]

Testing shows that a single Radius PrecisionColor 24X display board,
which has 95 functional resources, produces over a thousand lines of
log messages. Suppress these messages with pr_debug().
Remove some redundant messages relating to nubus_get_subdir() calls.
Fix the format block debug messages as the sequence of entries is
backwards (my bad).
Move the "scanning slots" message to its proper location.

Fixes: 71ae40e4cf33 ("nubus: Clean up printk calls")
Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
 drivers/nubus/nubus.c | 128 ++
 1 file changed, 55 insertions(+), 73 deletions(-)

diff --git a/drivers/nubus/nubus.c b/drivers/nubus/nubus.c
index 3c1d386a4640..2475b48c29d4 100644
--- a/drivers/nubus/nubus.c
+++ b/drivers/nubus/nubus.c
@@ -353,15 +353,15 @@ static int __init nubus_show_display_resource(struct 
nubus_dev *dev,
 {
switch (ent->type) {
case NUBUS_RESID_GAMMADIR:
-   pr_info("gamma directory offset: 0x%06x\n", ent->data);
+   pr_debug("gamma directory offset: 0x%06x\n", ent->data);
break;
case 0x0080 ... 0x0085:
-   pr_info("mode %02X info offset: 0x%06x\n",
-  ent->type, ent->data);
+   pr_debug("mode 0x%02x info offset: 0x%06x\n",
+   ent->type, ent->data);
break;
default:
-   pr_info("unknown resource %02X, data 0x%06x\n",
-  ent->type, ent->data);
+   pr_debug("unknown resource 0x%02x, data 0x%06x\n",
+   ent->type, ent->data);
}
return 0;
 }
@@ -375,12 +375,12 @@ static int __init nubus_show_network_resource(struct 
nubus_dev *dev,
char addr[6];
 
nubus_get_rsrc_mem(addr, ent, 6);
-   pr_info("MAC address: %pM\n", addr);
+   pr_debug("MAC address: %pM\n", addr);
break;
}
default:
-   pr_info("unknown resource %02X, data 0x%06x\n",
-  ent->type, ent->data);
+   pr_debug("unknown resource 0x%02x, data 0x%06x\n",
+   ent->type, ent->data);
}
return 0;
 }
@@ -394,8 +394,8 @@ static int __init nubus_show_cpu_resource(struct nubus_dev 
*dev,
unsigned long meminfo[2];
 
nubus_get_rsrc_mem(, ent, 8);
-   pr_info("memory: [ 0x%08lx 0x%08lx ]\n",
-  meminfo[0], meminfo[1]);
+   pr_debug("memory: [ 0x%08lx 0x%08lx ]\n",
+   meminfo[0], meminfo[1]);
break;
}
case NUBUS_RESID_ROMINFO:
@@ -403,13 +403,13 @@ static int __init nubus_show_cpu_resource(struct 
nubus_dev *dev,
unsigned long rominfo[2];
 
nubus_get_rsrc_mem(, ent, 8);
-   pr_info("ROM:[ 0x%08lx 0x%08lx ]\n",
-  rominfo[0], rominfo[1]);
+   pr_debug("ROM:[ 0x%08lx 0x%08lx ]\n",
+   rominfo[0], rominfo[1]);
break;
}
default:
-   pr_info("unknown resource %02X, data 0x%06x\n",
-  ent->type, ent->data);
+   pr_debug("unknown resource 0x%02x, data 0x%06x\n",
+   ent->type, ent->data);
}
return 0;
 }
@@ -428,8 +428,8 @@ static int __init nubus_show_private_resource(struct 
nubus_dev *dev,
nubus_show_cpu_resource(dev, ent);
break;
default:
-   pr_info("unknown resource %02X, data 0x%06x\n",
-  ent->type, ent->data);
+   pr_debug("unknown resource 0x%02x, data 0x%06x\n",
+   ent->type, ent->data);
}
return 0;
 }
@@ -442,12 +442,9 @@ nubus_get_functional_resource(struct nubus_board *board, 
int slot,
struct nubus_dirent ent;
struct nubus_dev *dev;
 
-   pr_info("  Function 0x%02x:\n", parent->type);
+   pr_debug("  Functional resource 0x%02x:\n", parent->type);
nubus_get_subdir(parent, );
 
-   pr_debug("%s: parent is 0x%p, dir is 0x%p\n",
-__func__, parent->base, dir.base);
-
/* Actually we should probably panic if this fails */
if ((dev = kzalloc(sizeof(*dev), GFP_ATOMIC)) == NULL)
return NULL;
@@ -466,14 +463,14 @@ nubus_get_functional_resource(struct nubus_board *board, 
int slot,
dev->type = nbtdata[1];
dev->dr_sw= nbtdata[2];
dev->dr_hw= nbtdata[3];
-   pr_info("type: [cat 0x%x type 0x%x sw 0x%x hw 
0x%x]\n",
-   nbtdata[0], nbtdata[1], nbtdata[2], nbtdata[3]);
+   pr_debug("type: [cat 0x%x type 0x%x sw 0x%x hw 
0x%x]\n",
+

[PATCH v3 09/14] nubus: Generalize block resource handling

[Finn Thain]

Scrap the specialized code to unpack video mode name resources and
driver resources. It isn't useful.
Instead, add a re-usable function to handle lists of block resources of
any kind, and descend into the video mode table resource directory.
Rename callers as nubus_get_foo(), consistent with their purpose and
with related functions in the same file.

Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
 drivers/nubus/nubus.c | 123 ++
 1 file changed, 65 insertions(+), 58 deletions(-)

diff --git a/drivers/nubus/nubus.c b/drivers/nubus/nubus.c
index 041c2be7407f..a7b480534a17 100644
--- a/drivers/nubus/nubus.c
+++ b/drivers/nubus/nubus.c
@@ -331,16 +331,63 @@ EXPORT_SYMBOL(nubus_find_rsrc);
among other things.  The rest of it should go in the /proc code.
For now, we just use it to give verbose boot logs. */
 
-static int __init nubus_show_display_resource(struct nubus_dev *dev,
- const struct nubus_dirent *ent)
+static int __init nubus_get_block_rsrc_dir(struct nubus_board *board,
+   const struct nubus_dirent *parent)
+{
+   struct nubus_dir dir;
+   struct nubus_dirent ent;
+
+   nubus_get_subdir(parent, );
+
+   while (nubus_readdir(, ) != -1) {
+   u32 size;
+
+   nubus_get_rsrc_mem(, , 4);
+   pr_debug("block (0x%x), size %d\n", ent.type, size);
+   }
+   return 0;
+}
+
+static int __init nubus_get_display_vidmode(struct nubus_board *board,
+const struct nubus_dirent *parent)
+{
+   struct nubus_dir dir;
+   struct nubus_dirent ent;
+
+   nubus_get_subdir(parent, );
+
+   while (nubus_readdir(, ) != -1) {
+   switch (ent.type) {
+   case 1: /* mVidParams */
+   case 2: /* mTable */
+   {
+   u32 size;
+
+   nubus_get_rsrc_mem(, , 4);
+   pr_debug("block (0x%x), size %d\n", ent.type,
+   size);
+   break;
+   }
+   default:
+   pr_debug("unknown resource 0x%02x, data 
0x%06x\n",
+   ent.type, ent.data);
+   }
+   }
+   return 0;
+}
+
+static int __init nubus_get_display_resource(struct nubus_dev *dev,
+ const struct nubus_dirent *ent)
 {
switch (ent->type) {
case NUBUS_RESID_GAMMADIR:
pr_debug("gamma directory offset: 0x%06x\n", ent->data);
+   nubus_get_block_rsrc_dir(dev->board, ent);
break;
case 0x0080 ... 0x0085:
pr_debug("mode 0x%02x info offset: 0x%06x\n",
ent->type, ent->data);
+   nubus_get_display_vidmode(dev->board, ent);
break;
default:
pr_debug("unknown resource 0x%02x, data 0x%06x\n",
@@ -349,8 +396,8 @@ static int __init nubus_show_display_resource(struct 
nubus_dev *dev,
return 0;
 }
 
-static int __init nubus_show_network_resource(struct nubus_dev *dev,
- const struct nubus_dirent *ent)
+static int __init nubus_get_network_resource(struct nubus_dev *dev,
+ const struct nubus_dirent *ent)
 {
switch (ent->type) {
case NUBUS_RESID_MAC_ADDRESS:
@@ -368,8 +415,8 @@ static int __init nubus_show_network_resource(struct 
nubus_dev *dev,
return 0;
 }
 
-static int __init nubus_show_cpu_resource(struct nubus_dev *dev,
- const struct nubus_dirent *ent)
+static int __init nubus_get_cpu_resource(struct nubus_dev *dev,
+ const struct nubus_dirent *ent)
 {
switch (ent->type) {
case NUBUS_RESID_MEMINFO:
@@ -397,18 +444,18 @@ static int __init nubus_show_cpu_resource(struct 
nubus_dev *dev,
return 0;
 }
 
-static int __init nubus_show_private_resource(struct nubus_dev *dev,
- const struct nubus_dirent *ent)
+static int __init nubus_get_private_resource(struct nubus_dev *dev,
+ const struct nubus_dirent *ent)
 {
switch (dev->category) {
case NUBUS_CAT_DISPLAY:
-   nubus_show_display_resource(dev, ent);
+   nubus_get_display_resource(dev, ent);
break;
case NUBUS_CAT_NETWORK:
-   nubus_show_network_resource(dev, ent);
+   nubus_get_network_resource(dev, ent);
break;
case NUBUS_CAT_CPU:
-   nubus_show_cpu_resource(dev, ent);
+   nubus_get_cpu_resource(dev, ent);
break;
 

[PATCH v3 10/14] nubus: Rework /proc/bus/nubus/s/ implementation

[Finn Thain]

The /proc/bus/nubus/s/ directory tree for any slot s is missing a lot
of information. The struct file_operations methods have long been left
unimplemented (hence the familiar compile-time warning, "Need to set
some I/O handlers here").

Slot resources have a complex structure which varies depending on board
function. The logic for interpreting these ROM data structures is found
in nubus.c. Let's not duplicate that logic in proc.c.

Create the /proc/bus/nubus/s/ inodes while scanning slot s. During
descent through slot resource subdirectories, call the new
nubus_proc_add_foo() functions to create the procfs inodes.

Also add a new function, nubus_seq_write_rsrc_mem(), to write the
contents of a particular slot resource to a given seq_file. This is
used by the procfs file_operations methods, to finally give userspace
access to slot ROM information, such as the available video modes.

Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
 drivers/nubus/nubus.c | 118 --
 drivers/nubus/proc.c  | 223 ++
 include/linux/nubus.h |  37 -
 3 files changed, 259 insertions(+), 119 deletions(-)

diff --git a/drivers/nubus/nubus.c b/drivers/nubus/nubus.c
index a7b480534a17..b0d8aa721173 100644
--- a/drivers/nubus/nubus.c
+++ b/drivers/nubus/nubus.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -146,7 +147,7 @@ static inline void *nubus_rom_addr(int slot)
return (void *)(0xF100 + (slot << 24));
 }
 
-static unsigned char *nubus_dirptr(const struct nubus_dirent *nd)
+unsigned char *nubus_dirptr(const struct nubus_dirent *nd)
 {
unsigned char *p = nd->base;
 
@@ -173,8 +174,8 @@ void nubus_get_rsrc_mem(void *dest, const struct 
nubus_dirent *dirent,
 }
 EXPORT_SYMBOL(nubus_get_rsrc_mem);
 
-void nubus_get_rsrc_str(char *dest, const struct nubus_dirent *dirent,
-unsigned int len)
+unsigned int nubus_get_rsrc_str(char *dest, const struct nubus_dirent *dirent,
+unsigned int len)
 {
char *t = dest;
unsigned char *p = nubus_dirptr(dirent);
@@ -189,9 +190,33 @@ void nubus_get_rsrc_str(char *dest, const struct 
nubus_dirent *dirent,
}
if (len > 0)
*t = '\0';
+   return t - dest;
 }
 EXPORT_SYMBOL(nubus_get_rsrc_str);
 
+void nubus_seq_write_rsrc_mem(struct seq_file *m,
+  const struct nubus_dirent *dirent,
+  unsigned int len)
+{
+   unsigned long buf[32];
+   unsigned int buf_size = sizeof(buf);
+   unsigned char *p = nubus_dirptr(dirent);
+
+   /* If possible, write out full buffers */
+   while (len >= buf_size) {
+   unsigned int i;
+
+   for (i = 0; i < ARRAY_SIZE(buf); i++)
+   buf[i] = nubus_get_rom(, sizeof(buf[0]),
+  dirent->mask);
+   seq_write(m, buf, buf_size);
+   len -= buf_size;
+   }
+   /* If not, write out individual bytes */
+   while (len--)
+   seq_putc(m, nubus_get_rom(, 1, dirent->mask));
+}
+
 int nubus_get_root_dir(const struct nubus_board *board,
   struct nubus_dir *dir)
 {
@@ -326,35 +351,35 @@ EXPORT_SYMBOL(nubus_find_rsrc);
looking at, and print out lots and lots of information from the
resource blocks. */
 
-/* FIXME: A lot of this stuff will eventually be useful after
-   initialization, for intelligently probing Ethernet and video chips,
-   among other things.  The rest of it should go in the /proc code.
-   For now, we just use it to give verbose boot logs. */
-
 static int __init nubus_get_block_rsrc_dir(struct nubus_board *board,
+   struct proc_dir_entry *procdir,
const struct nubus_dirent *parent)
 {
struct nubus_dir dir;
struct nubus_dirent ent;
 
nubus_get_subdir(parent, );
+   dir.procdir = nubus_proc_add_rsrc_dir(procdir, parent, board);
 
while (nubus_readdir(, ) != -1) {
u32 size;
 
nubus_get_rsrc_mem(, , 4);
pr_debug("block (0x%x), size %d\n", ent.type, size);
+   nubus_proc_add_rsrc_mem(dir.procdir, , size);
}
return 0;
 }
 
 static int __init nubus_get_display_vidmode(struct nubus_board *board,
+struct proc_dir_entry *procdir,
 const struct nubus_dirent *parent)
 {
struct nubus_dir dir;
struct nubus_dirent ent;
 
nubus_get_subdir(parent, );
+   dir.procdir = nubus_proc_add_rsrc_dir(procdir, parent, board);
 
while (nubus_readdir(, ) != -1) {
switch (ent.type) {
@@ -366,37 +391,42 @@ static int __init 

[PATCH v3 09/14] nubus: Generalize block resource handling

[Finn Thain]

Scrap the specialized code to unpack video mode name resources and
driver resources. It isn't useful.
Instead, add a re-usable function to handle lists of block resources of
any kind, and descend into the video mode table resource directory.
Rename callers as nubus_get_foo(), consistent with their purpose and
with related functions in the same file.

Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
 drivers/nubus/nubus.c | 123 ++
 1 file changed, 65 insertions(+), 58 deletions(-)

diff --git a/drivers/nubus/nubus.c b/drivers/nubus/nubus.c
index 041c2be7407f..a7b480534a17 100644
--- a/drivers/nubus/nubus.c
+++ b/drivers/nubus/nubus.c
@@ -331,16 +331,63 @@ EXPORT_SYMBOL(nubus_find_rsrc);
among other things.  The rest of it should go in the /proc code.
For now, we just use it to give verbose boot logs. */
 
-static int __init nubus_show_display_resource(struct nubus_dev *dev,
- const struct nubus_dirent *ent)
+static int __init nubus_get_block_rsrc_dir(struct nubus_board *board,
+   const struct nubus_dirent *parent)
+{
+   struct nubus_dir dir;
+   struct nubus_dirent ent;
+
+   nubus_get_subdir(parent, );
+
+   while (nubus_readdir(, ) != -1) {
+   u32 size;
+
+   nubus_get_rsrc_mem(, , 4);
+   pr_debug("block (0x%x), size %d\n", ent.type, size);
+   }
+   return 0;
+}
+
+static int __init nubus_get_display_vidmode(struct nubus_board *board,
+const struct nubus_dirent *parent)
+{
+   struct nubus_dir dir;
+   struct nubus_dirent ent;
+
+   nubus_get_subdir(parent, );
+
+   while (nubus_readdir(, ) != -1) {
+   switch (ent.type) {
+   case 1: /* mVidParams */
+   case 2: /* mTable */
+   {
+   u32 size;
+
+   nubus_get_rsrc_mem(, , 4);
+   pr_debug("block (0x%x), size %d\n", ent.type,
+   size);
+   break;
+   }
+   default:
+   pr_debug("unknown resource 0x%02x, data 
0x%06x\n",
+   ent.type, ent.data);
+   }
+   }
+   return 0;
+}
+
+static int __init nubus_get_display_resource(struct nubus_dev *dev,
+ const struct nubus_dirent *ent)
 {
switch (ent->type) {
case NUBUS_RESID_GAMMADIR:
pr_debug("gamma directory offset: 0x%06x\n", ent->data);
+   nubus_get_block_rsrc_dir(dev->board, ent);
break;
case 0x0080 ... 0x0085:
pr_debug("mode 0x%02x info offset: 0x%06x\n",
ent->type, ent->data);
+   nubus_get_display_vidmode(dev->board, ent);
break;
default:
pr_debug("unknown resource 0x%02x, data 0x%06x\n",
@@ -349,8 +396,8 @@ static int __init nubus_show_display_resource(struct 
nubus_dev *dev,
return 0;
 }
 
-static int __init nubus_show_network_resource(struct nubus_dev *dev,
- const struct nubus_dirent *ent)
+static int __init nubus_get_network_resource(struct nubus_dev *dev,
+ const struct nubus_dirent *ent)
 {
switch (ent->type) {
case NUBUS_RESID_MAC_ADDRESS:
@@ -368,8 +415,8 @@ static int __init nubus_show_network_resource(struct 
nubus_dev *dev,
return 0;
 }
 
-static int __init nubus_show_cpu_resource(struct nubus_dev *dev,
- const struct nubus_dirent *ent)
+static int __init nubus_get_cpu_resource(struct nubus_dev *dev,
+ const struct nubus_dirent *ent)
 {
switch (ent->type) {
case NUBUS_RESID_MEMINFO:
@@ -397,18 +444,18 @@ static int __init nubus_show_cpu_resource(struct 
nubus_dev *dev,
return 0;
 }
 
-static int __init nubus_show_private_resource(struct nubus_dev *dev,
- const struct nubus_dirent *ent)
+static int __init nubus_get_private_resource(struct nubus_dev *dev,
+ const struct nubus_dirent *ent)
 {
switch (dev->category) {
case NUBUS_CAT_DISPLAY:
-   nubus_show_display_resource(dev, ent);
+   nubus_get_display_resource(dev, ent);
break;
case NUBUS_CAT_NETWORK:
-   nubus_show_network_resource(dev, ent);
+   nubus_get_network_resource(dev, ent);
break;
case NUBUS_CAT_CPU:
-   nubus_show_cpu_resource(dev, ent);
+   nubus_get_cpu_resource(dev, ent);
break;
default:
pr_debug("

[PATCH v3 10/14] nubus: Rework /proc/bus/nubus/s/ implementation

[Finn Thain]

The /proc/bus/nubus/s/ directory tree for any slot s is missing a lot
of information. The struct file_operations methods have long been left
unimplemented (hence the familiar compile-time warning, "Need to set
some I/O handlers here").

Slot resources have a complex structure which varies depending on board
function. The logic for interpreting these ROM data structures is found
in nubus.c. Let's not duplicate that logic in proc.c.

Create the /proc/bus/nubus/s/ inodes while scanning slot s. During
descent through slot resource subdirectories, call the new
nubus_proc_add_foo() functions to create the procfs inodes.

Also add a new function, nubus_seq_write_rsrc_mem(), to write the
contents of a particular slot resource to a given seq_file. This is
used by the procfs file_operations methods, to finally give userspace
access to slot ROM information, such as the available video modes.

Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
 drivers/nubus/nubus.c | 118 --
 drivers/nubus/proc.c  | 223 ++
 include/linux/nubus.h |  37 -
 3 files changed, 259 insertions(+), 119 deletions(-)

diff --git a/drivers/nubus/nubus.c b/drivers/nubus/nubus.c
index a7b480534a17..b0d8aa721173 100644
--- a/drivers/nubus/nubus.c
+++ b/drivers/nubus/nubus.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -146,7 +147,7 @@ static inline void *nubus_rom_addr(int slot)
return (void *)(0xF100 + (slot << 24));
 }
 
-static unsigned char *nubus_dirptr(const struct nubus_dirent *nd)
+unsigned char *nubus_dirptr(const struct nubus_dirent *nd)
 {
unsigned char *p = nd->base;
 
@@ -173,8 +174,8 @@ void nubus_get_rsrc_mem(void *dest, const struct 
nubus_dirent *dirent,
 }
 EXPORT_SYMBOL(nubus_get_rsrc_mem);
 
-void nubus_get_rsrc_str(char *dest, const struct nubus_dirent *dirent,
-unsigned int len)
+unsigned int nubus_get_rsrc_str(char *dest, const struct nubus_dirent *dirent,
+unsigned int len)
 {
char *t = dest;
unsigned char *p = nubus_dirptr(dirent);
@@ -189,9 +190,33 @@ void nubus_get_rsrc_str(char *dest, const struct 
nubus_dirent *dirent,
}
if (len > 0)
*t = '\0';
+   return t - dest;
 }
 EXPORT_SYMBOL(nubus_get_rsrc_str);
 
+void nubus_seq_write_rsrc_mem(struct seq_file *m,
+  const struct nubus_dirent *dirent,
+  unsigned int len)
+{
+   unsigned long buf[32];
+   unsigned int buf_size = sizeof(buf);
+   unsigned char *p = nubus_dirptr(dirent);
+
+   /* If possible, write out full buffers */
+   while (len >= buf_size) {
+   unsigned int i;
+
+   for (i = 0; i < ARRAY_SIZE(buf); i++)
+   buf[i] = nubus_get_rom(, sizeof(buf[0]),
+  dirent->mask);
+   seq_write(m, buf, buf_size);
+   len -= buf_size;
+   }
+   /* If not, write out individual bytes */
+   while (len--)
+   seq_putc(m, nubus_get_rom(, 1, dirent->mask));
+}
+
 int nubus_get_root_dir(const struct nubus_board *board,
   struct nubus_dir *dir)
 {
@@ -326,35 +351,35 @@ EXPORT_SYMBOL(nubus_find_rsrc);
looking at, and print out lots and lots of information from the
resource blocks. */
 
-/* FIXME: A lot of this stuff will eventually be useful after
-   initialization, for intelligently probing Ethernet and video chips,
-   among other things.  The rest of it should go in the /proc code.
-   For now, we just use it to give verbose boot logs. */
-
 static int __init nubus_get_block_rsrc_dir(struct nubus_board *board,
+   struct proc_dir_entry *procdir,
const struct nubus_dirent *parent)
 {
struct nubus_dir dir;
struct nubus_dirent ent;
 
nubus_get_subdir(parent, );
+   dir.procdir = nubus_proc_add_rsrc_dir(procdir, parent, board);
 
while (nubus_readdir(, ) != -1) {
u32 size;
 
nubus_get_rsrc_mem(, , 4);
pr_debug("block (0x%x), size %d\n", ent.type, size);
+   nubus_proc_add_rsrc_mem(dir.procdir, , size);
}
return 0;
 }
 
 static int __init nubus_get_display_vidmode(struct nubus_board *board,
+struct proc_dir_entry *procdir,
 const struct nubus_dirent *parent)
 {
struct nubus_dir dir;
struct nubus_dirent ent;
 
nubus_get_subdir(parent, );
+   dir.procdir = nubus_proc_add_rsrc_dir(procdir, parent, board);
 
while (nubus_readdir(, ) != -1) {
switch (ent.type) {
@@ -366,37 +391,42 @@ static int __init nubus_get_display_vidmode(struct 
nubus_board