2018-01-24 23:12 GMT+08:00 Vitaly Kuznetsov :
> I was investigating an issue with seabios >= 1.10 which stopped working
> for nested KVM on Hyper-V. The problem appears to be in
> handle_ept_violation() function: when we do fast mmio we need to skip
> the instruction so we do
2018-01-24 23:12 GMT+08:00 Vitaly Kuznetsov :
> I was investigating an issue with seabios >= 1.10 which stopped working
> for nested KVM on Hyper-V. The problem appears to be in
> handle_ept_violation() function: when we do fast mmio we need to skip
> the instruction so we do
On Wed, 2018-01-24 at 16:53 -0800, Dexuan-Linux Cui wrote:
> On Wed, Jan 10, 2018 at 2:53 PM, Woodhouse, David wrote:
> >
> > On Thu, 2018-01-11 at 01:34 +0300, Alexey Dobriyan wrote:
> > >
> > >
> > > Bisection points to
> > >
> > >
On Wed, 2018-01-24 at 16:53 -0800, Dexuan-Linux Cui wrote:
> On Wed, Jan 10, 2018 at 2:53 PM, Woodhouse, David wrote:
> >
> > On Thu, 2018-01-11 at 01:34 +0300, Alexey Dobriyan wrote:
> > >
> > >
> > > Bisection points to
> > >
> > > f3433c1010c6af61c9897f0f0447f81b991feac1 is the
On 24/01/18 21:14, Ralph Campbell wrote:
> 2 Minor typos inline below:
thanks for proof-reading, will fix accordingly.
--
igor
On 24/01/18 21:14, Ralph Campbell wrote:
> 2 Minor typos inline below:
thanks for proof-reading, will fix accordingly.
--
igor
On 2018/1/25 12:16, Al Viro wrote:
On Thu, Jan 25, 2018 at 11:13:56AM +0800, Jia-Ju Bai wrote:
I have checked the given call chain, and find that nvme_dev_disable in
nvme_timeout calls mutex_lock that can sleep.
Thus, I suppose this call chain is not in atomic context.
... or it is broken.
On 2018/1/25 12:16, Al Viro wrote:
On Thu, Jan 25, 2018 at 11:13:56AM +0800, Jia-Ju Bai wrote:
I have checked the given call chain, and find that nvme_dev_disable in
nvme_timeout calls mutex_lock that can sleep.
Thus, I suppose this call chain is not in atomic context.
... or it is broken.
On Thu, Jan 25, 2018 at 3:08 AM, Shakeel Butt wrote:
> On Wed, Jan 24, 2018 at 3:12 AM, Amir Goldstein wrote:
>> On Wed, Jan 24, 2018 at 12:34 PM, Jan Kara wrote:
>>> On Mon 22-01-18 22:31:20, Amir Goldstein wrote:
On Fri, Jan 19, 2018
On Thu, Jan 25, 2018 at 3:08 AM, Shakeel Butt wrote:
> On Wed, Jan 24, 2018 at 3:12 AM, Amir Goldstein wrote:
>> On Wed, Jan 24, 2018 at 12:34 PM, Jan Kara wrote:
>>> On Mon 22-01-18 22:31:20, Amir Goldstein wrote:
On Fri, Jan 19, 2018 at 5:02 PM, Shakeel Butt wrote:
> On Wed, Nov
On Fri, Jan 19, 2018 at 11:57:32AM +0100, Enric Balletbo Serra wrote:
> Hi Vito,
>
> 2018-01-17 23:48 GMT+01:00 :
> > On Mon, Dec 18, 2017 at 10:25:33AM +0100, Enric Balletbo Serra wrote:
> >> Hi Vito,
> >>
> >> 2017-12-01 22:33 GMT+01:00 :
> >> > On
On Fri, Jan 19, 2018 at 11:57:32AM +0100, Enric Balletbo Serra wrote:
> Hi Vito,
>
> 2018-01-17 23:48 GMT+01:00 :
> > On Mon, Dec 18, 2017 at 10:25:33AM +0100, Enric Balletbo Serra wrote:
> >> Hi Vito,
> >>
> >> 2017-12-01 22:33 GMT+01:00 :
> >> > On Wed, Nov 29, 2017 at 10:39:19AM -0800,
2018-01-24 23:12 GMT+01:00 Peter Rosin :
> Hi Bartosz,
>
> On 2018-01-24 22:34, Bartosz Golaszewski wrote:
>> We now require all at24 users to use the "atmel," fallback in
>> device tree for different manufacturers.
>
> I think my patch [3/4] from about a week ago was just a tiny
2018-01-24 23:12 GMT+01:00 Peter Rosin :
> Hi Bartosz,
>
> On 2018-01-24 22:34, Bartosz Golaszewski wrote:
>> We now require all at24 users to use the "atmel," fallback in
>> device tree for different manufacturers.
>
> I think my patch [3/4] from about a week ago was just a tiny bit
> better.
>
On Wed, Jan 24, 2018 at 07:07:56PM -0800, Palmer Dabbelt wrote:
> The old mechanism for handling IRQs on RISC-V was pretty ugly: the arch
> code looked at the Kconfig entry for our first-level irqchip driver and
> called into it directly.
>
> This patch uses the new 0generic IRQ handling
On Wed, Jan 24, 2018 at 07:07:56PM -0800, Palmer Dabbelt wrote:
> The old mechanism for handling IRQs on RISC-V was pretty ugly: the arch
> code looked at the Kconfig entry for our first-level irqchip driver and
> called into it directly.
>
> This patch uses the new 0generic IRQ handling
On Wed, Jan 24, 2018 at 07:07:53PM -0800, Palmer Dabbelt wrote:
> It looks like this same irqchip registration mechanism has been copied
> into a handful of ports, including aarch64 and openrisc. I want to use
> this in the RISC-V port, so I thought it would be good to make this
> generic
On Wed, Jan 24, 2018 at 07:07:53PM -0800, Palmer Dabbelt wrote:
> It looks like this same irqchip registration mechanism has been copied
> into a handful of ports, including aarch64 and openrisc. I want to use
> this in the RISC-V port, so I thought it would be good to make this
> generic
On Wed, Jan 24, 2018 at 07:07:55PM -0800, Palmer Dabbelt wrote:
> It appears that openrisc copied arm64's MULTI_IRQ_HANDLER code (which
> came from arm). I wanted to make this generic so I could use it in the
> RISC-V port. This patch converts the openrisc code to use the generic
> version.
On Wed, Jan 24, 2018 at 07:07:55PM -0800, Palmer Dabbelt wrote:
> It appears that openrisc copied arm64's MULTI_IRQ_HANDLER code (which
> came from arm). I wanted to make this generic so I could use it in the
> RISC-V port. This patch converts the openrisc code to use the generic
> version.
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
From: Akash Gajjar
Witth this changes, the driver builds with CONFIG_OF support
Signed-off-by: Akash Gajjar
---
drivers/media/i2c/as3645a.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/media/i2c/as3645a.c
From: Akash Gajjar
Witth this changes, the driver builds with CONFIG_OF support
Signed-off-by: Akash Gajjar
---
drivers/media/i2c/as3645a.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/media/i2c/as3645a.c b/drivers/media/i2c/as3645a.c
index af5db71..24233fa 100644
---
We try to allocate one more entry for lockless peeking. The adding
operation may overflow which causes zero to be passed to kmalloc().
In this case, it returns ZERO_SIZE_PTR without any notice by ptr
ring. Try to do producing or consuming on such ring will lead NULL
dereference. Fix this detect
We try to allocate one more entry for lockless peeking. The adding
operation may overflow which causes zero to be passed to kmalloc().
In this case, it returns ZERO_SIZE_PTR without any notice by ptr
ring. Try to do producing or consuming on such ring will lead NULL
dereference. Fix this detect
On Wed, Jan 24, 2018 at 10:16:18PM -0800, Paul E. McKenney wrote:
> On Tue, Jan 23, 2018 at 03:59:26PM +0800, liangli...@huawei.com wrote:
> > From: Heng Zhang
> >
> > This RCU implementation (PRCU) is based on a fast consensus protocol
> > published in the following paper:
>
On Wed, Jan 24, 2018 at 10:16:18PM -0800, Paul E. McKenney wrote:
> On Tue, Jan 23, 2018 at 03:59:26PM +0800, liangli...@huawei.com wrote:
> > From: Heng Zhang
> >
> > This RCU implementation (PRCU) is based on a fast consensus protocol
> > published in the following paper:
> >
> > Fast
When a page is freed back to the global pool, its buddy will be checked
to see if it's possible to do a merge. This requires accessing buddy's
page structure and that access could take a long time if it's cache cold.
This patch adds a prefetch to the to-be-freed page's buddy outside of
zone->lock
When a page is freed back to the global pool, its buddy will be checked
to see if it's possible to do a merge. This requires accessing buddy's
page structure and that access could take a long time if it's cache cold.
This patch adds a prefetch to the to-be-freed page's buddy outside of
zone->lock
Hi all,
After merging the rdma tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: "init_rcu_head" [drivers/infiniband/ulp/srpt/ib_srpt.ko] undefined!
Caused by commit
a11253142e6d ("IB/srpt: Rework multi-channel support")
I have used the rdma tree from
Hi all,
After merging the rdma tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: "init_rcu_head" [drivers/infiniband/ulp/srpt/ib_srpt.ko] undefined!
Caused by commit
a11253142e6d ("IB/srpt: Rework multi-channel support")
I have used the rdma tree from
When freeing a batch of pages from Per-CPU-Pages(PCP) back to buddy,
the zone->lock is held and then pages are chosen from PCP's migratetype
list. While there is actually no need to do this 'choose part' under
lock since it's PCP pages, the only CPU that can touch them is us and
irq is also
When freeing a batch of pages from Per-CPU-Pages(PCP) back to buddy,
the zone->lock is held and then pages are chosen from PCP's migratetype
list. While there is actually no need to do this 'choose part' under
lock since it's PCP pages, the only CPU that can touch them is us and
irq is also
On 1/18/2018 4:01 PM, Dan Williams wrote:
'array_ptr' is proposed as a generic mechanism to mitigate against
Spectre-variant-1 attacks, i.e. an attack that bypasses boundary checks
via speculative execution). The 'array_ptr' implementation is expected
to be safe for current generation cpus
On 1/18/2018 4:01 PM, Dan Williams wrote:
'array_ptr' is proposed as a generic mechanism to mitigate against
Spectre-variant-1 attacks, i.e. an attack that bypasses boundary checks
via speculative execution). The 'array_ptr' implementation is expected
to be safe for current generation cpus
On 01/24/18 22:48, Frank Rowand wrote:
> On 01/21/18 06:31, Wolfram Sang wrote:
>> From: Tyrel Datwyler
>>
>> This patch introduces event tracepoints for tracking a device_nodes
>> reference cycle as well as reconfig notifications generated in response
>> to
On 01/24/18 22:48, Frank Rowand wrote:
> On 01/21/18 06:31, Wolfram Sang wrote:
>> From: Tyrel Datwyler
>>
>> This patch introduces event tracepoints for tracking a device_nodes
>> reference cycle as well as reconfig notifications generated in response
>> to node/property manipulations.
>>
>>
The new /sys interface like this:
#cat /sys/devices/virtual/workqueue/writeback/sched_attr
policy=0 prio=0 nice=0
# echo "policy=0 prio=0 nice=-1" >
/sys/devices/virtual/workqueue/writeback/sched_attr
# cat /sys/devices/virtual/workqueue/writeback/sched_attr
The new /sys interface like this:
#cat /sys/devices/virtual/workqueue/writeback/sched_attr
policy=0 prio=0 nice=0
# echo "policy=0 prio=0 nice=-1" >
/sys/devices/virtual/workqueue/writeback/sched_attr
# cat /sys/devices/virtual/workqueue/writeback/sched_attr
When pinning RT threads to specific cores using CPU affinity, the
kworkers on the same CPU would starve, which may lead to some kind
of priority inversion. In that case, the RT threads would also
suffer high performance impact.
The priority inversion looks like,
CPU 0: libvirtd acquired
When pinning RT threads to specific cores using CPU affinity, the
kworkers on the same CPU would starve, which may lead to some kind
of priority inversion. In that case, the RT threads would also
suffer high performance impact.
The priority inversion looks like,
CPU 0: libvirtd acquired
Replace workqueue's unbound_attrs by attrs, so that both unbound
or bound wq can use it.
Signed-off-by: Wen Yang
Signed-off-by: Jiang Biao
Signed-off-by: Tan Hu
Suggested-by: Tejun Heo
Cc: Tejun Heo
Replace workqueue's unbound_attrs by attrs, so that both unbound
or bound wq can use it.
Signed-off-by: Wen Yang
Signed-off-by: Jiang Biao
Signed-off-by: Tan Hu
Suggested-by: Tejun Heo
Cc: Tejun Heo
Cc: Lai Jiangshan
Cc: kernel test robot
Cc: linux-kernel@vger.kernel.org
---
Rename system_wq's wq->name from "events" to "system_percpu",
and similarly for the similarly named workqueues.
Signed-off-by: Wen Yang
Signed-off-by: Jiang Biao
Signed-off-by: Tan Hu
Suggested-by: Tejun Heo
Rename system_wq's wq->name from "events" to "system_percpu",
and similarly for the similarly named workqueues.
Signed-off-by: Wen Yang
Signed-off-by: Jiang Biao
Signed-off-by: Tan Hu
Suggested-by: Tejun Heo
Cc: Tejun Heo
Cc: Lai Jiangshan
Cc: linux-kernel@vger.kernel.org
---
Expose sched_attr for system workqueues, such as:
# cat /sys/devices/virtual/workqueue/system_percpu/sched_attr
policy=0 prio=0 nice=0
cat /sys/devices/virtual/workqueue/system_percpu_highpri/sched_attr
policy=0 prio=0 nice=-20
Signed-off-by: Wen Yang
Expose sched_attr for system workqueues, such as:
# cat /sys/devices/virtual/workqueue/system_percpu/sched_attr
policy=0 prio=0 nice=0
cat /sys/devices/virtual/workqueue/system_percpu_highpri/sched_attr
policy=0 prio=0 nice=-20
Signed-off-by: Wen Yang
This patch adds creation time field in inode layout to support showing
kstat.btime in ->statx.
Signed-off-by: Chao Yu
---
v3:
- fix address alignment isue.
fs/f2fs/f2fs.h | 7 +++
fs/f2fs/file.c | 9 +
fs/f2fs/inode.c | 16
This patch adds creation time field in inode layout to support showing
kstat.btime in ->statx.
Signed-off-by: Chao Yu
---
v3:
- fix address alignment isue.
fs/f2fs/f2fs.h | 7 +++
fs/f2fs/file.c | 9 +
fs/f2fs/inode.c | 16
Hi Steve,
On 01/21/18 06:31, Wolfram Sang wrote:
> I got a bug report for a DT node refcounting problem in the I2C subsystem.
> This
> patch was a huge help in validating the bug report and the proposed solution.
> So, I thought I bring it to attention again. Thanks Tyrel, for the initial
>
Hi Steve,
On 01/21/18 06:31, Wolfram Sang wrote:
> I got a bug report for a DT node refcounting problem in the I2C subsystem.
> This
> patch was a huge help in validating the bug report and the proposed solution.
> So, I thought I bring it to attention again. Thanks Tyrel, for the initial
>
On 2018/1/24 22:59, Chao Yu wrote:
> Hi Jaegeuk,
>
> On 2018/1/24 13:38, Jaegeuk Kim wrote:
>> On 01/22, Chao Yu wrote:
>>> From: Chao Yu
>>>
>>> This patch adds creation time field in inode layout to support showing
>>> kstat.btime in ->statx.
>>
>> Hi Chao,
>>
>> Could you
On 2018/1/24 22:59, Chao Yu wrote:
> Hi Jaegeuk,
>
> On 2018/1/24 13:38, Jaegeuk Kim wrote:
>> On 01/22, Chao Yu wrote:
>>> From: Chao Yu
>>>
>>> This patch adds creation time field in inode layout to support showing
>>> kstat.btime in ->statx.
>>
>> Hi Chao,
>>
>> Could you please check this
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
A: No.
Q: Should I include quotations after my reply?
http://daringfireball.net/2007/07/on_top
On Thu, Jan 25, 2018 at
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
A: No.
Q: Should I include quotations after my reply?
http://daringfireball.net/2007/07/on_top
On Thu, Jan 25, 2018 at
On 01/21/18 06:31, Wolfram Sang wrote:
> From: Tyrel Datwyler
>
> This patch introduces event tracepoints for tracking a device_nodes
> reference cycle as well as reconfig notifications generated in response
> to node/property manipulations.
>
> With the recent
On 01/21/18 06:31, Wolfram Sang wrote:
> From: Tyrel Datwyler
>
> This patch introduces event tracepoints for tracking a device_nodes
> reference cycle as well as reconfig notifications generated in response
> to node/property manipulations.
>
> With the recent upstreaming of the refcount API
On 01/21/18 06:31, Wolfram Sang wrote:
> I got a bug report for a DT node refcounting problem in the I2C subsystem.
> This
> patch was a huge help in validating the bug report and the proposed solution.
> So, I thought I bring it to attention again. Thanks Tyrel, for the initial
> work!
>
> Note
On 01/21/18 06:31, Wolfram Sang wrote:
> I got a bug report for a DT node refcounting problem in the I2C subsystem.
> This
> patch was a huge help in validating the bug report and the proposed solution.
> So, I thought I bring it to attention again. Thanks Tyrel, for the initial
> work!
>
> Note
On 01/22/18 03:49, Wolfram Sang wrote:
> Hi Frank,
>
>> Please go back and read the thread for version 1. Simply resubmitting a
>> forward port is ignoring that whole conversation.
>>
>> There is a lot of good info in that thread. I certainly learned stuff in it.
>
> Yes, I did that and
On 01/22/18 03:49, Wolfram Sang wrote:
> Hi Frank,
>
>> Please go back and read the thread for version 1. Simply resubmitting a
>> forward port is ignoring that whole conversation.
>>
>> There is a lot of good info in that thread. I certainly learned stuff in it.
>
> Yes, I did that and
On Fri, Jan 19, 2018 at 11:57:32AM +0100, Enric Balletbo Serra wrote:
> Hi Vito,
>
> 2018-01-17 23:48 GMT+01:00 :
> > On Mon, Dec 18, 2017 at 10:25:33AM +0100, Enric Balletbo Serra wrote:
> >> Hi Vito,
> >>
> >> 2017-12-01 22:33 GMT+01:00 :
> >> > On
On Fri, Jan 19, 2018 at 11:57:32AM +0100, Enric Balletbo Serra wrote:
> Hi Vito,
>
> 2018-01-17 23:48 GMT+01:00 :
> > On Mon, Dec 18, 2017 at 10:25:33AM +0100, Enric Balletbo Serra wrote:
> >> Hi Vito,
> >>
> >> 2017-12-01 22:33 GMT+01:00 :
> >> > On Wed, Nov 29, 2017 at 10:39:19AM -0800,
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/tipc/socket.c
between commit:
ade994f4f6c8 ("net: annotate ->poll() instances")
from the vfs tree and commit:
60c253069632 ("tipc: fix race between poll() and setsockopt()")
from the net-next tree.
I fixed
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
net/tipc/socket.c
between commit:
ade994f4f6c8 ("net: annotate ->poll() instances")
from the vfs tree and commit:
60c253069632 ("tipc: fix race between poll() and setsockopt()")
from the net-next tree.
I fixed
On Tue, Jan 23, 2018 at 03:59:34PM +0800, liangli...@huawei.com wrote:
> From: Lihao Liang
>
> This is PRCU's counterpart of RCU's rcu_barrier() API.
>
> Reviewed-by: Heng Zhang
> Signed-off-by: Lihao Liang
> ---
>
On Tue, Jan 23, 2018 at 03:59:34PM +0800, liangli...@huawei.com wrote:
> From: Lihao Liang
>
> This is PRCU's counterpart of RCU's rcu_barrier() API.
>
> Reviewed-by: Heng Zhang
> Signed-off-by: Lihao Liang
> ---
> include/linux/prcu.h | 7 ++
> kernel/rcu/prcu.c| 63
>
On Tue, Jan 23, 2018 at 03:59:32PM +0800, liangli...@huawei.com wrote:
> From: Lihao Liang
>
> This is PRCU's counterpart of RCU's call_rcu() API.
>
> Reviewed-by: Heng Zhang
> Signed-off-by: Lihao Liang
> ---
>
On Tue, Jan 23, 2018 at 03:59:31PM +0800, liangli...@huawei.com wrote:
> From: Lihao Liang
>
> Signed-off-by: Lihao Liang
> ---
> kernel/rcu/rcuperf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/rcu/rcuperf.c
On Tue, Jan 23, 2018 at 03:59:32PM +0800, liangli...@huawei.com wrote:
> From: Lihao Liang
>
> This is PRCU's counterpart of RCU's call_rcu() API.
>
> Reviewed-by: Heng Zhang
> Signed-off-by: Lihao Liang
> ---
> include/linux/prcu.h | 25
> init/main.c | 2 ++
>
On Tue, Jan 23, 2018 at 03:59:31PM +0800, liangli...@huawei.com wrote:
> From: Lihao Liang
>
> Signed-off-by: Lihao Liang
> ---
> kernel/rcu/rcuperf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/rcu/rcuperf.c b/kernel/rcu/rcuperf.c
> index
On Tue, Jan 23, 2018 at 03:59:40PM +0800, liangli...@huawei.com wrote:
> From: Lihao Liang
>
> Signed-off-by: Lihao Liang
> ---
> kvm.sh | 452
> +
> run-rcuperf.sh | 26
The
On Tue, Jan 23, 2018 at 03:59:25PM +0800, liangli...@huawei.com wrote:
> From: Lihao Liang
>
> Dear Paul,
>
> This patch set implements a preemptive version of RCU (PRCU) based on the
> following paper:
>
> Fast Consensus Using Bounded Staleness for Scalable Read-mostly
On Tue, Jan 23, 2018 at 03:59:40PM +0800, liangli...@huawei.com wrote:
> From: Lihao Liang
>
> Signed-off-by: Lihao Liang
> ---
> kvm.sh | 452
> +
> run-rcuperf.sh | 26
The usual approach would be to add what you need to
On Tue, Jan 23, 2018 at 03:59:25PM +0800, liangli...@huawei.com wrote:
> From: Lihao Liang
>
> Dear Paul,
>
> This patch set implements a preemptive version of RCU (PRCU) based on the
> following paper:
>
> Fast Consensus Using Bounded Staleness for Scalable Read-mostly
> Synchronization.
>
On Tue, Jan 23, 2018 at 03:59:28PM +0800, liangli...@huawei.com wrote:
> From: Lihao Liang
>
> Use the same config files as TREE02, TREE03, TREE06, TREE07, and TREE09.
>
> Signed-off-by: Lihao Liang
> ---
>
On Tue, Jan 23, 2018 at 03:59:28PM +0800, liangli...@huawei.com wrote:
> From: Lihao Liang
>
> Use the same config files as TREE02, TREE03, TREE06, TREE07, and TREE09.
>
> Signed-off-by: Lihao Liang
> ---
> .../selftests/rcutorture/configs/rcu/CFLIST| 5
>
On Tue, Jan 23, 2018 at 03:59:26PM +0800, liangli...@huawei.com wrote:
> From: Heng Zhang
>
> This RCU implementation (PRCU) is based on a fast consensus protocol
> published in the following paper:
>
> Fast Consensus Using Bounded Staleness for Scalable Read-mostly
>
On Tue, Jan 23, 2018 at 03:59:26PM +0800, liangli...@huawei.com wrote:
> From: Heng Zhang
>
> This RCU implementation (PRCU) is based on a fast consensus protocol
> published in the following paper:
>
> Fast Consensus Using Bounded Staleness for Scalable Read-mostly
> Synchronization.
> Haibo
Hi Eric
Thanks for you kindly response and suggestion.
That's really appreciated.
Jianchao
On 01/25/2018 11:55 AM, Eric Dumazet wrote:
> On Thu, 2018-01-25 at 11:27 +0800, jianchao.wang wrote:
>> Hi Tariq
>>
>> On 01/22/2018 10:12 AM, jianchao.wang wrote:
> On 19/01/2018 5:49 PM, Eric
Hi Eric
Thanks for you kindly response and suggestion.
That's really appreciated.
Jianchao
On 01/25/2018 11:55 AM, Eric Dumazet wrote:
> On Thu, 2018-01-25 at 11:27 +0800, jianchao.wang wrote:
>> Hi Tariq
>>
>> On 01/22/2018 10:12 AM, jianchao.wang wrote:
> On 19/01/2018 5:49 PM, Eric
Rob Herring writes:
> On Tue, Jan 23, 2018 at 12:53 AM, Michael Ellerman
> wrote:
>> Rob Herring writes:
>>
>>> Instead of calling both of_irq_parse_one and irq_create_of_mapping, call
>>> of_irq_parse_and_map instead which does the same
Rob Herring writes:
> On Tue, Jan 23, 2018 at 12:53 AM, Michael Ellerman
> wrote:
>> Rob Herring writes:
>>
>>> Instead of calling both of_irq_parse_one and irq_create_of_mapping, call
>>> of_irq_parse_and_map instead which does the same thing. This gets us closer
>>> to making the former 2
Hi Bjorn,
After merging the pci tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
arch/powerpc/kernel/pci-common.c: In function 'pcibios_setup
_device':
arch/powerpc/kernel/pci-common.c:406:15: error: 'virq' may be used
uninitialized in this function
Hi Bjorn,
After merging the pci tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
arch/powerpc/kernel/pci-common.c: In function 'pcibios_setup
_device':
arch/powerpc/kernel/pci-common.c:406:15: error: 'virq' may be used
uninitialized in this function
Remove %p because the kprobe will be dumped in
dump_kprobe().
Signed-off-by: Masami Hiramatsu
---
arch/s390/kernel/kprobes.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/s390/kernel/kprobes.c b/arch/s390/kernel/kprobes.c
index
Remove %p because the kprobe will be dumped in
dump_kprobe().
Signed-off-by: Masami Hiramatsu
---
arch/s390/kernel/kprobes.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/s390/kernel/kprobes.c b/arch/s390/kernel/kprobes.c
index af3722c28fd9..df30e5b9a572 100644
---
Fix %p uses in error messages by removing it because
those are redundant or meaningless.
Signed-off-by: Masami Hiramatsu
---
arch/arm64/kernel/probes/kprobes.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/probes/kprobes.c
Fix %p uses in error messages by removing it because
those are redundant or meaningless.
Signed-off-by: Masami Hiramatsu
---
arch/arm64/kernel/probes/kprobes.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/probes/kprobes.c
Replace %p with %px because it is right before BUG().
Signed-off-by: Masami Hiramatsu
---
arch/mn10300/kernel/kprobes.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/mn10300/kernel/kprobes.c b/arch/mn10300/kernel/kprobes.c
index
Replace %p with %px because it is right before BUG().
Signed-off-by: Masami Hiramatsu
---
arch/mn10300/kernel/kprobes.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/mn10300/kernel/kprobes.c b/arch/mn10300/kernel/kprobes.c
index 0311a7fcea16..e539fac00321
On Wed, Jan 24, 2018 at 08:34:14PM -0700, Jens Axboe wrote:
> On 1/24/18 7:46 PM, Jia-Ju Bai wrote:
> > The function ioc_create_icq here is not called in atomic context.
> > Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
> >
> > This is found by a static analysis tool
On Wed, Jan 24, 2018 at 08:34:14PM -0700, Jens Axboe wrote:
> On 1/24/18 7:46 PM, Jia-Ju Bai wrote:
> > The function ioc_create_icq here is not called in atomic context.
> > Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
> >
> > This is found by a static analysis tool
Fix %p uses in error messages by removing it and
using general dumper.
Signed-off-by: Masami Hiramatsu
---
arch/arm/probes/kprobes/core.c | 10 +-
arch/arm/probes/kprobes/test-core.c |1 -
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git
Fix %p uses in error messages by removing it and
using general dumper.
Signed-off-by: Masami Hiramatsu
---
arch/arm/probes/kprobes/core.c | 10 +-
arch/arm/probes/kprobes/test-core.c |1 -
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git
Fix %p uses in error messages in kprobes/x86.
- Some %p uses are not needed. Just remove it (or remove message).
- One %p use is right before the BUG() so replaced with %px.
Signed-off-by: Masami Hiramatsu
---
arch/x86/kernel/kprobes/core.c | 12
1 file
good morning Linux
https://goo.gl/2YZCS5
Fix %p uses in error messages in kprobes/x86.
- Some %p uses are not needed. Just remove it (or remove message).
- One %p use is right before the BUG() so replaced with %px.
Signed-off-by: Masami Hiramatsu
---
arch/x86/kernel/kprobes/core.c | 12
1 file changed, 4 insertions(+),
good morning Linux
https://goo.gl/2YZCS5
1 - 100 of 1710 matches
Mail list logo