> --- /dev/null
> +++ b/arch/csky/kernel/Makefile
> @@ -0,0 +1,8 @@
> +extra-y := head.o vmlinux.lds
> +
> +obj-y += entry.o atomic.o signal.o traps.o irq.o time.o vdso.o \
> + power.o syscall.o platform.o syscall_table.o setup.o \
> + process.o cpu-probe.o ptrace.o dumpstack.o
> +
>
> --- /dev/null
> +++ b/arch/csky/kernel/Makefile
> @@ -0,0 +1,8 @@
> +extra-y := head.o vmlinux.lds
> +
> +obj-y += entry.o atomic.o signal.o traps.o irq.o time.o vdso.o \
> + power.o syscall.o platform.o syscall_table.o setup.o \
> + process.o cpu-probe.o ptrace.o dumpstack.o
> +
>
Quoting Stephen Boyd (2018-06-26 10:06:54)
> These three lines make up what msleep() already does, i.e. setting the
> task to uninterruptible, sleeping for so many jiffies, and then
> schedule() already puts the task state back to TASK_RUNNING when it
> returns. Make things clearer by just calling
Quoting Stephen Boyd (2018-06-26 10:06:54)
> These three lines make up what msleep() already does, i.e. setting the
> task to uninterruptible, sleeping for so many jiffies, and then
> schedule() already puts the task state back to TASK_RUNNING when it
> returns. Make things clearer by just calling
On 09/27/2018 05:43 PM, Wanpeng Li wrote:
On your CPU4:
scheduler_ipi()
-> sched_ttwu_pending()
-> ttwu_do_activate()=> p->sched_remote_wakeup should be
false, so ENQUEUE_WAKEUP is set, ENQUEUE_MIGRATED is not
-> ttwu_activate()
-> activate_task()
On 09/27/2018 05:43 PM, Wanpeng Li wrote:
On your CPU4:
scheduler_ipi()
-> sched_ttwu_pending()
-> ttwu_do_activate()=> p->sched_remote_wakeup should be
false, so ENQUEUE_WAKEUP is set, ENQUEUE_MIGRATED is not
-> ttwu_activate()
-> activate_task()
Changes from v1:
* Take "space_" out of do_kern/user_addr_fault()
* Make "bad fault" comment in do_kern_addr_fault() less scary
* Add clarifying comment for the conditions under which
do_kern_addr_fault() is called.
* Remove mention of hw_error_code in search_exception_tables()
comment.
Changes from v1:
* Take "space_" out of do_kern/user_addr_fault()
* Make "bad fault" comment in do_kern_addr_fault() less scary
* Add clarifying comment for the conditions under which
do_kern_addr_fault() is called.
* Remove mention of hw_error_code in search_exception_tables()
comment.
> > SILVERMONT_CLIENT 0x37 Baytrail, Valleyview
There is no such product as Valleyview. Some things talk about
Valleyview 2 but shouldn't as that is Baytrail.
> /* "Small Core" Processors (Atom) */
>
> #define INTEL_FAM6_ATOM_BONNELL 0x1C /* Diamondville, Pineview
> */
> > SILVERMONT_CLIENT 0x37 Baytrail, Valleyview
There is no such product as Valleyview. Some things talk about
Valleyview 2 but shouldn't as that is Baytrail.
> /* "Small Core" Processors (Atom) */
>
> #define INTEL_FAM6_ATOM_BONNELL 0x1C /* Diamondville, Pineview
> */
From: Dave Hansen
The vsyscall page is weird. It is in what is traditionally part of
the kernel address space. But, it has user permissions and we handle
faults on it like we would on a user page: interrupts on.
Right now, we handle vsyscall emulation in the "bad_area" code, which
is used
From: Dave Hansen
We pass around a variable called "error_code" all around the page
fault code. Sounds simple enough, especially since "error_code" looks
like it exactly matches the values that the hardware gives us on the
stack to report the page fault error code (PFEC in SDM parlance).
From: Dave Hansen
The SMAP and Reserved checking do not have nice comments. Add
some to clarify and make it match everything else.
Signed-off-by: Dave Hansen
Cc: Sean Christopherson
Cc: "Peter Zijlstra (Intel)"
Cc: Thomas Gleixner
Cc: x...@kernel.org
Cc: Andy Lutomirski
Cc: Jann Horn
From: Dave Hansen
We will shortly be using this check in two locations. Put it in
a helper before we do so.
Let's also insert PAGE_MASK instead of the open-coded ~0xfff.
It is easier to read and also more obviously correct considering
the implicit type conversion that has to happen when it
From: Dave Hansen
The vsyscall page is weird. It is in what is traditionally part of
the kernel address space. But, it has user permissions and we handle
faults on it like we would on a user page: interrupts on.
Right now, we handle vsyscall emulation in the "bad_area" code, which
is used
From: Dave Hansen
We pass around a variable called "error_code" all around the page
fault code. Sounds simple enough, especially since "error_code" looks
like it exactly matches the values that the hardware gives us on the
stack to report the page fault error code (PFEC in SDM parlance).
From: Dave Hansen
The SMAP and Reserved checking do not have nice comments. Add
some to clarify and make it match everything else.
Signed-off-by: Dave Hansen
Cc: Sean Christopherson
Cc: "Peter Zijlstra (Intel)"
Cc: Thomas Gleixner
Cc: x...@kernel.org
Cc: Andy Lutomirski
Cc: Jann Horn
From: Dave Hansen
We will shortly be using this check in two locations. Put it in
a helper before we do so.
Let's also insert PAGE_MASK instead of the open-coded ~0xfff.
It is easier to read and also more obviously correct considering
the implicit type conversion that has to happen when it
From: Dave Hansen
The comments here are wrong. They are too absolute about where
faults can occur when running in the kernel. The comments are
also a bit hard to match up with the code.
Trim down the comments, and make them more precise.
Also add a comment explaining why we are doing the
From: Dave Hansen
The comments here are wrong. They are too absolute about where
faults can occur when running in the kernel. The comments are
also a bit hard to match up with the code.
Trim down the comments, and make them more precise.
Also add a comment explaining why we are doing the
From: Dave Hansen
Spurious faults only ever occur in the kernel's address space. They
are also constrained specifically to faults with one of these error codes:
X86_PF_WRITE | X86_PF_PROT
X86_PF_INSTR | X86_PF_PROT
So, it's never even possible to reach
From: Dave Hansen
The page fault handler (__do_page_fault()) basically has two sections:
one for handling faults in the kernel portion of the address space
and another for faults in the user portion of the address space.
But, these two parts don't stick out that well. Let's make that more
From: Dave Hansen
Spurious faults only ever occur in the kernel's address space. They
are also constrained specifically to faults with one of these error codes:
X86_PF_WRITE | X86_PF_PROT
X86_PF_INSTR | X86_PF_PROT
So, it's never even possible to reach
From: Dave Hansen
The page fault handler (__do_page_fault()) basically has two sections:
one for handling faults in the kernel portion of the address space
and another for faults in the user portion of the address space.
But, these two parts don't stick out that well. Let's make that more
From: Dave Hansen
The last patch broke out kernel address space handing into its own
helper. Now, do the same for user address space handling.
Signed-off-by: Dave Hansen
Cc: Sean Christopherson
Cc: "Peter Zijlstra (Intel)"
Cc: Thomas Gleixner
Cc: x...@kernel.org
Cc: Andy Lutomirski
Cc:
From: Dave Hansen
The last patch broke out kernel address space handing into its own
helper. Now, do the same for user address space handling.
Signed-off-by: Dave Hansen
Cc: Sean Christopherson
Cc: "Peter Zijlstra (Intel)"
Cc: Thomas Gleixner
Cc: x...@kernel.org
Cc: Andy Lutomirski
Cc:
Hi Arnd,
On Fri, Sep 28, 2018 at 5:59 PM Arnd Bergmann wrote:
> Applied for 4.20 with subject line changed s/arm/ARM/, thanks!
Thanks.
> I think most people just build a 'defconfig' kernel, which includes
> multiple platforms that use ARCH_SUPPORTS_BIG_ENDIAN.
Right, that's what it looked
Hi Arnd,
On Fri, Sep 28, 2018 at 5:59 PM Arnd Bergmann wrote:
> Applied for 4.20 with subject line changed s/arm/ARM/, thanks!
Thanks.
> I think most people just build a 'defconfig' kernel, which includes
> multiple platforms that use ARCH_SUPPORTS_BIG_ENDIAN.
Right, that's what it looked
On Fri, Sep 28, 2018 at 12:46 AM Lee Jones wrote:
>
> On Wed, 26 Sep 2018, Rob Herring wrote:
>
> > On Mon, Sep 17, 2018 at 04:33:22PM +0100, Charles Keepax wrote:
> > > Signed-off-by: Charles Keepax
> > > ---
> > > Documentation/devicetree/bindings/mfd/arizona.txt | 2 +-
> > > 1 file changed,
On Fri, Sep 28, 2018 at 12:46 AM Lee Jones wrote:
>
> On Wed, 26 Sep 2018, Rob Herring wrote:
>
> > On Mon, Sep 17, 2018 at 04:33:22PM +0100, Charles Keepax wrote:
> > > Signed-off-by: Charles Keepax
> > > ---
> > > Documentation/devicetree/bindings/mfd/arizona.txt | 2 +-
> > > 1 file changed,
> Well, then I have to repeat myself: Signed-off source code (in form of
> patches) in a well-known programming language for a (nowadays)
> well-known GPLv2 licensed project mailed on "everyone can subscribe"
> mailinglists, (thus) to be found in several $SEARCH_ENGINE-indexed
> mailinglist
Quoting Tero Kristo (2018-09-20 00:11:08)
> On 31/08/18 00:46, Stephen Boyd wrote:
> > Quoting Johan Hovold (2018-08-22 02:03:19)
> >> Fix child-node lookup which by using the wrong OF helper was searching
> >> the whole tree depth-first, something which could end up matching an
> >> unrelated
> Well, then I have to repeat myself: Signed-off source code (in form of
> patches) in a well-known programming language for a (nowadays)
> well-known GPLv2 licensed project mailed on "everyone can subscribe"
> mailinglists, (thus) to be found in several $SEARCH_ENGINE-indexed
> mailinglist
Quoting Tero Kristo (2018-09-20 00:11:08)
> On 31/08/18 00:46, Stephen Boyd wrote:
> > Quoting Johan Hovold (2018-08-22 02:03:19)
> >> Fix child-node lookup which by using the wrong OF helper was searching
> >> the whole tree depth-first, something which could end up matching an
> >> unrelated
Hi,
> Hi,
>
> I upgraded my kernel to 4.18.10 recently and have since been experiencing
> network problems after resuming from a
> suspend to RAM or disk. I previously had 4.18.6 and that was OK.
>
> The pattern of the problem is that when I first boot, the network is fine.
> But, after
Hi,
> Hi,
>
> I upgraded my kernel to 4.18.10 recently and have since been experiencing
> network problems after resuming from a
> suspend to RAM or disk. I previously had 4.18.6 and that was OK.
>
> The pattern of the problem is that when I first boot, the network is fine.
> But, after
Since SMPS10 and OTG cable detection extcon are described here, and
work to enable OTG power when an OTG cable is plugged in, we can
define OTG mode in the controller (which is disabled by default in
omap5.dtsi).
Tested on OMAP5EVM and Pyra.
Suggested-by: Roger Quadros
Signed-off-by: H.
Since SMPS10 and OTG cable detection extcon are described here, and
work to enable OTG power when an OTG cable is plugged in, we can
define OTG mode in the controller (which is disabled by default in
omap5.dtsi).
Tested on OMAP5EVM and Pyra.
Suggested-by: Roger Quadros
Signed-off-by: H.
On Wed, Sep 26, 2018 at 3:52 PM Jason A. Donenfeld wrote:
>
> This architecture, used for running in QEMU, runs just fine when
> compiled in big-endian mode. So enable it. This is enabled in exactly
> the same way that it is for other platforms (such as vexpress) that also
> support big-endian
On Wed, Sep 26, 2018 at 3:52 PM Jason A. Donenfeld wrote:
>
> This architecture, used for running in QEMU, runs just fine when
> compiled in big-endian mode. So enable it. This is enabled in exactly
> the same way that it is for other platforms (such as vexpress) that also
> support big-endian
As Jann pointed out in another thread, ptrace_requiest() returns an int, so
it makes sense for seccomp_get_filter() to return an int as well. The
return type of seccomp_get_filter() is bounded by the BPF_MAXINSNS check in
seccomp_prepare_filter(), so this conversion is safe.
Signed-off-by: Tycho
As Jann pointed out, there is a race between SECCOMP_FILTER_FLAG_TSYNC and
the ptrace code that can inspect a filter of another process. Let's
introduce read locking into the two ptrace accesses so that we don't race.
Signed-off-by: Tycho Andersen
Reported-by: Jann Horn
CC: Kees Cook
CC: Andy
As Jann pointed out in another thread, ptrace_requiest() returns an int, so
it makes sense for seccomp_get_filter() to return an int as well. The
return type of seccomp_get_filter() is bounded by the BPF_MAXINSNS check in
seccomp_prepare_filter(), so this conversion is safe.
Signed-off-by: Tycho
As Jann pointed out, there is a race between SECCOMP_FILTER_FLAG_TSYNC and
the ptrace code that can inspect a filter of another process. Let's
introduce read locking into the two ptrace accesses so that we don't race.
Signed-off-by: Tycho Andersen
Reported-by: Jann Horn
CC: Kees Cook
CC: Andy
As Jann pointed out in another thread, ptrace_requiest() returns an int, so
it makes sense for seccomp_get_metdata() to return an int as well. The
return type of seccomp_get_metadata() is bounded by sizeof(kmd), so this
conversion is safe.
Signed-off-by: Tycho Andersen
Reported-by: Jann Horn
As Jann pointed out in another thread, ptrace_requiest() returns an int, so
it makes sense for seccomp_get_metdata() to return an int as well. The
return type of seccomp_get_metadata() is bounded by sizeof(kmd), so this
conversion is safe.
Signed-off-by: Tycho Andersen
Reported-by: Jann Horn
Hello,
On 28.09.2018 17:02, Thomas Gleixner wrote:
> Tvrtko,
>
> On Fri, 28 Sep 2018, Tvrtko Ursulin wrote:
>> On 28/09/2018 11:26, Thomas Gleixner wrote:
>>> On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
>>>
>>> It would be very helpful if you cc all involved people on the cover letter
>>> instead
Hello,
On 28.09.2018 17:02, Thomas Gleixner wrote:
> Tvrtko,
>
> On Fri, 28 Sep 2018, Tvrtko Ursulin wrote:
>> On 28/09/2018 11:26, Thomas Gleixner wrote:
>>> On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
>>>
>>> It would be very helpful if you cc all involved people on the cover letter
>>> instead
On Fri, Sep 28, 2018 at 02:17:16PM +0100, Marc Zyngier wrote:
> On 28/09/18 12:06, Lorenzo Pieralisi wrote:
> >[+Murali, Marc]
> >
> >On Thu, Sep 27, 2018 at 04:44:26PM +0900, Kunihiko Hayashi wrote:
> >>Hi Lorenzo, Gustavo,
> >>
> >>On Wed, 26 Sep 2018 21:31:36 +0900 wrote:
> >>
> >>>Hi Lorenzo,
On Fri, Sep 28, 2018 at 02:17:16PM +0100, Marc Zyngier wrote:
> On 28/09/18 12:06, Lorenzo Pieralisi wrote:
> >[+Murali, Marc]
> >
> >On Thu, Sep 27, 2018 at 04:44:26PM +0900, Kunihiko Hayashi wrote:
> >>Hi Lorenzo, Gustavo,
> >>
> >>On Wed, 26 Sep 2018 21:31:36 +0900 wrote:
> >>
> >>>Hi Lorenzo,
Add flag returned by OPENDIR request to allow kernel to cache directory
contents in page cache. The effect of FOPEN_CACHE_DIR is twofold:
a) if not already cached, it writes entries into the cache
b) if already cached, it allows reading entries from the cache
The FOPEN_KEEP_CACHE has the
Add flag returned by OPENDIR request to allow kernel to cache directory
contents in page cache. The effect of FOPEN_CACHE_DIR is twofold:
a) if not already cached, it writes entries into the cache
b) if already cached, it allows reading entries from the cache
The FOPEN_KEEP_CACHE has the
Directory reading code is about to grow larger, so split it out from dir.c
into a new source file.
Signed-off-by: Miklos Szeredi
---
fs/fuse/Makefile | 2 +-
fs/fuse/dir.c | 259 +-
fs/fuse/fuse_i.h | 12 +++
fs/fuse/readdir.c | 259
Directory reading code is about to grow larger, so split it out from dir.c
into a new source file.
Signed-off-by: Miklos Szeredi
---
fs/fuse/Makefile | 2 +-
fs/fuse/dir.c | 259 +-
fs/fuse/fuse_i.h | 12 +++
fs/fuse/readdir.c | 259
The cache is only used if it's completed, not while it's still being
filled; this constraint could be lifted later, if it turns out to be
useful.
Introduce state in struct fuse_file that indicates the position within the
cache. After a seek, reset the position to the beginning of the cache and
The cache is only used if it's completed, not while it's still being
filled; this constraint could be lifted later, if it turns out to be
useful.
Introduce state in struct fuse_file that indicates the position within the
cache. After a seek, reset the position to the beginning of the cache and
Allow the cache to be invalidated when page(s) have gone missing. In this
case increment the version of the cache and reset to an empty state.
Add a version number to the directory stream in struct fuse_file as well,
indicating the version of the cache it's supposed to be reading. If the
cache
Store the modification time of the directory in the cache, obtained before
starting to fill the cache.
When reading the cache, verify that the directory hasn't changed, by
checking if current modification time is the same as the one stored in the
cache.
This only needs to be done when the
Allow the cache to be invalidated when page(s) have gone missing. In this
case increment the version of the cache and reset to an empty state.
Add a version number to the directory stream in struct fuse_file as well,
indicating the version of the cache it's supposed to be reading. If the
cache
Store the modification time of the directory in the cache, obtained before
starting to fill the cache.
When reading the cache, verify that the directory hasn't changed, by
checking if current modification time is the same as the one stored in the
cache.
This only needs to be done when the
Use the internal iversion counter to make sure modifications of the
directory through this filesystem are not missed by the mtime check (due to
mtime granularity).
Signed-off-by: Miklos Szeredi
---
fs/fuse/dir.c | 21 ++---
fs/fuse/fuse_i.h | 3 +++
fs/fuse/readdir.c | 5
Do this by grouping fields used for cached writes and putting them into a
union with fileds used for cached readdir (with obviously no overlap, since
we don't have hybrid objects).
Signed-off-by: Miklos Szeredi
---
fs/fuse/dir.c| 13 +++-
fs/fuse/file.c | 8
Use the internal iversion counter to make sure modifications of the
directory through this filesystem are not missed by the mtime check (due to
mtime granularity).
Signed-off-by: Miklos Szeredi
---
fs/fuse/dir.c | 21 ++---
fs/fuse/fuse_i.h | 3 +++
fs/fuse/readdir.c | 5
Do this by grouping fields used for cached writes and putting them into a
union with fileds used for cached readdir (with obviously no overlap, since
we don't have hybrid objects).
Signed-off-by: Miklos Szeredi
---
fs/fuse/dir.c| 13 +++-
fs/fuse/file.c | 8
This patch just adds the cache filling functions, which are invoked if
FOPEN_CACHE_DIR flag is set in the OPENDIR reply.
Cache reading and cache invalidation are added by subsequent patches.
The directory cache uses the page cache. Directory entries are packed into
a page in the same format as
This patch just adds the cache filling functions, which are invoked if
FOPEN_CACHE_DIR flag is set in the OPENDIR reply.
Cache reading and cache invalidation are added by subsequent patches.
The directory cache uses the page cache. Directory entries are packed into
a page in the same format as
Allow caching readdir in fuse. Use the page cache for this, which solves
cache shrinking on memory pressure.
I think it might make sense to extract something like this into a set of
VFS helpers, so that other filesystems can also make use of this facility.
Thanks,
Miklos
---
Miklos Szeredi
Allow caching readdir in fuse. Use the page cache for this, which solves
cache shrinking on memory pressure.
I think it might make sense to extract something like this into a set of
VFS helpers, so that other filesystems can also make use of this facility.
Thanks,
Miklos
---
Miklos Szeredi
Prepare for cache filling by introducing a helper for emitting a single
directory entry.
Signed-off-by: Miklos Szeredi
---
fs/fuse/readdir.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/fs/fuse/readdir.c b/fs/fuse/readdir.c
index 3e100e00e21e..65336c93c1f4
Prepare for cache filling by introducing a helper for emitting a single
directory entry.
Signed-off-by: Miklos Szeredi
---
fs/fuse/readdir.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/fs/fuse/readdir.c b/fs/fuse/readdir.c
index 3e100e00e21e..65336c93c1f4
On Wed, 22 Aug 2018 11:25:35 +0200
Marcus Linsner wrote:
> Hi. How to make the kernel keep(lock?) all code pages in RAM so that
> kswapd0 won't evict them when the system is under low memory
> conditions ?
>
> The purpose of this is to prevent the kernel from causing lots of disk
>
On Wed, 22 Aug 2018 11:25:35 +0200
Marcus Linsner wrote:
> Hi. How to make the kernel keep(lock?) all code pages in RAM so that
> kswapd0 won't evict them when the system is under low memory
> conditions ?
>
> The purpose of this is to prevent the kernel from causing lots of disk
>
On Fri, 2018-09-28 at 18:04 +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang
>
> Part of mtk_pcie_register_host is an open-coded version of
> pci_host_probe(). So instead of duplicating this code, use
> pci_host_probe() directly and remove mtk_pcie_register_host.
>
>
On Fri, 2018-09-28 at 18:04 +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang
>
> Part of mtk_pcie_register_host is an open-coded version of
> pci_host_probe(). So instead of duplicating this code, use
> pci_host_probe() directly and remove mtk_pcie_register_host.
>
>
On Thu, Sep 27, 2018 at 10:39:47PM -0700, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For code that retains pages via get_user_pages*(),
> release those pages via the new put_user_page(),
> instead of put_page().
>
> This prepares for eventually fixing the problem described
> in [1],
On Thu, Sep 27, 2018 at 10:39:47PM -0700, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For code that retains pages via get_user_pages*(),
> release those pages via the new put_user_page(),
> instead of put_page().
>
> This prepares for eventually fixing the problem described
> in [1],
On Fri, Sep 28, 2018 at 12:19:44AM +, Naoya Horiguchi wrote:
> On Tue, Sep 25, 2018 at 11:35:32AM -0400, Masayoshi Mizuma wrote:
> > From: Pavel Tatashin
> >
> > When checking for valid pfns in zero_resv_unavail(), it is not necessary to
> > verify that pfns within pageblock_nr_pages ranges
On Fri, Sep 28, 2018 at 12:19:44AM +, Naoya Horiguchi wrote:
> On Tue, Sep 25, 2018 at 11:35:32AM -0400, Masayoshi Mizuma wrote:
> > From: Pavel Tatashin
> >
> > When checking for valid pfns in zero_resv_unavail(), it is not necessary to
> > verify that pfns within pageblock_nr_pages ranges
On Thu, Sep 27, 2018 at 10:39:45PM -0700, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> Hi,
>
> This short series prepares for eventually fixing the problem described
> in [1], and is following a plan listed in [2].
>
> I'd like to get the first two patches into the -mm tree.
>
>
On Thu, Sep 27, 2018 at 10:39:45PM -0700, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> Hi,
>
> This short series prepares for eventually fixing the problem described
> in [1], and is following a plan listed in [2].
>
> I'd like to get the first two patches into the -mm tree.
>
>
On Fri, Sep 28, 2018 at 11:05:21AM +0200, Kurt Kanzenbach wrote:
> Hi Thomas,
>
> On Thu, Sep 27, 2018 at 04:47:47PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 Sep 2018, Kurt Kanzenbach wrote:
> > > On Thu, Sep 27, 2018 at 04:25:47PM +0200, Kurt Kanzenbach wrote:
> > > > However, the issue still
On Fri, Sep 28, 2018 at 11:05:21AM +0200, Kurt Kanzenbach wrote:
> Hi Thomas,
>
> On Thu, Sep 27, 2018 at 04:47:47PM +0200, Thomas Gleixner wrote:
> > On Thu, 27 Sep 2018, Kurt Kanzenbach wrote:
> > > On Thu, Sep 27, 2018 at 04:25:47PM +0200, Kurt Kanzenbach wrote:
> > > > However, the issue still
Tvrtko,
On Fri, 28 Sep 2018, Tvrtko Ursulin wrote:
> On 28/09/2018 15:02, Thomas Gleixner wrote:
> > > Presumably you see adding fine grained control as diminishing the overall
> > > security rather than raising it? Could you explain why? Because
> > > incompetent
> > > sysadmin will turn it off
Tvrtko,
On Fri, 28 Sep 2018, Tvrtko Ursulin wrote:
> On 28/09/2018 15:02, Thomas Gleixner wrote:
> > > Presumably you see adding fine grained control as diminishing the overall
> > > security rather than raising it? Could you explain why? Because
> > > incompetent
> > > sysadmin will turn it off
On Fri, Sep 28, 2018 at 3:22 PM Tvrtko Ursulin
wrote:
> On 28/09/2018 11:26, Thomas Gleixner wrote:
> > On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
> >> For situations where sysadmins might want to allow different level of
> >> access control for different PMUs, we start creating per-PMU
> >>
On Fri, Sep 28, 2018 at 3:22 PM Tvrtko Ursulin
wrote:
> On 28/09/2018 11:26, Thomas Gleixner wrote:
> > On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
> >> For situations where sysadmins might want to allow different level of
> >> access control for different PMUs, we start creating per-PMU
> >>
On Fri, Sep 28, 2018 at 10:40 AM, Dmitry Vyukov wrote:
> On Wed, Sep 26, 2018 at 9:52 AM, syzbot
> wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:dad486875956 Add linux-next specific files for 20180924
>> git tree: linux-next
>> console output:
On Fri, Sep 28, 2018 at 10:40 AM, Dmitry Vyukov wrote:
> On Wed, Sep 26, 2018 at 9:52 AM, syzbot
> wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:dad486875956 Add linux-next specific files for 20180924
>> git tree: linux-next
>> console output:
On Fri, Sep 28 2018 at 04:40 -0600, Marc Zyngier wrote:
On 27/09/18 18:18, Lina Iyer wrote:
The PDC irqchp can convert a falling edge or level low interrupt to a
rising edge or level high interrupt at the GIC. We just need to setup
the GIC correctly. Set up the interrupt type for the
On Fri, Sep 28 2018 at 04:40 -0600, Marc Zyngier wrote:
On 27/09/18 18:18, Lina Iyer wrote:
The PDC irqchp can convert a falling edge or level low interrupt to a
rising edge or level high interrupt at the GIC. We just need to setup
the GIC correctly. Set up the interrupt type for the
On 28/09/2018 15:02, Thomas Gleixner wrote:
Tvrtko,
On Fri, 28 Sep 2018, Tvrtko Ursulin wrote:
On 28/09/2018 11:26, Thomas Gleixner wrote:
On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
It would be very helpful if you cc all involved people on the cover letter
instead of just cc'ing your own
On 28/09/2018 15:02, Thomas Gleixner wrote:
Tvrtko,
On Fri, 28 Sep 2018, Tvrtko Ursulin wrote:
On 28/09/2018 11:26, Thomas Gleixner wrote:
On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
It would be very helpful if you cc all involved people on the cover letter
instead of just cc'ing your own
On Fri, Sep 28, 2018 at 4:45 PM, syzbot
wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:c127e59bee3e Merge tag 'for_v4.19-rc6' of git://git.kernel..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=13b2f32a40
> kernel config:
On Fri, Sep 28, 2018 at 4:45 PM, syzbot
wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:c127e59bee3e Merge tag 'for_v4.19-rc6' of git://git.kernel..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=13b2f32a40
> kernel config:
On Fri, 28 Sep 2018 07:11:44 -0700
Andy Lutomirski wrote:
> > On Sep 28, 2018, at 1:42 AM, Thomas Gleixner wrote:
> >
> >> On Fri, 28 Sep 2018, Martin Schwidefsky wrote:
> >> On Fri, 28 Sep 2018 09:12:10 +0200
> >> Geert Uytterhoeven wrote:
> >>> I don't know if that has happened, and
On Fri, 28 Sep 2018 07:11:44 -0700
Andy Lutomirski wrote:
> > On Sep 28, 2018, at 1:42 AM, Thomas Gleixner wrote:
> >
> >> On Fri, 28 Sep 2018, Martin Schwidefsky wrote:
> >> On Fri, 28 Sep 2018 09:12:10 +0200
> >> Geert Uytterhoeven wrote:
> >>> I don't know if that has happened, and
I'm interested in funding your business project aimed at reaching an agreement.
I'm interested in funding your business project aimed at reaching an agreement.
Em Fri, Sep 28, 2018 at 04:43:06PM +0530, Ravi Bangoria escreveu:
> On 09/28/2018 04:23 PM, Thomas Richter wrote:
> > S390 does not support the perf_event_open system call for
> > attribute type PERF_TYPE_BREAKPOINT. This results in test
> > failure for test 22:
> > [root@s8360046 perf]# ./perf
Em Fri, Sep 28, 2018 at 04:43:06PM +0530, Ravi Bangoria escreveu:
> On 09/28/2018 04:23 PM, Thomas Richter wrote:
> > S390 does not support the perf_event_open system call for
> > attribute type PERF_TYPE_BREAKPOINT. This results in test
> > failure for test 22:
> > [root@s8360046 perf]# ./perf
601 - 700 of 1218 matches
Mail list logo
