On 10/07/18 07:09, Ryder Lee wrote:
Cleanup binding document to get rid of unsupported reference boards
for MT7623N.
Cc: John Crispin
Cc: Sean Wang
Signed-off-by: Ryder Lee
Acked-by: John Crispin
---
Documentation/devicetree/bindings/arm/mediatek.txt | 3 ---
1 file changed, 3
On 10/07/18 07:09, Ryder Lee wrote:
Normally, we didn't release this kind of baord to user. This specific
board exists only in the early stage of development inside MediaTek -
and that may confuse peoples.
Hence this patch removes related files accordingly.
Cc: John Crispin
Cc: Sean Wang
On 10/07/18 07:09, Ryder Lee wrote:
Cleanup binding document to get rid of unsupported reference boards
for MT7623N.
Cc: John Crispin
Cc: Sean Wang
Signed-off-by: Ryder Lee
Acked-by: John Crispin
---
Documentation/devicetree/bindings/arm/mediatek.txt | 3 ---
1 file changed, 3
On 10/07/18 07:09, Ryder Lee wrote:
Normally, we didn't release this kind of baord to user. This specific
board exists only in the early stage of development inside MediaTek -
and that may confuse peoples.
Hence this patch removes related files accordingly.
Cc: John Crispin
Cc: Sean Wang
> + dev freq maintainters.
>
> On Mon, Jul 9, 2018 at 3:37 AM, noman pouigt wrote:
> > folks,
> >
> > I am trying to figure out the relationship between PM QOS
> > with devfreq framework. I see this thread[1] where MyungJoo
> > talks about QOS and devfreq but that control is through
> > sysfs
> + dev freq maintainters.
>
> On Mon, Jul 9, 2018 at 3:37 AM, noman pouigt wrote:
> > folks,
> >
> > I am trying to figure out the relationship between PM QOS
> > with devfreq framework. I see this thread[1] where MyungJoo
> > talks about QOS and devfreq but that control is through
> > sysfs
* Keerthy [180621 01:18]:
> Deep enough power saving mode can result into losing context of the clock
> registers also, and they need to be restored once coming back from the power
> saving mode. Hence add functions to save/restore clock context.
Patches 1 to 3 look good to me:
Acked-by: Tony
* Keerthy [180621 01:18]:
> Deep enough power saving mode can result into losing context of the clock
> registers also, and they need to be restored once coming back from the power
> saving mode. Hence add functions to save/restore clock context.
Patches 1 to 3 look good to me:
Acked-by: Tony
Hey Peter,
Sorry for late response on this..
On 01-06-18, 13:24, Peter Ujfalusi wrote:
> If the DMA supports per descriptor metadata it can implement the attach,
> get_ptr/set_len callbacks.
>
> Client drivers must only use either attach or get_ptr/set_len to avoid
> miss configuration.
>
>
Hey Peter,
Sorry for late response on this..
On 01-06-18, 13:24, Peter Ujfalusi wrote:
> If the DMA supports per descriptor metadata it can implement the attach,
> get_ptr/set_len callbacks.
>
> Client drivers must only use either attach or get_ptr/set_len to avoid
> miss configuration.
>
>
* Faiz Abbas [180709 16:50]:
> Add clkctrl data for the m_can clocks and register it within the
> clkctrl driver
I'll apply patches 2 to 5 to omap-for-v4.19/ti-sysc. The clock
patch is trivial enough to not have to wait for Tero to be back
online.
And I'll apply the dts changes into
* Faiz Abbas [180709 16:50]:
> Add clkctrl data for the m_can clocks and register it within the
> clkctrl driver
I'll apply patches 2 to 5 to omap-for-v4.19/ti-sysc. The clock
patch is trivial enough to not have to wait for Tero to be back
online.
And I'll apply the dts changes into
Hi Prakash,
On 07/09/2018 10:12 PM, Prakash, Prashanth wrote:
Hi George,
On 7/9/2018 4:10 AM, George Cherian wrote:
Per Section 8.4.7.1.3 of ACPI 6.2, The platform provides performance
feedback via set of performance counters. To determine the actual
performance level delivered over time,
Hi Prakash,
On 07/09/2018 10:12 PM, Prakash, Prashanth wrote:
Hi George,
On 7/9/2018 4:10 AM, George Cherian wrote:
Per Section 8.4.7.1.3 of ACPI 6.2, The platform provides performance
feedback via set of performance counters. To determine the actual
performance level delivered over time,
On Mon, Jul 09, 2018 at 04:51:08PM +0300, Jan Dakinevich wrote:
> An array of pointers to SRPT contexts in ib_device is over 30KiB even
> in default case, in which an amount of contexts is 4095. The patch
> is intended to weed out large contigous allocation for non-DMA memory.
kvmalloc* doesn't
On Mon, Jul 09, 2018 at 04:51:08PM +0300, Jan Dakinevich wrote:
> An array of pointers to SRPT contexts in ib_device is over 30KiB even
> in default case, in which an amount of contexts is 4095. The patch
> is intended to weed out large contigous allocation for non-DMA memory.
kvmalloc* doesn't
On Mon, 9 Jul 2018 17:13:56 -0700
Andrew Morton wrote:
> On Sun, 8 Jul 2018 01:25:38 +1000 Nicholas Piggin wrote:
>
> > On Fri, 06 Jul 2018 13:03:55 -0400
> > Rik van Riel wrote:
> >
> > > Hello,
> > >
> > > It looks like last summer, there were 2 sets of patches
> > > in flight to fix
On Mon, 9 Jul 2018 17:13:56 -0700
Andrew Morton wrote:
> On Sun, 8 Jul 2018 01:25:38 +1000 Nicholas Piggin wrote:
>
> > On Fri, 06 Jul 2018 13:03:55 -0400
> > Rik van Riel wrote:
> >
> > > Hello,
> > >
> > > It looks like last summer, there were 2 sets of patches
> > > in flight to fix
Hi, SeongJae
Do you have any input for this regression? thanks
On 2018年06月04日 13:52, kernel test robot wrote:
>
> Greeting,
>
> FYI, we noticed a -11.2% regression of aim7.jobs-per-min due to commit:
>
>
> commit: 316ba5736c9caa5dbcd84085989862d2df57431d ("brd: Mark as
> non-rotational")
>
Hi, SeongJae
Do you have any input for this regression? thanks
On 2018年06月04日 13:52, kernel test robot wrote:
>
> Greeting,
>
> FYI, we noticed a -11.2% regression of aim7.jobs-per-min due to commit:
>
>
> commit: 316ba5736c9caa5dbcd84085989862d2df57431d ("brd: Mark as
> non-rotational")
>
* Josh Poimboeuf wrote:
> Since we switched the x86_64 default to the ORC unwinder, a lot of
> people have switched over. But this patch will reverse (or at least
> slow down) that trend, because almost nobody has the libelf devel
> packaged installed by default. So over time, it will
* Josh Poimboeuf wrote:
> Since we switched the x86_64 default to the ORC unwinder, a lot of
> people have switched over. But this patch will reverse (or at least
> slow down) that trend, because almost nobody has the libelf devel
> packaged installed by default. So over time, it will
Dave Hansen writes:
> On 07/09/2018 06:19 PM, Huang, Ying wrote:
>> Dave Hansen writes:
>>
config THP_SWAP
def_bool y
- depends on TRANSPARENT_HUGEPAGE && ARCH_WANTS_THP_SWAP
+ depends on TRANSPARENT_HUGEPAGE && ARCH_WANTS_THP_SWAP && SWAP
help
>>>
>>> This
Dave Hansen writes:
> On 07/09/2018 06:19 PM, Huang, Ying wrote:
>> Dave Hansen writes:
>>
config THP_SWAP
def_bool y
- depends on TRANSPARENT_HUGEPAGE && ARCH_WANTS_THP_SWAP
+ depends on TRANSPARENT_HUGEPAGE && ARCH_WANTS_THP_SWAP && SWAP
help
>>>
>>> This
> On 9 July 2018 at 08:47, Hongjie Fang wrote:
> > mmc_select_hs400es() calls mmc_select_bus_width() which will try to
> > set 4bit transfer mode if fail to set 8bit mode. The problem is that
> > the bus width should not be set to 4bit in HS400es mode.
>
> I guess it fails because there is
> On 9 July 2018 at 08:47, Hongjie Fang wrote:
> > mmc_select_hs400es() calls mmc_select_bus_width() which will try to
> > set 4bit transfer mode if fail to set 8bit mode. The problem is that
> > the bus width should not be set to 4bit in HS400es mode.
>
> I guess it fails because there is
Normally, we didn't release this kind of baord to user. This specific
board exists only in the early stage of development inside MediaTek -
and that may confuse peoples.
Hence this patch removes related files accordingly.
Cc: John Crispin
Cc: Sean Wang
Signed-off-by: Ryder Lee
---
On Tue, Jul 10, 2018 at 11:17:40AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the rdma tree got a conflict in:
>
> drivers/infiniband/core/uverbs_cmd.c
>
> between commit:
>
> 4fae7f170416 ("RDMA/uverbs: Fix slab-out-of-bounds in
> ib_uverbs_ex_create_flow")
>
>
Cleanup binding document to get rid of unsupported reference boards
for MT7623N.
Cc: John Crispin
Cc: Sean Wang
Signed-off-by: Ryder Lee
---
Documentation/devicetree/bindings/arm/mediatek.txt | 3 ---
1 file changed, 3 deletions(-)
diff --git
Normally, we didn't release this kind of baord to user. This specific
board exists only in the early stage of development inside MediaTek -
and that may confuse peoples.
Hence this patch removes related files accordingly.
Cc: John Crispin
Cc: Sean Wang
Signed-off-by: Ryder Lee
---
On Tue, Jul 10, 2018 at 11:17:40AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the rdma tree got a conflict in:
>
> drivers/infiniband/core/uverbs_cmd.c
>
> between commit:
>
> 4fae7f170416 ("RDMA/uverbs: Fix slab-out-of-bounds in
> ib_uverbs_ex_create_flow")
>
>
Cleanup binding document to get rid of unsupported reference boards
for MT7623N.
Cc: John Crispin
Cc: Sean Wang
Signed-off-by: Ryder Lee
---
Documentation/devicetree/bindings/arm/mediatek.txt | 3 ---
1 file changed, 3 deletions(-)
diff --git
On Sun, Jul 08, 2018 at 10:44:00PM +0200, Christoph Hellwig wrote:
> On Wed, Jul 04, 2018 at 04:21:16PM +0200, Adrian Reber wrote:
> > In file included from /usr/include/linux/signal.h:5,
> > from /usr/include/linux/aio_abi.h:32,
> > from include.c:2:
> >
On Sun, Jul 08, 2018 at 10:44:00PM +0200, Christoph Hellwig wrote:
> On Wed, Jul 04, 2018 at 04:21:16PM +0200, Adrian Reber wrote:
> > In file included from /usr/include/linux/signal.h:5,
> > from /usr/include/linux/aio_abi.h:32,
> > from include.c:2:
> >
Hi Davidlohr,
On 07/09/2018 10:09 PM, Davidlohr Bueso wrote:
On Mon, 09 Jul 2018, Manfred Spraul wrote:
@Davidlohr:
Please double check that I have taken the correct patches, and
that I didn't break anything.
Everything seems ok.
Patch 8 had an alternative patch that didn't change nowarn
Hi Davidlohr,
On 07/09/2018 10:09 PM, Davidlohr Bueso wrote:
On Mon, 09 Jul 2018, Manfred Spraul wrote:
@Davidlohr:
Please double check that I have taken the correct patches, and
that I didn't break anything.
Everything seems ok.
Patch 8 had an alternative patch that didn't change nowarn
Hi, Paul and Peter,
I think we find the real root cause, READ_ONCE() doesn't need any
barriers, the problematic code is queued_spin_lock_slowpath() in
kernel/locking/qspinlock.c:
if (old & _Q_TAIL_MASK) {
prev = decode_tail(old);
/* Link @node into the
Hi, Paul and Peter,
I think we find the real root cause, READ_ONCE() doesn't need any
barriers, the problematic code is queued_spin_lock_slowpath() in
kernel/locking/qspinlock.c:
if (old & _Q_TAIL_MASK) {
prev = decode_tail(old);
/* Link @node into the
On Tue, Jul 10, 2018 at 12:47:49PM +0900, Masahiro Yamada wrote:
> Hi.
>
>
> 2018-07-10 11:29 GMT+09:00 Josh Poimboeuf :
> > On Tue, Jul 10, 2018 at 10:35:16AM +0900, Masahiro Yamada wrote:
> >> Currently, users are allowed to enable STACK_VALIDATION regardless
> >> of the compiler capability.
On Tue, Jul 10, 2018 at 12:47:49PM +0900, Masahiro Yamada wrote:
> Hi.
>
>
> 2018-07-10 11:29 GMT+09:00 Josh Poimboeuf :
> > On Tue, Jul 10, 2018 at 10:35:16AM +0900, Masahiro Yamada wrote:
> >> Currently, users are allowed to enable STACK_VALIDATION regardless
> >> of the compiler capability.
On Tue, Jul 10, 2018 at 02:05:12PM +1000, Stephen Rothwell wrote:
> Hi Jason,
>
> On Mon, 9 Jul 2018 21:41:57 -0600 Jason Gunthorpe wrote:
> >
> > What compiler is producing these? I got nothing from 0-day build
> > service or my local gcc-7..
>
> The x86 compiler is a v7.3.1 cross compiler
On Tue, Jul 10, 2018 at 02:05:12PM +1000, Stephen Rothwell wrote:
> Hi Jason,
>
> On Mon, 9 Jul 2018 21:41:57 -0600 Jason Gunthorpe wrote:
> >
> > What compiler is producing these? I got nothing from 0-day build
> > service or my local gcc-7..
>
> The x86 compiler is a v7.3.1 cross compiler
Hi Jason,
On Mon, 9 Jul 2018 21:41:57 -0600 Jason Gunthorpe wrote:
>
> What compiler is producing these? I got nothing from 0-day build
> service or my local gcc-7..
The x86 compiler is a v7.3.1 cross compiler hosted on PowerPC LE and
built from sources.
> They are false positives and I guess
Hi Jason,
On Mon, 9 Jul 2018 21:41:57 -0600 Jason Gunthorpe wrote:
>
> What compiler is producing these? I got nothing from 0-day build
> service or my local gcc-7..
The x86 compiler is a v7.3.1 cross compiler hosted on PowerPC LE and
built from sources.
> They are false positives and I guess
On 07/09/2018 07:14 PM, H.J. Lu wrote:
>> I'd really want to see this reproduced without KASLR to make the oops
>> easier to read. It would also be handy to try your workload with all
>> the pedantic debugging: KASAN, slab debugging, DEBUG_PAGE_ALLOC, etc...
>> and see if it still triggers.
> How
On 07/09/2018 07:14 PM, H.J. Lu wrote:
>> I'd really want to see this reproduced without KASLR to make the oops
>> easier to read. It would also be handy to try your workload with all
>> the pedantic debugging: KASAN, slab debugging, DEBUG_PAGE_ALLOC, etc...
>> and see if it still triggers.
> How
Hi.
2018-07-10 11:29 GMT+09:00 Josh Poimboeuf :
> On Tue, Jul 10, 2018 at 10:35:16AM +0900, Masahiro Yamada wrote:
>> Currently, users are allowed to enable STACK_VALIDATION regardless
>> of the compiler capability. The top-level Makefile warns or breaks
>> the build if it turns out that the
Hi.
2018-07-10 11:29 GMT+09:00 Josh Poimboeuf :
> On Tue, Jul 10, 2018 at 10:35:16AM +0900, Masahiro Yamada wrote:
>> Currently, users are allowed to enable STACK_VALIDATION regardless
>> of the compiler capability. The top-level Makefile warns or breaks
>> the build if it turns out that the
Hi,
On 07/09/2018 04:28 PM, Rafael J. Wysocki wrote:
On Mon, Jul 9, 2018 at 10:45 PM, Jeremy Linton wrote:
Hi,
First thanks for the patch..
On 07/08/2018 04:14 AM, Rafael J. Wysocki wrote:
On Monday, July 2, 2018 11:41:42 PM CEST Jeremy Linton wrote:
Hi,
I'm experiencing two problems
Hi,
On 07/09/2018 04:28 PM, Rafael J. Wysocki wrote:
On Mon, Jul 9, 2018 at 10:45 PM, Jeremy Linton wrote:
Hi,
First thanks for the patch..
On 07/08/2018 04:14 AM, Rafael J. Wysocki wrote:
On Monday, July 2, 2018 11:41:42 PM CEST Jeremy Linton wrote:
Hi,
I'm experiencing two problems
On Tue, Jul 10, 2018 at 11:33:42AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the rdma tree, today's linux-next build (x86_64
> allmodconfig) produced these warnings:
>
> In file included from include/linux/printk.h:336:0,
> from include/linux/kernel.h:14,
>
On Tue, Jul 10, 2018 at 11:33:42AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the rdma tree, today's linux-next build (x86_64
> allmodconfig) produced these warnings:
>
> In file included from include/linux/printk.h:336:0,
> from include/linux/kernel.h:14,
>
On Mon, 2018-07-09 at 17:38 -0400, Rik van Riel wrote:
>
> I added your code, and Signed-off-By in patch
> 1 for version 5 of the series.
No objection, but no need (like taking credit for fixing a typo:).
On Mon, 2018-07-09 at 17:38 -0400, Rik van Riel wrote:
>
> I added your code, and Signed-off-By in patch
> 1 for version 5 of the series.
No objection, but no need (like taking credit for fixing a typo:).
For Synopsys DesignWare 8250 uart which version >= 4.00a, there's a
valid divisor latch fraction register. The fractional divisor width is
4bits ~ 6bits.
Now the preparation is done, it's easy to add the feature support.
This patch firstly tries to get the fractional divisor width during
probe,
For Synopsys DesignWare 8250 uart which version >= 4.00a, there's a
valid divisor latch fraction register. The fractional divisor width is
4bits ~ 6bits.
Now the preparation is done, it's easy to add the feature support.
This patch firstly tries to get the fractional divisor width during
probe,
Some drivers could call serial8250_do_set_divisor() to complete its
own set_divisor routine. Export this symbol for code reusing.
Signed-off-by: Jisheng Zhang
---
drivers/tty/serial/8250/8250_port.c | 5 +++--
include/linux/serial_8250.h | 3 +++
2 files changed, 6 insertions(+), 2
Some drivers could call serial8250_do_set_divisor() to complete its
own set_divisor routine. Export this symbol for code reusing.
Signed-off-by: Jisheng Zhang
---
drivers/tty/serial/8250/8250_port.c | 5 +++--
include/linux/serial_8250.h | 3 +++
2 files changed, 6 insertions(+), 2
Add these two hooks so that they can be overridden with driver specific
implementations.
Signed-off-by: Jisheng Zhang
Reviewed-by: Andy Shevchenko
---
drivers/tty/serial/8250/8250_core.c | 4
drivers/tty/serial/8250/8250_port.c | 27 +++
Add these two hooks so that they can be overridden with driver specific
implementations.
Signed-off-by: Jisheng Zhang
Reviewed-by: Andy Shevchenko
---
drivers/tty/serial/8250/8250_core.c | 4
drivers/tty/serial/8250/8250_port.c | 27 +++
For Synopsys DesignWare 8250 uart which version >= 4.00a, there's a
valid divisor latch fraction register. The fractional divisor width is
4bits ~ 6bits.
patch1 introduces necessary hooks to 8250 core.
patch2 exports serial8250_do_set_divisor()
patch3 implements the fractional divisor support for
For Synopsys DesignWare 8250 uart which version >= 4.00a, there's a
valid divisor latch fraction register. The fractional divisor width is
4bits ~ 6bits.
patch1 introduces necessary hooks to 8250 core.
patch2 exports serial8250_do_set_divisor()
patch3 implements the fractional divisor support for
On Mon, Jul 09, 2018 at 10:07:16PM -0400, Steven Rostedt wrote:
> On Tue, 10 Jul 2018 10:25:16 +1000
> "Tobin C. Harding" wrote:
>
> > Since I'm a massive noob I did not realise that since v7 of this set was
> > applied to random-next already that doing incremental versions was
> > pointless.
>
On Mon, Jul 09, 2018 at 10:07:16PM -0400, Steven Rostedt wrote:
> On Tue, 10 Jul 2018 10:25:16 +1000
> "Tobin C. Harding" wrote:
>
> > Since I'm a massive noob I did not realise that since v7 of this set was
> > applied to random-next already that doing incremental versions was
> > pointless.
>
On 2018/7/10 1:06, Mike Christie wrote:
On 07/06/2018 08:28 PM, Xiubo Li wrote:
On 2018/7/7 2:23, Mike Christie wrote:
On 07/05/2018 09:57 PM, xiu...@redhat.com wrote:
static irqreturn_t uio_interrupt(int irq, void *dev_id)
{
struct uio_device *idev = (struct uio_device *)dev_id;
On 2018/7/10 1:06, Mike Christie wrote:
On 07/06/2018 08:28 PM, Xiubo Li wrote:
On 2018/7/7 2:23, Mike Christie wrote:
On 07/05/2018 09:57 PM, xiu...@redhat.com wrote:
static irqreturn_t uio_interrupt(int irq, void *dev_id)
{
struct uio_device *idev = (struct uio_device *)dev_id;
On 2018/7/10 0:40, Mike Christie wrote:
On 07/06/2018 08:47 PM, Xiubo Li wrote:
On 2018/7/7 2:58, Mike Christie wrote:
On 07/05/2018 09:57 PM, xiu...@redhat.com wrote:
void uio_event_notify(struct uio_info *info)
{
-struct uio_device *idev = info->uio_dev;
+struct uio_device
On 2018/7/10 0:40, Mike Christie wrote:
On 07/06/2018 08:47 PM, Xiubo Li wrote:
On 2018/7/7 2:58, Mike Christie wrote:
On 07/05/2018 09:57 PM, xiu...@redhat.com wrote:
void uio_event_notify(struct uio_info *info)
{
-struct uio_device *idev = info->uio_dev;
+struct uio_device
On Tue, Jul 10, 2018 at 10:35:16AM +0900, Masahiro Yamada wrote:
> Currently, users are allowed to enable STACK_VALIDATION regardless
> of the compiler capability. The top-level Makefile warns or breaks
> the build if it turns out that the host compiler cannot link libelf.
>
> Move the libelf
On Tue, Jul 10, 2018 at 10:35:16AM +0900, Masahiro Yamada wrote:
> Currently, users are allowed to enable STACK_VALIDATION regardless
> of the compiler capability. The top-level Makefile warns or breaks
> the build if it turns out that the host compiler cannot link libelf.
>
> Move the libelf
From: Yandong Zhao
Operations for contexts where we do not want to do any checks for
preemptions. Unless strictly necessary, always use this_cpu_read()
instead. Because of the kernel_neon_busy here we have to make sure
that it is the current cpu.
Signed-off-by: Yandong Zhao
---
From: Yandong Zhao
Operations for contexts where we do not want to do any checks for
preemptions. Unless strictly necessary, always use this_cpu_read()
instead. Because of the kernel_neon_busy here we have to make sure
that it is the current cpu.
Signed-off-by: Yandong Zhao
---
On Wed, 2018-07-04 at 16:01 +0200, Thomas Gleixner wrote:
> On Wed, 4 Jul 2018, Yang, Bin wrote:
> > e820 table:
> > =
> >
> > [0.00] BIOS-e820: [mem 0x-
> > 0x0009fbff]
> > usable
> > [0.00] BIOS-e820: [mem 0x0009fc00-
> >
On Wed, 2018-07-04 at 16:01 +0200, Thomas Gleixner wrote:
> On Wed, 4 Jul 2018, Yang, Bin wrote:
> > e820 table:
> > =
> >
> > [0.00] BIOS-e820: [mem 0x-
> > 0x0009fbff]
> > usable
> > [0.00] BIOS-e820: [mem 0x0009fc00-
> >
syzbot has found a reproducer for the following crash on:
HEAD commit:092150a25cb7 Merge branch 'for-linus' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16627cc240
kernel config:
syzbot has found a reproducer for the following crash on:
HEAD commit:092150a25cb7 Merge branch 'for-linus' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16627cc240
kernel config:
Andrew Morton wrote:
> On Sat, 7 Jul 2018 08:26:32 +0900 Tetsuo Handa
> wrote:
>
> > Hello Andrew,
> >
> > It seems that syzbot (experimentally ?) restarted testing linux-next.
> >
> > May I ask you to carry temporarily debug printk() patch at
> >
On Mon, Jul 9, 2018 at 5:44 PM, Dave Hansen wrote:
> ... cc'ing a few folks who I know have been looking at this code
> lately. The full oops is below if any of you want to take a look.
>
> OK, well, annotating the disassembly a bit:
>
>> (gdb) disass free_pages_and_swap_cache
>> Dump of
Andrew Morton wrote:
> On Sat, 7 Jul 2018 08:26:32 +0900 Tetsuo Handa
> wrote:
>
> > Hello Andrew,
> >
> > It seems that syzbot (experimentally ?) restarted testing linux-next.
> >
> > May I ask you to carry temporarily debug printk() patch at
> >
On Mon, Jul 9, 2018 at 5:44 PM, Dave Hansen wrote:
> ... cc'ing a few folks who I know have been looking at this code
> lately. The full oops is below if any of you want to take a look.
>
> OK, well, annotating the disassembly a bit:
>
>> (gdb) disass free_pages_and_swap_cache
>> Dump of
On Tue, 10 Jul 2018 10:25:19 +1000
"Tobin C. Harding" wrote:
> Recently boot parameter 'debug_boot_weak_hash' was added. Latter
> discussion on LKML developed more descriptive documentation but due to
> the programmers lack of understanding (*cough* me) on how linux-next
> works these
On Tue, 10 Jul 2018 10:25:19 +1000
"Tobin C. Harding" wrote:
> Recently boot parameter 'debug_boot_weak_hash' was added. Latter
> discussion on LKML developed more descriptive documentation but due to
> the programmers lack of understanding (*cough* me) on how linux-next
> works these
On Tue, 10 Jul 2018 10:25:18 +1000
"Tobin C. Harding" wrote:
> Recently boot variable 'debug_boot_weak_hash' was added (by me). In a
> classic case of cargo cult programming the novice developer added a
> macro call to EXPORT_SYMBOL(). This is wrong and was pointed out on
> LKML. As pointed
On Tue, 10 Jul 2018 10:25:18 +1000
"Tobin C. Harding" wrote:
> Recently boot variable 'debug_boot_weak_hash' was added (by me). In a
> classic case of cargo cult programming the novice developer added a
> macro call to EXPORT_SYMBOL(). This is wrong and was pointed out on
> LKML. As pointed
Hi Andy,
On Mon, 9 Jul 2018 16:32:41 +0800 Jisheng Zhang wrote:
> Hi Andy,
>
> On Mon, 9 Jul 2018 16:23:15 +0800 Jisheng Zhang wrote:
>
> > For Synopsys DesignWare 8250 uart which version >= 4.00a, there's a
> > valid divisor latch fraction register. The fractional divisor width is
> > 4bits ~
Hi Andy,
On Mon, 9 Jul 2018 16:32:41 +0800 Jisheng Zhang wrote:
> Hi Andy,
>
> On Mon, 9 Jul 2018 16:23:15 +0800 Jisheng Zhang wrote:
>
> > For Synopsys DesignWare 8250 uart which version >= 4.00a, there's a
> > valid divisor latch fraction register. The fractional divisor width is
> > 4bits ~
On Tue, 10 Jul 2018 10:25:16 +1000
"Tobin C. Harding" wrote:
> Since I'm a massive noob I did not realise that since v7 of this set was
> applied to random-next already that doing incremental versions was
> pointless.
I wouldn't say you are a noob anymore. You are making the same types of
On Tue, 10 Jul 2018 10:25:16 +1000
"Tobin C. Harding" wrote:
> Since I'm a massive noob I did not realise that since v7 of this set was
> applied to random-next already that doing incremental versions was
> pointless.
I wouldn't say you are a noob anymore. You are making the same types of
On Tue, 10 Jul 2018 10:25:17 +1000
"Tobin C. Harding" wrote:
> Currently we are casting an argument to the macro min_t(). This is
> unnecessary since the macro already includes a cast.
>
> Remove unnecessary cast from argument to macro min_t()
>
> Signed-off-by: Tobin C. Harding
On Tue, 10 Jul 2018 10:25:17 +1000
"Tobin C. Harding" wrote:
> Currently we are casting an argument to the macro min_t(). This is
> unnecessary since the macro already includes a cast.
>
> Remove unnecessary cast from argument to macro min_t()
>
> Signed-off-by: Tobin C. Harding
On 07/09/2018 06:19 PM, Huang, Ying wrote:
> Dave Hansen writes:
>
>>> config THP_SWAP
>>> def_bool y
>>> - depends on TRANSPARENT_HUGEPAGE && ARCH_WANTS_THP_SWAP
>>> + depends on TRANSPARENT_HUGEPAGE && ARCH_WANTS_THP_SWAP && SWAP
>>> help
>>
>> This seems like a bug-fix. Is there
On 07/09/2018 06:19 PM, Huang, Ying wrote:
> Dave Hansen writes:
>
>>> config THP_SWAP
>>> def_bool y
>>> - depends on TRANSPARENT_HUGEPAGE && ARCH_WANTS_THP_SWAP
>>> + depends on TRANSPARENT_HUGEPAGE && ARCH_WANTS_THP_SWAP && SWAP
>>> help
>>
>> This seems like a bug-fix. Is there
On Mon, 9 Jul 2018, Andrew Morton wrote:
> > When perf profiling a wide variety of different workloads, it was found
> > that vmacache_find() had higher than expected cost: up to 0.08% of cpu
> > utilization in some cases. This was found to rival other core VM
> > functions such as
On Mon, 2018-07-09 at 17:33 -0700, Linus Torvalds wrote:
> On Mon, Jul 9, 2018 at 5:29 PM Benjamin Herrenschmidt
> wrote:
> >
> > For devices with a class, we create a "glue" directory between
> > the parent device and the new device with the class name.
> >
> > This directory is never
On Mon, 9 Jul 2018, Andrew Morton wrote:
> > When perf profiling a wide variety of different workloads, it was found
> > that vmacache_find() had higher than expected cost: up to 0.08% of cpu
> > utilization in some cases. This was found to rival other core VM
> > functions such as
On Mon, 2018-07-09 at 17:33 -0700, Linus Torvalds wrote:
> On Mon, Jul 9, 2018 at 5:29 PM Benjamin Herrenschmidt
> wrote:
> >
> > For devices with a class, we create a "glue" directory between
> > the parent device and the new device with the class name.
> >
> > This directory is never
Currently, users are allowed to enable STACK_VALIDATION regardless
of the compiler capability. The top-level Makefile warns or breaks
the build if it turns out that the host compiler cannot link libelf.
Move the libelf test to Kconfig so that users can enable the feature
only when the host
Currently, users are allowed to enable STACK_VALIDATION regardless
of the compiler capability. The top-level Makefile warns or breaks
the build if it turns out that the host compiler cannot link libelf.
Move the libelf test to Kconfig so that users can enable the feature
only when the host
Hi all,
After merging the rdma tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:
In file included from include/linux/printk.h:336:0,
from include/linux/kernel.h:14,
from arch/x86/include/asm/percpu.h:45,
from
Hi all,
After merging the rdma tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:
In file included from include/linux/printk.h:336:0,
from include/linux/kernel.h:14,
from arch/x86/include/asm/percpu.h:45,
from
1 - 100 of 1608 matches
Mail list logo
