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
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
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
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
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
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
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
---
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
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
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
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
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
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
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
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
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
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
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,
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
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
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,
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
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
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,
[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
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
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;
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;
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:
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>
>
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 files
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 files
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
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
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: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: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 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
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
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
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
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();
^~~
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();
^~~
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
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
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
---
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
---
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
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
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
d [-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 include ?
I used the version of the tty tre
d [-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 include ?
I used the version of the tty tre
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
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
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.
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.
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;
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
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
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
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
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
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
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 +
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
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
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
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
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
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
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
>
>
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
>
>
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
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
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
> 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, , _err, htons(ETH_P_IPV6),
>> + offset) < 0) {
>> +if (!csum_err) /* ignore csum errors. */
>> +
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
> 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, , _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
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
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
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
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
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:
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,
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
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
1 - 100 of 1628 matches
Mail list logo
