Hi Xin,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.19-rc3 next-20180910]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Inotify api cannot display information about users and processes.
That is, you can only know that the file event is generated, but you don't know
who triggered the event, which is not conducive to fault location.
Is it possible to add pid and comm members to the event structure to increase
the di
Hi Xin,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.19-rc3 next-20180910]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
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
On 2018/9/11 2:06, Borislav Petkov wrote:
On Mon, Sep 10, 2018 at 09:16:03PM +0800, Pu Wen wrote:
The Hygon Dhyana CPU have a special magic MSR way to force WB for
From the last review round:
Also, it is "The ... CPU has a special..."
Please take your time and incorporate *all* review feedb
On Mon, 10 Sep 2018 14:23:56 +0200
Ingo Molnar wrote:
>
> * Masami Hiramatsu wrote:
>
> > Instead of calling BUG_ON, if we find a kprobe in use on free kprobe
> > list, just remove it from the list and keep it on kprobe hash list
> > as same as other in-use kprobes.
> >
> > Signed-off-by: Mas
* Alexey Budankov wrote:
> It may sound too optimistic but glibc API is expected to be backward
> compatible
> and for POSIX AIO API part too. Internal implementation also tends to evolve
> to
> better option overtime, more probably basing on modern kernel capabilities
> mentioned here: ht
On Mon, Sep 10, 2018 at 08:14:20PM +0200, Miklos Szeredi wrote:
> Why do pollable waitqueues need to disable interrupts generally?
Any waitqueue needs to disable interrupts for consistency. We
always use spin_lock_irqsave in __wake_up_common_lock() for example.
On 10/09/18 17:34, Arnaldo Carvalho de Melo wrote:
> Em Fri, Sep 07, 2018 at 11:51:16AM +0300, Adrian Hunter escreveu:
>> Commit 1c5aae7710bb ("perf machine: Create maps for x86 PTI entry
>> trampolines") revealed a problem with maps__find_symbol_by_name() that
>
> Can we have this with a Fixes: 1
On 2018/9/11 0:38, Borislav Petkov wrote:
That sentence is not needed for the same reason as above.
And select CPU_SUP_AMD
to solve the dependency issues in kernel.
No, this should say: "Since Dhyana uses AMD functionality to a large
degree, select CPU_SUP_AMD which provides that functionalit
On 09/07/2018 12:58 AM, Vincent Guittot wrote:
On Fri, 7 Sep 2018 at 09:16, Juri Lelli wrote:
On 06/09/18 16:25, Dietmar Eggemann wrote:
Hi Juri,
On 08/23/2018 11:54 PM, Juri Lelli wrote:
On 23/08/18 18:52, Dietmar Eggemann wrote:
Hi,
On 08/21/2018 01:54 AM, Miguel de Dios wrote:
On 08/1
Commit-ID: 84818af26350c245c8e1994493b7459c0822be5b
Gitweb: https://git.kernel.org/tip/84818af26350c245c8e1994493b7459c0822be5b
Author: Steven Rostedt (VMware)
AuthorDate: Mon, 10 Sep 2018 21:46:38 -0400
Committer: Ingo Molnar
CommitDate: Tue, 11 Sep 2018 08:12:00 +0200
locking/rtmutex
On Tue, Sep 11, 2018 at 09:27:45AM +0530, Anup Patel wrote:
> The list of currently defined RISC-V local interrupts will definitely grow
> based on my experience from ARM/ARM64 world.
>
> Like Thomas mentioned, we will definitely end-up having separate
> irqchip and irq_domain for RISC-V local int
* Peter Zijlstra wrote:
> On Thu, Aug 09, 2018 at 02:57:53PM +0100, Dietmar Eggemann wrote:
> > LB_BIAS allows the adjustment on how conservative load should be
> > balanced.
>
> > It is very likely that LB_BIAS' influence on load balancing can be
> > neglected (see test results below). This i
Commit-ID: ace8031099f91480799b5929b4cccf2dcacc5136
Gitweb: https://git.kernel.org/tip/ace8031099f91480799b5929b4cccf2dcacc5136
Author: zhong jiang
AuthorDate: Fri, 3 Aug 2018 20:37:32 +0800
Committer: Ingo Molnar
CommitDate: Mon, 10 Sep 2018 15:10:57 +0200
sched/topology: Make local v
Commit-ID: 44060e8a5189fd79220a94422b8249a85e91
Gitweb: https://git.kernel.org/tip/44060e8a5189fd79220a94422b8249a85e91
Author: Chao Fan
AuthorDate: Tue, 7 Aug 2018 09:57:05 +0800
Committer: Ingo Molnar
CommitDate: Mon, 10 Sep 2018 15:07:11 +0200
x86/boot/KASLR: Remove return v
Commit-ID: 07e846bace717729fd20b5d99521a5f8c7d7a9cb
Gitweb: https://git.kernel.org/tip/07e846bace717729fd20b5d99521a5f8c7d7a9cb
Author: Randy Dunlap
AuthorDate: Sun, 5 Aug 2018 20:34:05 -0700
Committer: Ingo Molnar
CommitDate: Mon, 10 Sep 2018 15:09:30 +0200
x86/doc: Fix Documentation/
Commit-ID: 2766d2ee960c52adc415931130dd6910158dd04d
Gitweb: https://git.kernel.org/tip/2766d2ee960c52adc415931130dd6910158dd04d
Author: Zubin Mithra
AuthorDate: Fri, 10 Aug 2018 08:43:14 -0700
Committer: Ingo Molnar
CommitDate: Mon, 10 Sep 2018 14:55:36 +0200
perf/x86: Add __ro_after_i
Commit-ID: b1e3a25f5879017fc50ca17f03118b26a19df49a
Gitweb: https://git.kernel.org/tip/b1e3a25f5879017fc50ca17f03118b26a19df49a
Author: He Zhe
AuthorDate: Tue, 14 Aug 2018 23:33:43 +0800
Committer: Ingo Molnar
CommitDate: Mon, 10 Sep 2018 14:47:33 +0200
x86/corruption-check: Use pr_*()
Commit-ID: ccde460b9ae5c2bd5e4742af0a7f623c2daad566
Gitweb: https://git.kernel.org/tip/ccde460b9ae5c2bd5e4742af0a7f623c2daad566
Author: He Zhe
AuthorDate: Tue, 14 Aug 2018 23:33:42 +0800
Committer: Ingo Molnar
CommitDate: Mon, 10 Sep 2018 14:47:32 +0200
x86/corruption-check: Fix panic
On Mon, Sep 10, 2018 at 06:36:52PM -0700, Atish Patra wrote:
> 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 h
On Mon, 10 Sep 2018 23:23:58 +0200,
Yu Zhao wrote:
>
> Internally, skl_init_chip() calls snd_hdac_bus_init_chip() which
> 1) sets bus->chip_init to prevent multiple entrances before device
> is stopped; 2) enables interrupt.
>
> We shouldn't use it for the purpose of resetting device only because
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
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
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
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
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
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
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: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: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 (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
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
---
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
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
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
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
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
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
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 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
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:
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>
>
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
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
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
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: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 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
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(+
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
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
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,
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
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
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
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
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
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;
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
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
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 +
..
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
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
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
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 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. */
>> +
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 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
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
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_
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
[..]
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
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 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: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 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 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
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 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
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
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
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
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
1 - 100 of 822 matches
Mail list logo
