On Wed, 22 Aug 2018 22:03:40 -0700
Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 9:33 PM Nicholas Piggin wrote:
> >
> > I think it was quite well understood and fixed here, a145abf12c9 but
> > again that was before I really started looking at it.
>
> You don't understand the problem.
More
On Wed, 22 Aug 2018 22:03:40 -0700
Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 9:33 PM Nicholas Piggin wrote:
> >
> > I think it was quite well understood and fixed here, a145abf12c9 but
> > again that was before I really started looking at it.
>
> You don't understand the problem.
More
On 23 August 2018 at 10:48, Masahiro Yamada
wrote:
> Hi Jassi,
>
>
> 2018-08-21 19:44 GMT+09:00 Jassi Brar :
>> On 21 August 2018 at 15:17, Masahiro Yamada
>> wrote:
>>> (+CC Rob, DT, LKML)
>>>
>>> I forgot to CC this to DT community...
>>>
>>>
>>> 2018-08-21 18:30 GMT+09:00 Masahiro Yamada :
On 23 August 2018 at 10:48, Masahiro Yamada
wrote:
> Hi Jassi,
>
>
> 2018-08-21 19:44 GMT+09:00 Jassi Brar :
>> On 21 August 2018 at 15:17, Masahiro Yamada
>> wrote:
>>> (+CC Rob, DT, LKML)
>>>
>>> I forgot to CC this to DT community...
>>>
>>>
>>> 2018-08-21 18:30 GMT+09:00 Masahiro Yamada :
Hi,
On Wed, Aug 22, 2018 at 03:07:04PM +0900, Dae R. Jeong wrote:
> Reporting the crash: KASAN: null-ptr-deref Write in binder_update_page_range
>
> This crash has been found in v4.18-rc3 using RaceFuzzer (a modified
> version of Syzkaller), which we describe more at the end of this
> report.
>
Hi,
On Wed, Aug 22, 2018 at 03:07:04PM +0900, Dae R. Jeong wrote:
> Reporting the crash: KASAN: null-ptr-deref Write in binder_update_page_range
>
> This crash has been found in v4.18-rc3 using RaceFuzzer (a modified
> version of Syzkaller), which we describe more at the end of this
> report.
>
From: John Hubbard
KASAN reports a use-after-free during startup, in mei_cl_write:
BUG: KASAN: use-after-free in mei_cl_write+0x601/0x870 [mei]
(drivers/misc/mei/client.c:1770)
This is caused by commit 98e70866aacb ("mei: add support for variable
length mei headers."), which changed
From: John Hubbard
KASAN reports a use-after-free during startup, in mei_cl_write:
BUG: KASAN: use-after-free in mei_cl_write+0x601/0x870 [mei]
(drivers/misc/mei/client.c:1770)
This is caused by commit 98e70866aacb ("mei: add support for variable
length mei headers."), which changed
On Wed, 2018-08-22 at 22:11 -0700, Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 9:54 PM Benjamin Herrenschmidt
> wrote:
> >
> >
> > So we do need a different flush instruction for the page tables vs. the
> > normal TLB pages.
>
> Right. ARM wants it too. x86 is odd in that a regular
On Wed, 2018-08-22 at 22:11 -0700, Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 9:54 PM Benjamin Herrenschmidt
> wrote:
> >
> >
> > So we do need a different flush instruction for the page tables vs. the
> > normal TLB pages.
>
> Right. ARM wants it too. x86 is odd in that a regular
On Wed, Aug 22, 2018 at 10:11 PM Linus Torvalds
wrote:
>
> So instead, when you get to the actual "tlb_flush(tlb)", you do
> exactly that - flush the tlb. And the mmu_gather structure shows you
> how much you need to flush. If you see that "freed_tables" is set,
> then you know that you need to
On Wed, Aug 22, 2018 at 10:11 PM Linus Torvalds
wrote:
>
> So instead, when you get to the actual "tlb_flush(tlb)", you do
> exactly that - flush the tlb. And the mmu_gather structure shows you
> how much you need to flush. If you see that "freed_tables" is set,
> then you know that you need to
Hi Jassi,
2018-08-21 19:44 GMT+09:00 Jassi Brar :
> On 21 August 2018 at 15:17, Masahiro Yamada
> wrote:
>> (+CC Rob, DT, LKML)
>>
>> I forgot to CC this to DT community...
>>
>>
>> 2018-08-21 18:30 GMT+09:00 Masahiro Yamada :
>>> The MIO DMAC (Media IO DMA Controller) is used in UniPhier LD4,
Hi Jassi,
2018-08-21 19:44 GMT+09:00 Jassi Brar :
> On 21 August 2018 at 15:17, Masahiro Yamada
> wrote:
>> (+CC Rob, DT, LKML)
>>
>> I forgot to CC this to DT community...
>>
>>
>> 2018-08-21 18:30 GMT+09:00 Masahiro Yamada :
>>> The MIO DMAC (Media IO DMA Controller) is used in UniPhier LD4,
On Wed, 22 Aug 2018 21:54:48 -0700
Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 9:16 PM Nicholas Piggin wrote:
> >
> > On Wed, 22 Aug 2018 20:35:16 -0700
> > Linus Torvalds wrote:
> > >
> > > And yes, those lazy tlbs are all kernel threads, but they can still
> > > speculatively load user
On Wed, 22 Aug 2018 21:54:48 -0700
Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 9:16 PM Nicholas Piggin wrote:
> >
> > On Wed, 22 Aug 2018 20:35:16 -0700
> > Linus Torvalds wrote:
> > >
> > > And yes, those lazy tlbs are all kernel threads, but they can still
> > > speculatively load user
Commit d70f2a14b72a4 ("include/linux/sched/mm.h: uninline
mmdrop_async(), etc") ignored the return value of arch_dup_mmap(). As a
result, on x86, a failure to duplicate the LDT (e.g., due to memory
allocation error), would leave the duplicated memory mapping in an
inconsistent state.
Fix by
Commit d70f2a14b72a4 ("include/linux/sched/mm.h: uninline
mmdrop_async(), etc") ignored the return value of arch_dup_mmap(). As a
result, on x86, a failure to duplicate the LDT (e.g., due to memory
allocation error), would leave the duplicated memory mapping in an
inconsistent state.
Fix by
On Wed, Aug 22, 2018 at 9:54 PM Benjamin Herrenschmidt wrote:
>
>
> So we do need a different flush instruction for the page tables vs. the
> normal TLB pages.
Right. ARM wants it too. x86 is odd in that a regular "invlpg" already
invalidates all the internal tlb cache nodes.
So the "new world
On Wed, Aug 22, 2018 at 9:54 PM Benjamin Herrenschmidt wrote:
>
>
> So we do need a different flush instruction for the page tables vs. the
> normal TLB pages.
Right. ARM wants it too. x86 is odd in that a regular "invlpg" already
invalidates all the internal tlb cache nodes.
So the "new world
ccing Maurizio because he was working on the same issue.
On 08/22/2018 12:37 PM, Laura Abbott wrote:
> Fedora got a bug report of a crash with iSCSI:
>
> kernel BUG at include/linux/scatterlist.h:143!
> ...
> RIP: 0010:iscsit_do_crypto_hash_buf+0x154/0x180 [iscsi_target_mod]
> ...
> Call Trace:
ccing Maurizio because he was working on the same issue.
On 08/22/2018 12:37 PM, Laura Abbott wrote:
> Fedora got a bug report of a crash with iSCSI:
>
> kernel BUG at include/linux/scatterlist.h:143!
> ...
> RIP: 0010:iscsit_do_crypto_hash_buf+0x154/0x180 [iscsi_target_mod]
> ...
> Call Trace:
On Wed, Aug 22, 2018 at 9:33 PM Nicholas Piggin wrote:
>
> I think it was quite well understood and fixed here, a145abf12c9 but
> again that was before I really started looking at it.
You don't understand the problem.
All the x86 people thought WE ALREADY DID THAT.
Because we had done this all
On Wed, Aug 22, 2018 at 9:33 PM Nicholas Piggin wrote:
>
> I think it was quite well understood and fixed here, a145abf12c9 but
> again that was before I really started looking at it.
You don't understand the problem.
All the x86 people thought WE ALREADY DID THAT.
Because we had done this all
On Wed, Aug 22, 2018 at 9:16 PM Nicholas Piggin wrote:
>
> On Wed, 22 Aug 2018 20:35:16 -0700
> Linus Torvalds wrote:
> >
> > And yes, those lazy tlbs are all kernel threads, but they can still
> > speculatively load user addresses.
>
> So?
>
> If the arch does not shoot those all down after the
On Wed, Aug 22, 2018 at 9:16 PM Nicholas Piggin wrote:
>
> On Wed, 22 Aug 2018 20:35:16 -0700
> Linus Torvalds wrote:
> >
> > And yes, those lazy tlbs are all kernel threads, but they can still
> > speculatively load user addresses.
>
> So?
>
> If the arch does not shoot those all down after the
On Wed, 2018-08-22 at 20:59 -0700, Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 8:45 PM Nicholas Piggin wrote:
> >
> > powerpc/radix has no such issue, it already does this tracking.
>
> Yeah, I now realize that this was why you wanted to add that hacky
> thing to the generic code, so that
On Wed, 2018-08-22 at 20:59 -0700, Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 8:45 PM Nicholas Piggin wrote:
> >
> > powerpc/radix has no such issue, it already does this tracking.
>
> Yeah, I now realize that this was why you wanted to add that hacky
> thing to the generic code, so that
On Wed, 22 Aug 2018 20:59:46 -0700
Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 8:45 PM Nicholas Piggin wrote:
> >
> > powerpc/radix has no such issue, it already does this tracking.
>
> Yeah, I now realize that this was why you wanted to add that hacky
> thing to the generic code, so
On Wed, 22 Aug 2018 20:59:46 -0700
Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 8:45 PM Nicholas Piggin wrote:
> >
> > powerpc/radix has no such issue, it already does this tracking.
>
> Yeah, I now realize that this was why you wanted to add that hacky
> thing to the generic code, so
Business as usual -- the bulk of our changes are to devicetree files
with new hardware support, new SoCs and platforms, and new board types.
New SoCs/platforms:
- Raspberry Pi Compute Module (CM1) and IO board
- i.MX6SSL from NXP
- Renesas RZ/N1D SoC (R9A06G032), Dual Cortex-A7 with Ethernet, CAN
Business as usual -- the bulk of our changes are to devicetree files
with new hardware support, new SoCs and platforms, and new board types.
New SoCs/platforms:
- Raspberry Pi Compute Module (CM1) and IO board
- i.MX6SSL from NXP
- Renesas RZ/N1D SoC (R9A06G032), Dual Cortex-A7 with Ethernet, CAN
We keep these separate since some files are shared and conflict-prone,
but there isn't really much to write about here.
Some of the churnier pieces is for the Aspeed platforms, which did an
overdue refresh of the defconfig, and enabled USB gadget and some
drivers from there. Most of the rest are
We keep these separate since some files are shared and conflict-prone,
but there isn't really much to write about here.
Some of the churnier pieces is for the Aspeed platforms, which did an
overdue refresh of the defconfig, and enabled USB gadget and some
drivers from there. Most of the rest are
Some of the larger changes this merge window:
- Removal of drivers for Exynos5440, a Samsung SoC that never saw
widespread use.
- Uniphier support for USB3 and SPI reset handling
- Syste control and SRAM drivers and bindings for Allwinner platforms
- Qualcomm AOSS (Always-on subsystem) reset
Most of the SoC updates in this cycle are cleanups and moves to more
modern infrastructure:
- Davinci was moved to common clock framework
- OMAP1-based Amstrad E3 "Superphone" saw a bunch of cleanups to the
keyboard interface (bitbanged AT keyboard via GPIO).
- Removal of some stale code for
Hi Linus,
Another medium-sized batch of ARM updates this release cycle. Not a
large number of new platforms in this release, but there are a few --
from Renesas and TI in particular.
790 patches this time around, 173 authors. 26531 lines added and 13363
removed -- very close to the size of last
Some of the larger changes this merge window:
- Removal of drivers for Exynos5440, a Samsung SoC that never saw
widespread use.
- Uniphier support for USB3 and SPI reset handling
- Syste control and SRAM drivers and bindings for Allwinner platforms
- Qualcomm AOSS (Always-on subsystem) reset
Most of the SoC updates in this cycle are cleanups and moves to more
modern infrastructure:
- Davinci was moved to common clock framework
- OMAP1-based Amstrad E3 "Superphone" saw a bunch of cleanups to the
keyboard interface (bitbanged AT keyboard via GPIO).
- Removal of some stale code for
Hi Linus,
Another medium-sized batch of ARM updates this release cycle. Not a
large number of new platforms in this release, but there are a few --
from Renesas and TI in particular.
790 patches this time around, 173 authors. 26531 lines added and 13363
removed -- very close to the size of last
On 8/22/18 8:54 PM, Anup Patel wrote:
On Wed, Aug 22, 2018 at 11:33 AM, Christoph Hellwig wrote:
On Tue, Aug 21, 2018 at 10:34:38PM +0530, Anup Patel wrote:
The cpu_operations is certainly required because SOC vendors will add
vendor-specific mechanism to selectively bringing-up CPUs/HARTs
On 8/22/18 8:54 PM, Anup Patel wrote:
On Wed, Aug 22, 2018 at 11:33 AM, Christoph Hellwig wrote:
On Tue, Aug 21, 2018 at 10:34:38PM +0530, Anup Patel wrote:
The cpu_operations is certainly required because SOC vendors will add
vendor-specific mechanism to selectively bringing-up CPUs/HARTs
On Wed, 22 Aug 2018 20:35:16 -0700
Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 8:31 PM Nicholas Piggin wrote:
> >
> >
> > So that leaves speculative operations. I don't see where the problem is
> > with those either -- this shortcut needs to ensure there are no other
> > *non speculative*
On Wed, 22 Aug 2018 20:35:16 -0700
Linus Torvalds wrote:
> On Wed, Aug 22, 2018 at 8:31 PM Nicholas Piggin wrote:
> >
> >
> > So that leaves speculative operations. I don't see where the problem is
> > with those either -- this shortcut needs to ensure there are no other
> > *non speculative*
On Thu, 23 Aug 2018, kernel test robot wrote:
FYI, we noticed the following commit (built with gcc-7):
commit: 296ba26b6681b6e07ed419b3004647167cb17f61 ("ipc: drop ipc_lock()")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
I suspect this is because that commit
On Thu, 23 Aug 2018, kernel test robot wrote:
FYI, we noticed the following commit (built with gcc-7):
commit: 296ba26b6681b6e07ed419b3004647167cb17f61 ("ipc: drop ipc_lock()")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
I suspect this is because that commit
On Wed, Aug 22, 2018 at 8:45 PM Nicholas Piggin wrote:
>
> powerpc/radix has no such issue, it already does this tracking.
Yeah, I now realize that this was why you wanted to add that hacky
thing to the generic code, so that you can add the tlb_flush_pgtable()
call.
I thought it was because
On Wed, Aug 22, 2018 at 8:45 PM Nicholas Piggin wrote:
>
> powerpc/radix has no such issue, it already does this tracking.
Yeah, I now realize that this was why you wanted to add that hacky
thing to the generic code, so that you can add the tlb_flush_pgtable()
call.
I thought it was because
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 815f0ddb346c196018d4d8f8f55c12b83da1de3f
commit: 0fbe9a245c60bedebb6dd329966f463bb724450a microblaze: add endianness
options to LDFLAGS instead of LD
date: 4 weeks ago
config: microblaze-allmodconfig
On 08/22/18 at 06:23pm, Dave Young wrote:
> On 08/21/18 at 03:39pm, Ard Biesheuvel wrote:
> > On 9 August 2018 at 11:13, Dave Young wrote:
> > > On 08/09/18 at 09:33am, Mike Galbraith wrote:
> > >> On Thu, 2018-08-09 at 12:21 +0800, Dave Young wrote:
> > >> > Hi Mike,
> > >> >
> > >> > Thanks for
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 815f0ddb346c196018d4d8f8f55c12b83da1de3f
commit: 0fbe9a245c60bedebb6dd329966f463bb724450a microblaze: add endianness
options to LDFLAGS instead of LD
date: 4 weeks ago
config: microblaze-allmodconfig
On 08/22/18 at 06:23pm, Dave Young wrote:
> On 08/21/18 at 03:39pm, Ard Biesheuvel wrote:
> > On 9 August 2018 at 11:13, Dave Young wrote:
> > > On 08/09/18 at 09:33am, Mike Galbraith wrote:
> > >> On Thu, 2018-08-09 at 12:21 +0800, Dave Young wrote:
> > >> > Hi Mike,
> > >> >
> > >> > Thanks for
On Wed, 22 Aug 2018 17:55:27 +0200
Peter Zijlstra wrote:
> On Wed, Aug 22, 2018 at 05:30:15PM +0200, Peter Zijlstra wrote:
> > ARM
> > which later used this put an explicit TLB invalidate in their
> > __p*_free_tlb() functions, and PowerPC-radix followed that example.
>
> > +/*
> > + * If we
On Wed, 22 Aug 2018 17:55:27 +0200
Peter Zijlstra wrote:
> On Wed, Aug 22, 2018 at 05:30:15PM +0200, Peter Zijlstra wrote:
> > ARM
> > which later used this put an explicit TLB invalidate in their
> > __p*_free_tlb() functions, and PowerPC-radix followed that example.
>
> > +/*
> > + * If we
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 815f0ddb346c196018d4d8f8f55c12b83da1de3f
commit: faa16bc404d72a5afb857c924c83a5f691f83386 lib: Use existing define with
polynomial
date: 4 weeks ago
config: powerpc-skiroot_defconfig (attached as .config)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 815f0ddb346c196018d4d8f8f55c12b83da1de3f
commit: faa16bc404d72a5afb857c924c83a5f691f83386 lib: Use existing define with
polynomial
date: 4 weeks ago
config: powerpc-skiroot_defconfig (attached as .config)
On Wed, Aug 22, 2018 at 8:35 PM Linus Torvalds
wrote:
>
> No. Because mm_users doesn't contain any lazy tlb users.
.. or, as it turns out, the use_mm() case either, which can do
gup_fast(). Oh well.
Linus
On Wed, Aug 22, 2018 at 8:35 PM Linus Torvalds
wrote:
>
> No. Because mm_users doesn't contain any lazy tlb users.
.. or, as it turns out, the use_mm() case either, which can do
gup_fast(). Oh well.
Linus
On Wed, Aug 22, 2018 at 8:31 PM Nicholas Piggin wrote:
>
>
> So that leaves speculative operations. I don't see where the problem is
> with those either -- this shortcut needs to ensure there are no other
> *non speculative* operations. mm_users is correct for that.
No. Because mm_users doesn't
On Wed, Aug 22, 2018 at 8:31 PM Nicholas Piggin wrote:
>
>
> So that leaves speculative operations. I don't see where the problem is
> with those either -- this shortcut needs to ensure there are no other
> *non speculative* operations. mm_users is correct for that.
No. Because mm_users doesn't
Hi all,
Please do not add any v4.20 material to your linux-next included
branches until after v4.19-rc1 has been released.
Changes since 20180822:
New tree: at91-fixes
The kbuild tree gained a build failure so I used the version from
next-20180822.
Non-merge commits (relative to Linus' tree
Hi all,
Please do not add any v4.20 material to your linux-next included
branches until after v4.19-rc1 has been released.
Changes since 20180822:
New tree: at91-fixes
The kbuild tree gained a build failure so I used the version from
next-20180822.
Non-merge commits (relative to Linus' tree
On Wed, 22 Aug 2018 17:30:14 +0200
Peter Zijlstra wrote:
> Will noted that only checking mm_users is incorrect; we should also
> check mm_count in order to cover CPUs that have a lazy reference to
> this mm (and could do speculative TLB operations).
Why is that incorrect?
This shortcut has
On Wed, 22 Aug 2018 17:30:14 +0200
Peter Zijlstra wrote:
> Will noted that only checking mm_users is incorrect; we should also
> check mm_count in order to cover CPUs that have a lazy reference to
> this mm (and could do speculative TLB operations).
Why is that incorrect?
This shortcut has
On Sat, May 26, 2018 at 11:24:01AM +0200, Dmitry Vyukov wrote:
> On Sun, May 13, 2018 at 8:21 AM, Eric Biggers wrote:
> > On Thu, Apr 05, 2018 at 08:15:24PM -0700, Eric Biggers wrote:
> >> On Mon, Jan 29, 2018 at 01:29:48PM +0800, Tianyu Lan wrote:
> >> >
> >> >
> >> > On 1/27/2018 7:27 AM, Eric
On Sat, May 26, 2018 at 11:24:01AM +0200, Dmitry Vyukov wrote:
> On Sun, May 13, 2018 at 8:21 AM, Eric Biggers wrote:
> > On Thu, Apr 05, 2018 at 08:15:24PM -0700, Eric Biggers wrote:
> >> On Mon, Jan 29, 2018 at 01:29:48PM +0800, Tianyu Lan wrote:
> >> >
> >> >
> >> > On 1/27/2018 7:27 AM, Eric
Compliment of the day to you Dear Friend.
Dear Friend.
I am Mrs. Amina Kadi. am sending this brief letter to solicit your
partnership to transfer $5.5 million US Dollars. I shall send you
more information and procedures when I receive positive response from
you.
Mrs. Amina Kadi
Compliment of the day to you Dear Friend.
Dear Friend.
I am Mrs. Amina Kadi. am sending this brief letter to solicit your
partnership to transfer $5.5 million US Dollars. I shall send you
more information and procedures when I receive positive response from
you.
Mrs. Amina Kadi
Hi Johan,
I love your patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.18 next-20180822]
[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/commits
Hi Johan,
I love your patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.18 next-20180822]
[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/commits
FYI, we noticed the following commit (built with gcc-5):
commit: 19efe000d3258032d9a1dfb25313a092f9454da0 ("x86: Remap the IRQ stack so
it has guard pages")
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git x86/guard_pages
in testcase: trinity
with following parameters:
FYI, we noticed the following commit (built with gcc-5):
commit: 19efe000d3258032d9a1dfb25313a092f9454da0 ("x86: Remap the IRQ stack so
it has guard pages")
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git x86/guard_pages
in testcase: trinity
with following parameters:
Currently the ti-cpufreq driver blindly registers a 'ti-cpufreq' to force
the driver to probe on any platforms where the driver is built in.
However, this should only happen on platforms that actually can make use
of the driver. There is already functionality in place to match the
SoC compatible
Currently the ti-cpufreq driver blindly registers a 'ti-cpufreq' to force
the driver to probe on any platforms where the driver is built in.
However, this should only happen on platforms that actually can make use
of the driver. There is already functionality in place to match the
SoC compatible
Hi Nick
2018-08-23 8:37 GMT+09:00 Nick Desaulniers :
> Commit cafa0010cd51 ("Raise the minimum required gcc version to 4.6")
> recently exposed a brittle part of the build for supporting non-gcc
> compilers.
>
> Both Clang and ICC define __GNUC__, __GNUC_MINOR__, and
> __GNUC_PATCHLEVEL__ for
Hi Nick
2018-08-23 8:37 GMT+09:00 Nick Desaulniers :
> Commit cafa0010cd51 ("Raise the minimum required gcc version to 4.6")
> recently exposed a brittle part of the build for supporting non-gcc
> compilers.
>
> Both Clang and ICC define __GNUC__, __GNUC_MINOR__, and
> __GNUC_PATCHLEVEL__ for
Hi Paul,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tip/irq/core]
[also build test WARNING on v4.18 next-20180822]
[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
Hi Paul,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tip/irq/core]
[also build test WARNING on v4.18 next-20180822]
[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
If some error happened before find_vqs, error branch will goto
virtscsi_remove_vqs to free vqs. Actually the vqs have not been allocated
successfully, so this will cause wild-pointer-free problem. So
virtscsi_remove_vqs could be deleted as no error will happen after
find_vqs.
Signed-off-by: Jun
If some error happened before find_vqs, error branch will goto
virtscsi_remove_vqs to free vqs. Actually the vqs have not been allocated
successfully, so this will cause wild-pointer-free problem. So
virtscsi_remove_vqs could be deleted as no error will happen after
find_vqs.
Signed-off-by: Jun
Linus,
Masami found an off by one bug in the code that keeps "notrace" functions
from being traced by kprobes. During my testing, I found that there's places
that we may want to add kprobes to notrace, thus we may end up changing this
code before 4.19 is released. The history behind this change
Linus,
Masami found an off by one bug in the code that keeps "notrace" functions
from being traced by kprobes. During my testing, I found that there's places
that we may want to add kprobes to notrace, thus we may end up changing this
code before 4.19 is released. The history behind this change
On 08/22/2018 05:20 PM, Stephen Rothwell wrote:
> Hi John,
>
> After merging the apparmor tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> security/apparmor/policy_unpack.c: In function 'unpack_dfa':
> security/apparmor/policy_unpack.c:426:1: warning: label
On 08/22/2018 05:20 PM, Stephen Rothwell wrote:
> Hi John,
>
> After merging the apparmor tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> security/apparmor/policy_unpack.c: In function 'unpack_dfa':
> security/apparmor/policy_unpack.c:426:1: warning: label
We also have stat() that drops from 6 to 2 roundtrips.
For metadata I think the only remaining low hanging fruit is readdir().
Currently in cifs.ko scanning a directory takes a minimum of 4 roundtrips :
open
query and get data
query and get the error STATUS_NO_MORE_FILES
close
For small-ish
We also have stat() that drops from 6 to 2 roundtrips.
For metadata I think the only remaining low hanging fruit is readdir().
Currently in cifs.ko scanning a directory takes a minimum of 4 roundtrips :
open
query and get data
query and get the error STATUS_NO_MORE_FILES
close
For small-ish
Hi all,
No reply for 2 weeks, any comments?
Thanks,
Chao Fan
On Tue, Aug 07, 2018 at 02:49:56PM +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
Hi all,
No reply for 2 weeks, any comments?
Thanks,
Chao Fan
On Tue, Aug 07, 2018 at 02:49:56PM +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
On Thu, 23 Aug 2018 10:18:31 +0900
Masami Hiramatsu wrote:
> On Wed, 22 Aug 2018 08:58:09 -0400
> Steven Rostedt wrote:
>
> > On Tue, 21 Aug 2018 09:42:49 -0400
> > Steven Rostedt wrote:
> >
> > > On Tue, 21 Aug 2018 22:04:57 +0900
> > > Masami Hiramatsu wrote:
> > >
> > > > Fix
On Thu, 23 Aug 2018 10:18:31 +0900
Masami Hiramatsu wrote:
> On Wed, 22 Aug 2018 08:58:09 -0400
> Steven Rostedt wrote:
>
> > On Tue, 21 Aug 2018 09:42:49 -0400
> > Steven Rostedt wrote:
> >
> > > On Tue, 21 Aug 2018 22:04:57 +0900
> > > Masami Hiramatsu wrote:
> > >
> > > > Fix
On Wed, Aug 22, 2018 at 5:55 PM, Jann Horn wrote:
> On Thu, Aug 23, 2018 at 2:28 AM Andy Lutomirski wrote:
>>
>> On Wed, Aug 22, 2018 at 4:53 PM, Jann Horn wrote:
>> > On Tue, Aug 7, 2018 at 4:55 AM Andy Lutomirski wrote:
>> >> > On Aug 6, 2018, at 6:22 PM, Jann Horn wrote:
>> >> > There have
On Wed, Aug 22, 2018 at 5:55 PM, Jann Horn wrote:
> On Thu, Aug 23, 2018 at 2:28 AM Andy Lutomirski wrote:
>>
>> On Wed, Aug 22, 2018 at 4:53 PM, Jann Horn wrote:
>> > On Tue, Aug 7, 2018 at 4:55 AM Andy Lutomirski wrote:
>> >> > On Aug 6, 2018, at 6:22 PM, Jann Horn wrote:
>> >> > There have
On Wed, 22 Aug 2018 08:58:09 -0400
Steven Rostedt wrote:
> On Tue, 21 Aug 2018 09:42:49 -0400
> Steven Rostedt wrote:
>
> > On Tue, 21 Aug 2018 22:04:57 +0900
> > Masami Hiramatsu wrote:
> >
> > > Fix within_notrace_func() to check notrace function correctly.
> > >
> > > Since the
On Wed, 22 Aug 2018 08:58:09 -0400
Steven Rostedt wrote:
> On Tue, 21 Aug 2018 09:42:49 -0400
> Steven Rostedt wrote:
>
> > On Tue, 21 Aug 2018 22:04:57 +0900
> > Masami Hiramatsu wrote:
> >
> > > Fix within_notrace_func() to check notrace function correctly.
> > >
> > > Since the
On Wed, Aug 22, 2018 at 6:10 PM Dominique Martinet
wrote:
>
> I'm not building linux directly, but BPF programs that indirectly uses
> clang with bcc
Oh, ok.
I _can_ test the basic build (just not get a working link and a
kernel) by just forcing it, so I guess I'll call that testing enough.
On Wed, Aug 22, 2018 at 6:10 PM Dominique Martinet
wrote:
>
> I'm not building linux directly, but BPF programs that indirectly uses
> clang with bcc
Oh, ok.
I _can_ test the basic build (just not get a working link and a
kernel) by just forcing it, so I guess I'll call that testing enough.
Linus Torvalds wrote on Wed, Aug 22, 2018:
> I've fixed that manually, but when I tried to test it I just hit the
>
> arch/x86/Makefile:179: *** Compiler lacks asm-goto support.. Stop.
>
> error.
>
> Do you have some experimental clang build with asm goto support? What
> version? Or is it
Linus Torvalds wrote on Wed, Aug 22, 2018:
> I've fixed that manually, but when I tried to test it I just hit the
>
> arch/x86/Makefile:179: *** Compiler lacks asm-goto support.. Stop.
>
> error.
>
> Do you have some experimental clang build with asm goto support? What
> version? Or is it
On 08/22/2018 05:39 PM, Dmitry Torokhov wrote:
> On Wed, Aug 22, 2018 at 4:35 PM Randy Dunlap wrote:
>>
>> On 08/22/2018 11:53 AM, H. Nikolaus Schaller wrote:
>>> This patch requires that /sbin/depmod is installed and installable on
>>> the build host.
>>>
>>> But not all build hosts for cross
On 08/22/2018 05:39 PM, Dmitry Torokhov wrote:
> On Wed, Aug 22, 2018 at 4:35 PM Randy Dunlap wrote:
>>
>> On 08/22/2018 11:53 AM, H. Nikolaus Schaller wrote:
>>> This patch requires that /sbin/depmod is installed and installable on
>>> the build host.
>>>
>>> But not all build hosts for cross
1 - 100 of 878 matches
Mail list logo
