kgdbts current fails when compiled with restrict:
drivers/misc/kgdbts.c: In function ‘configure_kgdbts’:
drivers/misc/kgdbts.c:1070:2: error: ‘strcpy’ source argument is the same as
destination [-Werror=restrict]
strcpy(config, opt);
^~~
As the error says, config is being use
On Mon, 10 Sep 2018, Andreas Grünbacher wrote:
Am Mo., 10. Sep. 2018 schrieb Marc Aurèle La France:
Commit 786534b92f3ce68f4afc8a761c80b76887797b0a "tmpfs: listxattr
should include POSIX ACL xattrs", which first appeared in 4.5 kernels,
introduced a regression whereby listxattr() syscalls on a
Hi Gao,
On Mon, Sep 10, 2018 at 09:08:57PM +0800, Gao Xiang wrote:
> This patch attempts to enable RCU-walk for fscrypt.
> It looks harmless at glance and could have better
> performance than do ref-walk only.
>
> Signed-off-by: Gao Xiang
> ---
> change log v2:
> - READ_ONCE(dir->d_parent)
On Mon, Sep 10, 2018 at 03:36:54PM -0600, Jeremy Gebben wrote:
> The abx804 and abx805 chips have support for a simple watchdog
> function that can trigger an external reset.
>
> Signed-off-by: Jeremy Gebben
I am missing the "select WATCHDOG_CORE" that would normally go
with watchdog drivers. If
I just noticed this patch because it conflicted with the PREEMPT_RT v4.14
patch.
On Fri, Jul 20, 2018 at 10:39:13AM +0200, Peter Rosin wrote:
> Needed for annotating rt_mutex locks.
>
> Tested-by: John Sperbeck
> Signed-off-by: Peter Rosin
> ---
> include/linux/rtmutex.h | 7 +++
> kerne
This series implements EDAC driver for QCOM SoCs. As of now, this driver
supports EDAC for Last Level Cache Controller (LLCC). LLCC EDAC driver is
to detect and report single and double bit errors on Last Level Cache
Controller (LLCC) cache. Interrupts are triggered when the errors happen
in the ca
From: Channagoud Kadabi
Add error reporting driver for Single Bit Errors (SBEs) and Double Bit
Errors (DBEs). As of now, this driver supports error reporting for
Last Level Cache Controller (LLCC) of Tag RAM and Data RAM. Interrupts
are triggered when the errors happen in the cache, the driver ha
Add reg-names and interrupts for LLCC documentation and the usage
examples. llcc broadcast base is added in addition to llcc base,
which is used for llcc broadcast writes.
Signed-off-by: Venkata Narendra Kumar Gutta
Reviewed-by: Rob Herring
---
.../devicetree/bindings/arm/msm/qcom,llcc.txt
Built-in PHY ports are still being polled, avoid generating spurious
and duplicate events which the PHY library resolves through polling
anyways.
Fixes: 0e01491de646 ("net: dsa: b53: Add SerDes support")
Signed-off-by: Florian Fainelli
---
drivers/net/dsa/b53/b53_srab.c | 3 ++-
1 file changed,
Cache error reporting controller detects and reports single and
double bit errors on Last Level Cache Controller (LLCC) cache.
Add required support to register LLCC EDAC driver as platform driver,
from LLCC driver.
Signed-off-by: Venkata Narendra Kumar Gutta
Reviewed-by: Evan Green
---
drivers/
Currently, broadcast base is set to end of the LLCC banks, which may
not be correct always. As the number of banks may vary for each chipset
and the broadcast base could be at a different address as well. This info
depends on the chipset, so get the broadcast base info from the device
tree (DT). Ad
Hi,
On 08/03/2018 07:05 AM, Dietmar Eggemann wrote:
A CFS (SCHED_OTHER, SCHED_BATCH or SCHED_IDLE policy) task's
se->runnable_weight must always be in sync with its se->load.weight.
se->runnable_weight is set to se->load.weight when the task is
forked (init_entity_runnable_average()) or reniced
Folks, please tell me that I'm misreading the history
here...
0.97:
kernel/chr_dev/tty_ioctl.c:tty_ioctl():
+ case FIONBIO:
+ if (arg)
+ file->f_flags |= O_NONBLOCK;
+ else
+
On Mon, Sep 10, 2018 at 05:09:52AM -0700, swkhack wrote:
> the i_state init in the critical section,so as the list init should in it.
Why? What bug does this fix?
-Dave.
--
Dave Chinner
da...@fromorbit.com
On 9/10/18 1:34 PM, John Hubbard wrote:
On 9/10/18 10:20 AM, Davidlohr Bueso wrote:
On Mon, 10 Sep 2018, Waiman Long wrote:
On 09/08/2018 12:13 AM, John Hubbard wrote:
[...]
It's also interesting that there are two main huge page systems (THP and
Hugetlbfs), and I sometimes
wonder the obviou
On 9/8/18 12:13 AM, John Hubbard wrote:
I'm interested in the first 3 of those 4 topics, so if it doesn't conflict with
HMM topics or
fix-gup-with-dma topics, I'd like to attend.
Great, we'll add your name to the list.
GPUs generally need to access large chunks of
memory, and that includes m
On Mon, 10 Sep 2018, Roman Gushchin wrote:
> The memcg OOM killer is never invoked due to a failed high-order
> allocation, however the MEMCG_OOM event can be easily raised.
>
> Under some memory pressure it can happen easily because of a
> concurrent allocation. Let's look at try_charge(). Even
Hi,
This is a work-in-progress of what I presented at LSF/MM this year[0] to
greatly reduce contention on lru_lock, allowing it to scale on large systems.
This is completely different from the lru_lock series posted last January[1].
I'm hoping for feedback on the overall design and general direc
lru_lock needs to be held to update memcg LRU statistics. This
requirement arises fairly naturally based on when the stats are updated
because callers are holding lru_lock already.
In preparation for allowing concurrent adds and removes from the LRU,
however, make concurrent updates to these stat
lru_lock needs to be held to update the zone_reclaim_stat statistics.
Similar to the previous patch, this requirement again arises fairly
naturally because callers are holding lru_lock already.
In preparation for allowing concurrent adds and removes from the LRU,
however, make concurrent updates t
lru_lock is currently a spinlock, which allows only one task at a time
to add or remove pages from any of a node's LRU lists, even if the
pages are in different parts of the same LRU or on different LRUs
altogether. This bottleneck shows up in memory-intensive database
workloads such as decision s
FYI, we noticed the following commit (built with gcc-6):
commit: fd0002870b453c58d0d8c195954f5049bc6675fb ("vfs: Implement a filesystem
superblock creation/configuration context")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
in testcase: boot
on test machine: qemu-sys
On 2018-09-11 01:27, Steven Rostedt wrote:
>
> Why this:
>
> #ifdef CONFIG_DEBUG_LOCK_ALLOC
> [..]
> #endif
>
> #ifndef CONFIG_DEBUG_LOCK_ALLOC
> [..]
> #endif
>
> ???
>
> This should use #else.
Yes. Water under the bridge...
Cheers,
Peter
The previous patch used the concurrent algorithm serially to see that it
was stable for one task. Now in release_pages, take lru_lock as reader
instead of writer to allow concurrent removals from one or more LRUs.
Suggested-by: Yosef Lev
Signed-off-by: Daniel Jordan
---
mm/swap.c | 28
Now that the LRU lock is a RW lock, lay the groundwork for fine-grained
synchronization so that multiple threads holding the lock as reader can
safely remove pages from an LRU at the same time.
Add a thread-safe variant of list_del called smp_list_del that allows
multiple threads to delete nodes f
The add-to-front LRU path currently adds one page at a time to the front
of an LRU. This is slow when using the concurrent algorithm described
in the next patch because the LRU head node will be locked for every
page that's added.
Instead, prepare local lists of pages, grouped by LRU, to be added
This patch is NOT OK to me，maybe many cache in a cache_set, and some
cache are not registered yet, so ca is possible NULL.
zhong jiang 于2018年9月8日周六 下午7:52写道：
>
> The iterator in for_each_cache is never null, therefore, remove
> the redundant null pointer check.
>
> Signed-off-by: zhong jiang
> -
Now that we splice a local list onto the LRU, prepare for multiple tasks
doing this concurrently by adding a variant of the kernel's list
splicing API, list_splice, that's designed to work with multiple tasks.
Although there is naturally less parallelism to be gained from locking
the LRU head this
Switch over to holding lru_lock as reader when splicing pages onto the
front of an LRU. The main benefit of doing this is to allow LRU adds
and removes to happen concurrently. Before this patch, an add blocks
all removing threads.
Suggested-by: Yosef Lev
Signed-off-by: Daniel Jordan
---
mm/sw
On 2018/9/10 22:19, Mark Brown wrote:
> On Sat, Sep 08, 2018 at 04:36:19PM +0800, zhong jiang wrote:
>> kmemdup has implemented the function that kzalloc() + memcpy() will
>> do. and we prefer to use the kmemdup rather than the open coded
>> implementation.
> Please submit patches using subject li
sorry, the cover letter forwand to rafael.
Thanks,
Chao Fan
On Mon, Sep 10, 2018 at 08:40:12PM +0800, Chao Fan wrote:
>***Background:
>People reported that kaslr may randomly chooses some positions
>which are located in movable memory regions. This will break memory
>hotplug feature and make the
On 2018/9/10 21:49, zhong jiang wrote:
> On 2018/9/8 22:17, Jonathan Cameron wrote:
>> On Sat, 8 Sep 2018 17:59:13 +0530
>> Himanshu Jha wrote:
>>
>>> On Sat, Sep 08, 2018 at 06:57:36PM +0800, zhong jiang wrote:
The iterator in for_each_set_bit is never null, therefore, remove
the redund
On 11 September 2018 at 05:20, Pavel Machek wrote:
> Hi!
>
>> >> I'm still convinced that this will confuse our users and to me it would
>> >> be more logical if this denotes the number of times the pattern should
>> >> be repeated, with e.g. negative numbers denoting infinite.
>> >
>> > Sounds re
On 9/10/18 4:24 AM, Christoph Hellwig wrote:
On Thu, Sep 06, 2018 at 01:05:25AM -0700, Atish Patra wrote:
+#elif defined(CONFIG_64BIT)
+ if ((strcmp(mmu_type, "riscv,sv39") != 0)
+ && (strcmp(mmu_type, "riscv,sv48") != 0))
+ return;
This should be:
if (st
On 9/10/18 4:29 AM, Christoph Hellwig wrote:
On Thu, Sep 06, 2018 at 01:05:34AM -0700, Atish Patra wrote:
Setup the cpu_logical_map during boot. Moreover, every SBI call
and PLIC context are based on the physical hartid. Use the logical
cpu to hartid mapping to pass correct hartid to respective
On 9/10/18 4:26 AM, Christoph Hellwig wrote:
On Thu, Sep 06, 2018 at 01:05:29AM -0700, Atish Patra wrote:
From: Palmer Dabbelt
It's a bit confusing exactly what this function does: it actually
returns the hartid of an OF processor node, failing with -1 on invalid
nodes. I've changed the name
On 2018/9/11 8:59, Junhui Tang wrote:
> This patch is NOT OK to me，maybe many cache in a cache_set, and some
> cache are not registered yet, so ca is possible NULL.
Yep, It's my fault. please ingnore the patch.
Thanks,
zhong jiang
> zhong jiang 于2018年9月8日周六 下午7:52写道：
>> The iterator in for_e
From: Steven Rostedt (VMware)
Merging v4.14.68 into v4.14-rt I tripped over a conflict in the
rtmutex.c code. There I found that we had:
#ifdef CONFIG_DEBUG_LOCK_ALLOC
[..]
#endif
#ifndef CONFIG_DEBUG_LOCK_ALLOC
[..]
#endif
Really this should be:
#ifdef CONFIG_DEBUG_LOCK_ALLOC
[..]
There is a couple of reports about lockup in ldsem_down_read() without
anyone holding write end of ldisc semaphore:
lkml.kernel.org/r/<20171121132855.ajdv4k6swzhvk...@wfg-t540p.sh.intel.com>
lkml.kernel.org/r/<20180907045041.GF1110@shao2-debian>
They all looked like a missed wake up.
I wasn't luck
tty_ldisc_reinit() doesn't race with neither tty_ldisc_hangup()
nor set_ldisc() nor tty_ldisc_release() as they use tty lock.
But it races with anyone who expects line discipline to be the same
after hoding read semaphore in tty_ldisc_ref().
We've seen the following crash on v4.9.108 stable:
BUG:
Hi all,
Three fixes that worth to have in the @stable, as we've hit them on v4.9
stable.
And for linux-next - adding lockdep asserts for line discipline changing
code, verifying that write ldisc sem will be held forthwith.
The last patch is optional and probably, timeout can be dropped for
read_
As notted by Jiri, tty_ldisc_reinit() shouldn't rely on tty counter.
Simplify math by increasing the counter after reinit success.
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Link: lkml.kernel.org/r/<20180829022353.23568-2-d...@arista.com>
Suggested-by: Jiri Slaby
Reviewed-by: Jiri Slaby
Signed-off-
Make sure under CONFIG_LOCKDEP that each change to line discipline
is done with held write semaphor.
Otherwise potential reader will have a good time dereferencing
incomplete/uninitialized ldisc.
Exception here is tty_ldisc_open(), as it's called without ldisc_sem
locked by tty_init_dev() for the
In case of tty_ldisc_reinit() failure, tty->count should be decremented
back, otherwise we will never release_tty().
Tetsuo reported that it fixes noisy warnings on tty release like:
pts pts4033: tty_release: tty->count(10529) != (#fd's(7) + #kopen's(0))
Fixes: commit 892d1fa7eaae ("tty: Destroy
It seems like when ldsem_down_read() fails with timeout, it misses
update for sem->wait_readers. By that reason, when writer finally
releases write end of the semaphore __ldsem_wake_readers() does adjust
sem->count with wrong value:
sem->wait_readers * (LDSEM_ACTIVE_BIAS - LDSEM_WAIT_BIAS)
I.e, if
On Mon, Sep 10, 2018 at 04:19:26PM +0100, Mark Brown wrote:
> On Sun, Sep 09, 2018 at 10:00:23AM +0800, Shawn Guo wrote:
> > On Thu, Sep 06, 2018 at 11:15:17AM +0100, Mark Brown wrote:
>
> > > I was expecting to get a pull request with the precursor patches in it -
> > > the regulator driver seems
Hi Michal,
On 09/10/2018 07:48 AM, Michal Hocko wrote:
> On Fri 07-09-18 16:30:59, Shuah Khan wrote:
>> On 09/07/2018 02:34 AM, Michal Hocko wrote:
>>> On Thu 06-09-18 15:53:34, Shuah Khan wrote:
[]
>>
>> In addition to isolation, being able to reserve a block instead is one of the
>> issues I
On Mon, Sep 10, 2018 at 06:12:43PM +0300, Andy Shevchenko wrote:
> On Mon, Sep 10, 2018 at 10:42:59PM +0800, Song Qiang wrote:
> > This driver was originally written by ST in 2016 as a misc input device,
> > and hasn't been maintained for a long time. I grabbed some code from
> > it's API and refor
> On 2018年9月10日, at 下午11:36, Jiri Benc wrote:
>
> On Mon, 10 Sep 2018 16:25:09 +0800, Haishuang Yan wrote:
>> +if (gre_parse_header(skb, &tpi, &csum_err, htons(ETH_P_IPV6),
>> + offset) < 0) {
>> +if (!csum_err) /* ignore csum errors. */
>> +
From: Xin Lin <18650033...@163.com>
Adversaries often attack the Linux kernel via using
commit_creds(prepare_kernel_cred(0)) to submit ROOT
credential for the purpose of privilege escalation.
For processes inside the Linux container, the above
approach also works, because the container and the
ho
On Thu, 2018-09-06 at 20:31 +0200, Wolfram Sang wrote:
> On Thu, Sep 06, 2018 at 09:15:28PM +0800, Jun Gao wrote:
> > From: Jun Gao
> >
> > In order not to block the initializations of some i2c devices.
> > Register i2c adapter driver at appropriate time.
> >
> > Signed-off-by: Jun Gao
>
> The
On (09/10/18 16:57), Petr Mladek wrote:
>
> Good catch.
>
> > ---
> >
> > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> > index c036f128cdc3..ede29a7ba6db 100644
> > --- a/kernel/printk/printk.c
> > +++ b/kernel/printk/printk.c
> > @@ -2545,6 +2545,7 @@ void console_flush_on_pan
This patchset adds 96Boards Rock960 CE board support. Rock960 CE
(Consumer Edition) board is one of the member of 96Boards Consumer
Edition and AI platform and is manufactured by Vamrs Limited. Most of
the board configuration is shared with the Ficus board manufactured by
vamrs, which is an Enterpr
Since the same family members of Rock960 boards (Rock960 and Ficus)
share the same configuration, split out the common nodes into a common
dtsi file for reducing code duplication. The board specific nodes for
Ficus boards are then placed in corresponding board DTS file.
Signed-off-by: Manivannan S
Add devicetree support for Rock960 board, one of the Consumer Edition
boards of the 96Boards family. This board support utilizes the common
Rock960 family board support that includes Ficus 96Board.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
..
For proper working of SD cards, let's add the Card Detect GPIO property
to the common devicetree for Rock960 family boards.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/rockchip/r
Add devicetree binding for Rock960 board from Vamrs Limited.
Signed-off-by: Manivannan Sadhasivam
---
Documentation/devicetree/bindings/arm/rockchip.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
b/Documentation/devicetree/bindings
On Mon, Sep 10, 2018 at 11:27:47PM +0530, Himanshu Jha wrote:
> On Mon, Sep 10, 2018 at 10:42:59PM +0800, Song Qiang wrote:
> > This driver was originally written by ST in 2016 as a misc input device,
> > and hasn't been maintained for a long time. I grabbed some code from
> > it's API and reformed
Hi Greg,
After merging the usb tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
drivers/usb/core/hcd.c: In function '__usb_hcd_giveback_urb':
drivers/usb/core/hcd.c:1741:16: warning: unused variable 'flags'
[-Wunused-variable]
unsigned long flags;
This patch implements the 'pattern_set'and 'pattern_clear'
interfaces to support SC27XX LED breathing mode.
Signed-off-by: Baolin Wang
Acked-by: Pavel Machek
---
Changes from v11:
- None.
Changes from v10:
- Add duration alignment function suggested by Jacek.
- Add acked tag from Pavel.
Cha
This patch adds one new led trigger that LED device can configure
the software or hardware pattern and trigger it.
Consumers can write 'pattern' file to enable the software pattern
which alters the brightness for the specified duration with one
software timer.
Moreover consumers can write 'hw_pat
sart_mode_of_match' defined but
not used [-Wunused-variable]
static const struct of_device_id at91_usart_mode_of_match[] = {
^~~~
Caused by commit
7d3aa342cef7 ("mfd: at91-usart: Add MFD driver for USART")
Forgot to
I noticed that tools/lib/api/Makefile has these conditional
assignments, similar to tools/perf/Makefile.config:
ifeq ($(DEBUG),0)
ifeq ($(CC_NO_CLANG), 0)
CFLAGS += -O3
else
CFLAGS += -O6
endif
endif
ifeq ($(DEBUG),0)
CFLAGS += -D_FORTIFY_SOURCE
endif
But it doesn't set DEBUG to 0 by defau
On Mon, Sep 10, 2018 at 7:04 PM, Christoph Hellwig wrote:
> On Thu, Sep 06, 2018 at 04:15:14PM +0530, Anup Patel wrote:
>> This patch is doing two things:
>> 1. Allow IRQCHIP driver to provide IPI trigger mechanism
>
> And the big questions is why do we want that? The last thing we
> want is for
Thanks Rob for reviewing.
On 9/11/2018 1:31 AM, Rob Herring wrote:
On Mon, Sep 03, 2018 at 05:22:39PM +0530, Rohit kumar wrote:
Add devicetree bindings documentation file for Qualcomm
Technolgies Inc ADSP Peripheral Image Loader.
Signed-off-by: Rohit kumar
---
.../bindings/remoteproc/qcom,
Thanks Bjorn for reviewing.
On 9/11/2018 12:01 AM, Bjorn Andersson wrote:
On Mon 03 Sep 04:52 PDT 2018, Rohit kumar wrote:
This adds Non PAS ADSP PIL driver for Qualcomm
Technologies Inc SoCs.
Added initial support for SDM845 with ADSP bootup and
shutdown operation handled from Application Pr
Hi all,
After merging the tip tree, today's linux-next build (x86_64 allnoconfig)
produced this warning:
arch/x86/kernel/cpu/common.c: In function 'syscall_init':
arch/x86/kernel/cpu/common.c:1534:6: warning: unused variable 'cpu'
[-Wunused-variable]
int cpu = smp_processor_id();
^~~
In
Add devicetree bindings documentation file for Qualcomm
Technolgies Inc ADSP Peripheral Image Loader.
Signed-off-by: Rohit kumar
---
Changes since v3:
Addressed comments given by Rob
.../bindings/remoteproc/qcom,adsp-pil.txt | 126 +
1 file changed, 126 insertions(+
On Tue, Sep 11, 2018 at 3:49 AM, Christoph Hellwig wrote:
> On Mon, Sep 10, 2018 at 09:37:59PM +0200, Thomas Gleixner wrote:
>> Processor local interrupts really should be architected and there are
>> really not that many of them.
>
> And that is what they are.
>
>> But well, RISC-V decided obvsio
On Mon, Sep 10, 2018 at 10:18 AM, Oleg Nesterov wrote:
> On 09/10, Kees Cook wrote:
>>
>> > So get_arg_page() does
>> >
>> > /*
>> > * Since the stack will hold pointers to the strings, we
>> > * must account for them as well.
>> >
On Mon, Sep 10, 2018 at 10:21 AM, Oleg Nesterov wrote:
> On 09/10, Kees Cook wrote:
>>
>> On Mon, Sep 10, 2018 at 9:41 AM, Kees Cook wrote:
>> > On Mon, Sep 10, 2018 at 5:29 AM, Oleg Nesterov wrote:
>> >> Hi Kees,
>> >>
>> >> I was thinking about backporting the commit 98da7d08850fb8bde
>> >> ("
On Mon, Sep 10, 2018 at 10:43 AM, Oleg Nesterov wrote:
> On 09/10, Oleg Nesterov wrote:
>>
>> On 09/10, Kees Cook wrote:
>> >
>> > On Mon, Sep 10, 2018 at 9:41 AM, Kees Cook wrote:
>> > > On Mon, Sep 10, 2018 at 5:29 AM, Oleg Nesterov wrote:
>> > >> Hi Kees,
>> > >>
>> > >> I was thinking about
Hi Shawn,
On 11.09.2018 03:53, Shawn Guo wrote:
> On Mon, Sep 10, 2018 at 04:19:26PM +0100, Mark Brown wrote:
>> On Sun, Sep 09, 2018 at 10:00:23AM +0800, Shawn Guo wrote:
>>> On Thu, Sep 06, 2018 at 11:15:17AM +0100, Mark Brown wrote:
>>
I was expecting to get a pull request with the precurs
Hi all,
Changes since 20180910:
Dropped trees: xarray, ida (temporarily)
The vfs tree lost a build failure, but I still disabled building some
samples.
The tty tree gained a build failure so I used the version from
next-20180910.
Non-merge commits (relative to Linus' tree): 2768
3055
On (09/11/18 02:48), Dmitry Safonov wrote:
> There is a couple of reports about lockup in ldsem_down_read() without
> anyone holding write end of ldisc semaphore:
> lkml.kernel.org/r/<20171121132855.ajdv4k6swzhvk...@wfg-t540p.sh.intel.com>
> lkml.kernel.org/r/<20180907045041.GF1110@shao2-debian>
>
FYI, we noticed the following commit (built with gcc-6):
commit: a8c7fe83d17109b77c7b27a23140e76d3753fa6a ("kernfs, sysfs, cgroup,
intel_rdt: Support fs_context")
https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git
btrfs-mount-api
in testcase: trinity
with following parameters:
Hi Boris,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Monday, August 20, 2018 10:10 PM
> To: Naga Sureshkumar Relli
> Cc: miquel.ray...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> computersforpe...@gmail.com; marek.va...@gmail.com; kyu
If the cmd has not be returned after aborted by qla2x00_eh_abort,
we have to wait for it. However, the time is 1000ms at least currently.
If there are a lot cmds need to be aborted, the delay could be long
enough to lead to panic due to such as hung task, ocfs2 heartbeat,
etc, just before scsi reco
Hi,
[LINUX PATCH v11 1/3] dt-bindings: memory: Add pl353 smc controller devicetree
binding information
[LINUX PATCH v11 2/3] memory: pl353: Add driver for arm pl353 static memory
controller
Can somebody apply the above patches?
The above patches are already reviewed.
Thanks,
Naga Sureshkumar
Hi Eric,
On 2018/9/11 7:20, Eric Biggers wrote:
> Hi Gao,
>
> On Mon, Sep 10, 2018 at 09:08:57PM +0800, Gao Xiang wrote:
>> This patch attempts to enable RCU-walk for fscrypt.
>> It looks harmless at glance and could have better
>> performance than do ref-walk only.
>>
>> Signed-off-by: Gao Xiang
This patch converts zone lock from spinlock to rwlock and always
take the lock in write mode so there is no functionality change.
This is a preparation for free path to take the lock in read mode
to make free path work concurrently.
compact_trylock and compact_unlock_should_abort are taken from
D
Since we will make free path run concurrently, free_area[].nr_free has
to be atomic.
Signed-off-by: Aaron Lu
---
include/linux/mmzone.h | 2 +-
mm/page_alloc.c| 12 ++--
mm/vmstat.c| 4 ++--
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/linu
Daniel Jordan's patch has made it possible for multiple threads to
operate on a global list with smp_list_del() at any position and
smp_list_add/splice() at head position concurrently without taking
any lock.
This patch makes use of this technique on free list.
To make this happen, add_to_buddy_ta
There are multiple places that add/remove a page into/from buddy,
introduce helper functions for them.
This also makes it easier to add code when a page is added/removed
to/from buddy.
No functionality change.
Acked-by: Vlastimil Babka
Signed-off-by: Aaron Lu
---
mm/page_alloc.c | 65
Daniel Jordan and others proposed an innovative technique to make
multiple threads concurrently use list_del() at any position of the
list and list_add() at head position of the list without taking a lock
in this year's MM summit[0].
People think this technique may be useful to improve zone lock
s
From: Daniel Jordan
Now that we splice a local list onto the LRU, prepare for multiple tasks
doing this concurrently by adding a variant of the kernel's list
splicing API, list_splice, that's designed to work with multiple tasks.
Although there is naturally less parallelism to be gained from loc
With free path running concurrently, the cache bouncing on free
list head is severe since multiple threads can be freeing pages
and each free will need to add the page to free list head.
To improve performance on free path for order-0 pages, we can
choose to not add the merged pages to Buddy immed
For the sake of testing purpose, do not add anon pages to LRU to
avoid LRU lock so we can test zone lock exclusively.
Signed-off-by: Aaron Lu
---
mm/memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memory.c b/mm/memory.c
index c467102a5cbc..080641255b8b 100644
---
Now that we have mergable pages in Buddy unmerged, this is a step
to reduce such things from happening to some extent.
Suppose two buddy pages are on the list to be freed in free_pcppages_bulk(),
the first page goes to merge but its buddy is not in Buddy yet so we
hold it locally as an order0 page
From: Daniel Jordan
Now that the LRU lock is a RW lock, lay the groundwork for fine-grained
synchronization so that multiple threads holding the lock as reader can
safely remove pages from an LRU at the same time.
Add a thread-safe variant of list_del called smp_list_del that allows
multiple thr
On (09/11/18 14:04), Sergey Senozhatsky wrote:
> > for (;;) {
> > set_current_state(TASK_UNINTERRUPTIBLE);
>
> I think that set_current_state() also executes memory barrier. Just
> because it accesses task state.
>
> > - if (!waiter.task)
> > + if (!READ_ONCE(w
Hello,
syzbot found the following crash on:
HEAD commit:3d0e7a9e00fd Merge tag 'md/4.19-rc2' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1666429e40
kernel config: https://syzkaller.appspot.com/x/.config?x=8f59875069d721b6
da
On Mon, 10 Sep 2018 23:17:18 +0200,
Yu Zhao wrote:
>
> This reverts commit 12eeeb4f4733bbc4481d01df35933fc15beb8b19.
>
> The patch doesn't fix accessing memory with null pointer in
> skl_interrupt().
>
> There are two problems: 1) skl_init_chip() is called twice, before
> and after dma buffer is
Hello,
syzbot found the following crash on:
HEAD commit:11da3a7f84f1 Linux 4.19-rc3
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10577ada40
kernel config: https://syzkaller.appspot.com/x/.config?x=9917ff4b798e1a1e
dashboard link: https://syzkaller.a
On Mon, 10 Sep 2018 23:21:50 +0200,
Yu Zhao wrote:
>
> In snd_hdac_bus_init_chip(), we enable interrupt before
> snd_hdac_bus_init_cmd_io() initializing dma buffers. If irq has
> been acquired and irq handler uses the dma buffer, kernel may crash
> when interrupt comes in.
>
> Fix the problem by
Hi Thomas,
On Mon, Sep 10, 2018 at 11:53:39AM +0200, Thomas Gleixner wrote:
> On Mon, 10 Sep 2018, Feng Tang wrote:
> > diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
> > index e848a4811785..fc172551048a 100644
> > --- a/arch/x86/mm/pgtable.c
> > +++ b/arch/x86/mm/pgtable.c
> > @@ -637
Hi,
On 4 September 2018 at 14:52, Chunyan Zhang wrote:
> On 11 August 2018 at 09:34, Baolin Wang wrote:
>> Remove the unused reg_backup structure.
>>
>> Signed-off-by: Baolin Wang
>
> Acked-by: Chunyan Zhang
Thanks Chunyan.
Greg, could you apply this patch set if there are no other issues? T
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/drm_plane.c: In function 'drm_mode_getplane_res':
drivers/gpu/drm/drm_plane.c:475:26: warning:
variable 'config' set but not used [-Wunused-but-set-variable]
Signed-off-by: YueHaibing
---
drivers/gpu/drm/drm_plane.c | 2 --
1 file
On 9/7/2018 12:11 PM, Thomas Gleixner wrote:
On Thu, 6 Sep 2018, Philipp Eppelt wrote:
The "flat" driver defines the MSI addressing scheme to be used as
logical addressing in flat mode. The MSI msg address is composed
accordingly, but sets MSI_ADDR_REDIRECTION_CPU which is a zero at bit[3].
C
Hello,
syzbot found the following crash on:
HEAD commit:3d0e7a9e00fd Merge tag 'md/4.19-rc2' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12820cd140
kernel config: https://syzkaller.appspot.com/x/.config?x=8f59875069d721b6
da
701 - 800 of 822 matches
Mail list logo
