Currently, a lock can block pending requests, but all pending
requests are equal. If lots of pending requests are
mutually exclusive, this means they will all be woken up
and all but one will fail. This can hurt performance.
So we will allow pending requests to block other requests.
Only the
When we find an existing lock which conflicts with a request,
and the request wants to wait, we currently add the request
to a list. When the lock is removed, the whole list is woken.
This can cause the thundering-herd problem.
To reduce the problem, we make use of the (new) fact that
a pending
posix_unblock_lock() is not specific to posix locks, and behaves
nearly identically to locks_delete_block() - the former returning a
status while the later doesn't.
So discard posix_unblock_lock() and use locks_delete_block() instead,
after giving that function an appropriate return value.
Now that requests can block other requests, we
need to be careful to always clean up those blocked
requests.
Any time that we wait for a request, we might have
other requests attached, and when we stop waiting,
we must clean them up.
If the lock was granted, the requests might have been
moved to
Currently, a lock can block pending requests, but all pending
requests are equal. If lots of pending requests are
mutually exclusive, this means they will all be woken up
and all but one will fail. This can hurt performance.
So we will allow pending requests to block other requests.
Only the
When we find an existing lock which conflicts with a request,
and the request wants to wait, we currently add the request
to a list. When the lock is removed, the whole list is woken.
This can cause the thundering-herd problem.
To reduce the problem, we make use of the (new) fact that
a pending
posix_unblock_lock() is not specific to posix locks, and behaves
nearly identically to locks_delete_block() - the former returning a
status while the later doesn't.
So discard posix_unblock_lock() and use locks_delete_block() instead,
after giving that function an appropriate return value.
Now that requests can block other requests, we
need to be careful to always clean up those blocked
requests.
Any time that we wait for a request, we might have
other requests attached, and when we stop waiting,
we must clean them up.
If the lock was granted, the requests might have been
moved to
struct file lock contains an 'fl_next' pointer which
is used to point to the lock that this request is blocked
waiting for. So rename it to fl_blocker.
The fl_blocked list_head in an active lock is the head of a list of
blocked requests. In a request it is a node in that list.
These are two
Using memcpy() to copy lock requests leave the various
list_head in an inconsistent state.
As we will soon attach a list of conflicting request to
another pending request, we need these lists to be consistent.
So change NFS to use locks_init_lock/locks_copy_lock instead
of memcpy.
Signed-off-by:
This functionality will be useful in future patches, so
split it out from locks_wake_up_blocks().
Signed-off-by: NeilBrown
---
fs/locks.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index a6c6d601286c..b8f33792a0a6
struct file lock contains an 'fl_next' pointer which
is used to point to the lock that this request is blocked
waiting for. So rename it to fl_blocker.
The fl_blocked list_head in an active lock is the head of a list of
blocked requests. In a request it is a node in that list.
These are two
Using memcpy() to copy lock requests leave the various
list_head in an inconsistent state.
As we will soon attach a list of conflicting request to
another pending request, we need these lists to be consistent.
So change NFS to use locks_init_lock/locks_copy_lock instead
of memcpy.
Signed-off-by:
This functionality will be useful in future patches, so
split it out from locks_wake_up_blocks().
Signed-off-by: NeilBrown
---
fs/locks.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index a6c6d601286c..b8f33792a0a6
This took longer that I had wanted, due to various reasons - sorry.
And I'm now posting it in a merge window, which is not ideal. I don't
expect it to be included in this merge window and I won't be at all
impatient for review, but I didn't want to delay it further.
Testing found some problems,
This took longer that I had wanted, due to various reasons - sorry.
And I'm now posting it in a merge window, which is not ideal. I don't
expect it to be included in this merge window and I won't be at all
impatient for review, but I didn't want to delay it further.
Testing found some problems,
On Tue, Oct 23, 2018 at 03:08:53PM -0700, Nick Desaulniers wrote:
> On Tue, Oct 23, 2018 at 2:58 PM Nathan Chancellor
> wrote:
> >
> > On Tue, Oct 23, 2018 at 01:01:22PM -0700, H. Peter Anvin wrote:
> > > On 10/23/18 11:40, Nick Desaulniers wrote:
> > > > On Mon, Oct 22, 2018 at 10:11 PM Nadav
On Tue, Oct 23, 2018 at 03:08:53PM -0700, Nick Desaulniers wrote:
> On Tue, Oct 23, 2018 at 2:58 PM Nathan Chancellor
> wrote:
> >
> > On Tue, Oct 23, 2018 at 01:01:22PM -0700, H. Peter Anvin wrote:
> > > On 10/23/18 11:40, Nick Desaulniers wrote:
> > > > On Mon, Oct 22, 2018 at 10:11 PM Nadav
On Tue, 2018-10-23 at 21:19 +0100, Phillip Potter wrote:
> Replace if/else statements with common lookup table implementation.
>
> Original patch written by Amir Goldstein.
>
> Signed-off-by: Phillip Potter
> ---
> fs/hfsplus/dir.c | 16 ++--
> 1 file changed, 2 insertions(+), 14
On Tue, 2018-10-23 at 21:19 +0100, Phillip Potter wrote:
> Replace if/else statements with common lookup table implementation.
>
> Original patch written by Amir Goldstein.
>
> Signed-off-by: Phillip Potter
> ---
> fs/hfsplus/dir.c | 16 ++--
> 1 file changed, 2 insertions(+), 14
On 23/10/2018 17:20, Rasmus Villemoes wrote:
On 2018-10-11 01:03, Bryan O'Donoghue wrote:
On 05/10/2018 15:28, Rasmus Villemoes wrote:
Signed-off-by: Rasmus Villemoes
---
I have no idea if the performance matters (it probably doesn't). Feel
free to ignore this and the followup cleanup.
On 23/10/2018 17:20, Rasmus Villemoes wrote:
On 2018-10-11 01:03, Bryan O'Donoghue wrote:
On 05/10/2018 15:28, Rasmus Villemoes wrote:
Signed-off-by: Rasmus Villemoes
---
I have no idea if the performance matters (it probably doesn't). Feel
free to ignore this and the followup cleanup.
If an ARM mapping symbol shares an address with a valid symbol,
find_elf_symbol can currently return the mapping symbol instead, as the
symbol is not validated. This can result in confusing warnings:
WARNING: vmlinux.o(.text+0x18f4028): Section mismatch in reference
from the function
If an ARM mapping symbol shares an address with a valid symbol,
find_elf_symbol can currently return the mapping symbol instead, as the
symbol is not validated. This can result in confusing warnings:
WARNING: vmlinux.o(.text+0x18f4028): Section mismatch in reference
from the function
Hi Loic,
On 7/27/18 8:14 AM, Loic Pallardy wrote:
> This patch introduces a function to verify that a specified carveout
> is fitting request device address and associated length
>
> Signed-off-by: Loic Pallardy
> ---
> drivers/remoteproc/remoteproc_core.c | 47
>
Hi Loic,
On 7/27/18 8:14 AM, Loic Pallardy wrote:
> This patch introduces a function to verify that a specified carveout
> is fitting request device address and associated length
>
> Signed-off-by: Loic Pallardy
> ---
> drivers/remoteproc/remoteproc_core.c | 47
>
On Tue, Oct 23, 2018 at 2:58 PM Nathan Chancellor
wrote:
>
> On Tue, Oct 23, 2018 at 01:01:22PM -0700, H. Peter Anvin wrote:
> > On 10/23/18 11:40, Nick Desaulniers wrote:
> > > On Mon, Oct 22, 2018 at 10:11 PM Nadav Amit wrote:
> > >>
> > >> at 5:37 PM, Nathan Chancellor wrote:
> > >>
> > >>
On Tue, Oct 23, 2018 at 2:58 PM Nathan Chancellor
wrote:
>
> On Tue, Oct 23, 2018 at 01:01:22PM -0700, H. Peter Anvin wrote:
> > On 10/23/18 11:40, Nick Desaulniers wrote:
> > > On Mon, Oct 22, 2018 at 10:11 PM Nadav Amit wrote:
> > >>
> > >> at 5:37 PM, Nathan Chancellor wrote:
> > >>
> > >>
On October 23, 2018 2:58:11 PM PDT, Nathan Chancellor
wrote:
>On Tue, Oct 23, 2018 at 01:01:22PM -0700, H. Peter Anvin wrote:
>> On 10/23/18 11:40, Nick Desaulniers wrote:
>> > On Mon, Oct 22, 2018 at 10:11 PM Nadav Amit
>wrote:
>> >>
>> >> at 5:37 PM, Nathan Chancellor wrote:
>> >>
>> >>
On October 23, 2018 2:58:11 PM PDT, Nathan Chancellor
wrote:
>On Tue, Oct 23, 2018 at 01:01:22PM -0700, H. Peter Anvin wrote:
>> On 10/23/18 11:40, Nick Desaulniers wrote:
>> > On Mon, Oct 22, 2018 at 10:11 PM Nadav Amit
>wrote:
>> >>
>> >> at 5:37 PM, Nathan Chancellor wrote:
>> >>
>> >>
On Tue, Oct 23, 2018 at 01:01:22PM -0700, H. Peter Anvin wrote:
> On 10/23/18 11:40, Nick Desaulniers wrote:
> > On Mon, Oct 22, 2018 at 10:11 PM Nadav Amit wrote:
> >>
> >> at 5:37 PM, Nathan Chancellor wrote:
> >>
> >> Commit 77b0bf55bc67 ("kbuild/Makefile: Prepare for using macros in
> >>
On Tue, Oct 23, 2018 at 01:01:22PM -0700, H. Peter Anvin wrote:
> On 10/23/18 11:40, Nick Desaulniers wrote:
> > On Mon, Oct 22, 2018 at 10:11 PM Nadav Amit wrote:
> >>
> >> at 5:37 PM, Nathan Chancellor wrote:
> >>
> >> Commit 77b0bf55bc67 ("kbuild/Makefile: Prepare for using macros in
> >>
On Tue, 2018-10-23 at 21:54 +0200, Dominik Brodowski wrote:
> While at it, add a few comments which config options #ifdef
> and #else statements refer to.
>
> Fixes: 86d333a8cc7f ("cpufreq: intel_pstate: Add base_frequency
> attribute")
> Cc: Srinivas Pandruvada
> Cc: Rafael J. Wysocki
>
On Tue, 2018-10-23 at 21:54 +0200, Dominik Brodowski wrote:
> While at it, add a few comments which config options #ifdef
> and #else statements refer to.
>
> Fixes: 86d333a8cc7f ("cpufreq: intel_pstate: Add base_frequency
> attribute")
> Cc: Srinivas Pandruvada
> Cc: Rafael J. Wysocki
>
Hi, Oleg:
On 10/23/18 12:43 PM, Enke Chen wrote:
>>
>>> --- a/fs/coredump.c
>>> +++ b/fs/coredump.c
>>> @@ -546,6 +546,7 @@ void do_coredump(const kernel_siginfo_t *siginfo)
>>> struct cred *cred;
>>> int retval = 0;
>>> int ispipe;
>>> + bool notify;
>>> struct files_struct
Hi, Oleg:
On 10/23/18 12:43 PM, Enke Chen wrote:
>>
>>> --- a/fs/coredump.c
>>> +++ b/fs/coredump.c
>>> @@ -546,6 +546,7 @@ void do_coredump(const kernel_siginfo_t *siginfo)
>>> struct cred *cred;
>>> int retval = 0;
>>> int ispipe;
>>> + bool notify;
>>> struct files_struct
Extension of protected memory to dynamic allocations.
Allocations are performed from "pools".
A pool is a list of virtual memory areas, in various state of
protection.
Supported cases
===
Read Only Pool
--
Memory is allocated from the pool, in writable state.
Then it
Extension of protected memory to dynamic allocations.
Allocations are performed from "pools".
A pool is a list of virtual memory areas, in various state of
protection.
Supported cases
===
Read Only Pool
--
Memory is allocated from the pool, in writable state.
Then it
Introduce a section and a label for statically allocated write rare
data.
The label is named "__write_rare_after_init".
As the name implies, after the init phase is completed, this section
will be modifiable only by invoking write rare functions.
NOTE:
this needs rework, because the current
Introduce a section and a label for statically allocated write rare
data.
The label is named "__write_rare_after_init".
As the name implies, after the init phase is completed, this section
will be modifiable only by invoking write rare functions.
NOTE:
this needs rework, because the current
The test cases verify the various interfaces offered by both prmem.h and
prmemextra.h
The tests avoid triggering crashes, by not performing actions that would
be treated as illegal. That part is handled in the lkdtm patch.
Signed-off-by: Igor Stoppa
CC: Michal Hocko
CC: Vlastimil Babka
CC:
The test cases verify the various interfaces offered by both prmem.h and
prmemextra.h
The tests avoid triggering crashes, by not performing actions that would
be treated as illegal. That part is handled in the lkdtm patch.
Signed-off-by: Igor Stoppa
CC: Michal Hocko
CC: Vlastimil Babka
CC:
Using a list_head in an unnamed union poses a problem with the current
implementation of the initializer, since it doesn't specify the names of
the fields it is initializing.
This patch makes it use designated initializers.
Signed-off-by: Igor Stoppa
CC: Kate Stewart
CC: "David S. Miller"
CC:
Using a list_head in an unnamed union poses a problem with the current
implementation of the initializer, since it doesn't specify the names of
the fields it is initializing.
This patch makes it use designated initializers.
Signed-off-by: Igor Stoppa
CC: Kate Stewart
CC: "David S. Miller"
CC:
When a page is used for virtual memory, it is often necessary to obtain
a handler to the corresponding vmap_area, which refers to the virtually
continuous area generated, when invoking vmalloc.
The struct page has a "private" field, which can be re-used, to store a
pointer to the parent area.
As preparation to using write rare on the nodes of various types of
lists, specify that the fields in the basic data structures must be
aligned to sizeof(void *)
It is meant to ensure that any static allocation will not cross a page
boundary, to allow pointers to be updated in one step.
In some cases, all the data needing protection can be allocated from a pool
in one go, as directly writable, then initialized and protected.
The sequence is relatively short and it's acceptable to leave the entire
data set unprotected.
In other cases, this is not possible, because the data will
Prevent leaks of protected memory to userspace.
The protection from overwrited from userspace is already available, once
the memory is write protected.
Signed-off-by: Igor Stoppa
CC: Kees Cook
CC: Chris von Recklinghausen
CC: linux...@kvack.org
CC: linux-kernel@vger.kernel.org
---
When a page is used for virtual memory, it is often necessary to obtain
a handler to the corresponding vmap_area, which refers to the virtually
continuous area generated, when invoking vmalloc.
The struct page has a "private" field, which can be re-used, to store a
pointer to the parent area.
As preparation to using write rare on the nodes of various types of
lists, specify that the fields in the basic data structures must be
aligned to sizeof(void *)
It is meant to ensure that any static allocation will not cross a page
boundary, to allow pointers to be updated in one step.
In some cases, all the data needing protection can be allocated from a pool
in one go, as directly writable, then initialized and protected.
The sequence is relatively short and it's acceptable to leave the entire
data set unprotected.
In other cases, this is not possible, because the data will
Prevent leaks of protected memory to userspace.
The protection from overwrited from userspace is already available, once
the memory is write protected.
Signed-off-by: Igor Stoppa
CC: Kees Cook
CC: Chris von Recklinghausen
CC: linux...@kvack.org
CC: linux-kernel@vger.kernel.org
---
Minimalistic functionality for having the write rare version of
atomic_long_t data.
Signed-off-by: Igor Stoppa
CC: Will Deacon
CC: Peter Zijlstra
CC: Boqun Feng
CC: Arnd Bergmann
CC: linux-a...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
---
MAINTAINERS | 1 +
These test cases focus on the basic operations required to operate
both prlist and prhlist data, in particular creating, growing, shrinking,
destroying.
They can also be useful as reference for practical use of write-rare lists.
Signed-off-by: Igor Stoppa
CC: Kate Stewart
CC: Philippe
Minimalistic functionality for having the write rare version of
atomic_long_t data.
Signed-off-by: Igor Stoppa
CC: Will Deacon
CC: Peter Zijlstra
CC: Boqun Feng
CC: Arnd Bergmann
CC: linux-a...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
---
MAINTAINERS | 1 +
These test cases focus on the basic operations required to operate
both prlist and prhlist data, in particular creating, growing, shrinking,
destroying.
They can also be useful as reference for practical use of write-rare lists.
Signed-off-by: Igor Stoppa
CC: Kate Stewart
CC: Philippe
The measurement list is moved to write rare memory, including
related data structures.
Various boilerplate linux data structures and related functions are
replaced by their write-rare counterpart.
Signed-off-by: Igor Stoppa
CC: Mimi Zohar
CC: Dmitry Kasatkin
CC: James Morris
CC: "Serge E.
Some of the data structures used in list management are composed by two
pointers. Since the kernel is now configured by default to randomize the
layout of data structures soleley composed by pointers, this might
prevent correct type punning between these structures and their write
rare
Some of the data structures used in list management are composed by two
pointers. Since the kernel is now configured by default to randomize the
layout of data structures soleley composed by pointers, this might
prevent correct type punning between these structures and their write
rare
The measurement list is moved to write rare memory, including
related data structures.
Various boilerplate linux data structures and related functions are
replaced by their write-rare counterpart.
Signed-off-by: Igor Stoppa
CC: Mimi Zohar
CC: Dmitry Kasatkin
CC: James Morris
CC: "Serge E.
Prepare vmalloc for:
- tagging areas used for dynamic allocation of protected memory
- supporting various tags, related to the property that an area might have
- extrapolating the pool containing a given area
- chaining the areas in each pool
- extrapolating the area containing a given memory
Wrappers around the basic write rare functionality, addressing several
common data types found in the kernel, allowing to specify the new
values through immediates, like constants and defines.
Note:
The list is not complete and could be expanded.
Signed-off-by: Igor Stoppa
CC: Michal Hocko
CC:
Various cases meant to verify that illegal operations on protected
memory will either BUG() or WARN().
The test cases fall into 2 main categories:
- trying to overwrite (directly) something that is write protected
- trying to use write rare functions on something that is not write rare
Prepare vmalloc for:
- tagging areas used for dynamic allocation of protected memory
- supporting various tags, related to the property that an area might have
- extrapolating the pool containing a given area
- chaining the areas in each pool
- extrapolating the area containing a given memory
Wrappers around the basic write rare functionality, addressing several
common data types found in the kernel, allowing to specify the new
values through immediates, like constants and defines.
Note:
The list is not complete and could be expanded.
Signed-off-by: Igor Stoppa
CC: Michal Hocko
CC:
Various cases meant to verify that illegal operations on protected
memory will either BUG() or WARN().
The test cases fall into 2 main categories:
- trying to overwrite (directly) something that is write protected
- trying to use write rare functions on something that is not write rare
Implementation of write rare for statically allocated data, located in a
specific memory section through the use of the __write_rare label.
The basic functions are wr_memcpy() and wr_memset(): the write rare
counterparts of memcpy() and memset() respectively.
To minimize chances of attacks, this
Implementation of write rare for statically allocated data, located in a
specific memory section through the use of the __write_rare label.
The basic functions are wr_memcpy() and wr_memset(): the write rare
counterparts of memcpy() and memset() respectively.
To minimize chances of attacks, this
Hi Leonardo,
On 10/22/18 11:10 PM, Leonardo Brás wrote:
> Creates DEF_FIELD_ADDR_VAR as a more generic version of the DEF_FIELD_ADD
> macro, allowing usage of a variable name other than the struct element name.
> Also, sets DEF_FIELD_ADDR as a specific usage of DEF_FILD_ADDR_VAR in which
> the
Hi Leonardo,
On 10/22/18 11:10 PM, Leonardo Brás wrote:
> Creates DEF_FIELD_ADDR_VAR as a more generic version of the DEF_FIELD_ADD
> macro, allowing usage of a variable name other than the struct element name.
> Also, sets DEF_FIELD_ADDR as a specific usage of DEF_FILD_ADDR_VAR in which
> the
Hi Masami,
On Wed, 2018-10-24 at 00:03 +0900, Masami Hiramatsu wrote:
> On Thu, 11 Oct 2018 16:02:07 -0500
> Tom Zanussi wrote:
>
> > From: Tom Zanussi
> >
> > Add a test case verifying the basic functionality of the
> > hist:snapshot() action.
> >
>
> I think this is OK for current tracing
Hi Masami,
On Wed, 2018-10-24 at 00:03 +0900, Masami Hiramatsu wrote:
> On Thu, 11 Oct 2018 16:02:07 -0500
> Tom Zanussi wrote:
>
> > From: Tom Zanussi
> >
> > Add a test case verifying the basic functionality of the
> > hist:snapshot() action.
> >
>
> I think this is OK for current tracing
I also commented over there regarding this specific problem.
I think my wording was inaccurate perhaps. It's not so much direct
recursion, but a dependency chain connecting the handler_mutex class
back to itself. This is how lockdep finds problems, it doesn't consider
actual *instances* but
I also commented over there regarding this specific problem.
I think my wording was inaccurate perhaps. It's not so much direct
recursion, but a dependency chain connecting the handler_mutex class
back to itself. This is how lockdep finds problems, it doesn't consider
actual *instances* but
Hi Masami,
On Tue, 2018-10-23 at 23:37 +0900, Masami Hiramatsu wrote:
> Hi Tom,
>
> On Thu, 11 Oct 2018 16:02:04 -0500
> Tom Zanussi wrote:
>
> > From: Tom Zanussi
> >
> > Future patches will want to print a histogram key outside a
> > histogram
> > - add and use hist_trigger_print_key() for
bow == backup on write
Similar to dm-snap, add the ability to take a snapshot of a device.
Unlike dm-snap, a separate volume is not required.
dm-bow can be in one of three states.
In state one, the free blocks on the device are identified by issuing
an FSTRIM to the filesystem.
In state two,
Hi Masami,
On Tue, 2018-10-23 at 23:37 +0900, Masami Hiramatsu wrote:
> Hi Tom,
>
> On Thu, 11 Oct 2018 16:02:04 -0500
> Tom Zanussi wrote:
>
> > From: Tom Zanussi
> >
> > Future patches will want to print a histogram key outside a
> > histogram
> > - add and use hist_trigger_print_key() for
bow == backup on write
Similar to dm-snap, add the ability to take a snapshot of a device.
Unlike dm-snap, a separate volume is not required.
dm-bow can be in one of three states.
In state one, the free blocks on the device are identified by issuing
an FSTRIM to the filesystem.
In state two,
Hi Loic,
On 7/27/18 8:14 AM, Loic Pallardy wrote:
> Memory entry could be allocated in different ways (ioremap,
> dma_alloc_coherent, internal RAM allocator...).
> This patch introduces an alloc ops in rproc_mem_entry structure
> to associate dedicated allocation mechanism to each memory entry
>
Hi Loic,
On 7/27/18 8:14 AM, Loic Pallardy wrote:
> Memory entry could be allocated in different ways (ioremap,
> dma_alloc_coherent, internal RAM allocator...).
> This patch introduces an alloc ops in rproc_mem_entry structure
> to associate dedicated allocation mechanism to each memory entry
>
Hi Stefan,
On 23/10/2018 14:01, Stefan Wahren wrote:
> Hi Matthias,
>
>> matthias@kernel.org hat am 21. Oktober 2018 um 23:58 geschrieben:
>>
>>
>> From: Matthias Brugger
>>
>> By defaul of-based thermal driver do not enable hwmon.
>> This patch does this explicitly, so that the temperature
Hi Stefan,
On 23/10/2018 14:01, Stefan Wahren wrote:
> Hi Matthias,
>
>> matthias@kernel.org hat am 21. Oktober 2018 um 23:58 geschrieben:
>>
>>
>> From: Matthias Brugger
>>
>> By defaul of-based thermal driver do not enable hwmon.
>> This patch does this explicitly, so that the temperature
Deduplicate the ext2 file type conversion implementation.
Original patch by Amir Goldstein.
v2:
- Rebased against Linux 4.19 by Phillip Potter
- This version does not remove EXT2_FT_x enum from fs/ext2/ext2.h,
as these values are now used in compile-time checks added by
Phillip Potter to
Deduplicate the ext2 file type conversion implementation.
Original patch by Amir Goldstein.
v2:
- Rebased against Linux 4.19 by Phillip Potter
- This version does not remove EXT2_FT_x enum from fs/ext2/ext2.h,
as these values are now used in compile-time checks added by
Phillip Potter to
Hi Masami,
On Tue, 2018-10-23 at 14:09 +0900, Masami Hiramatsu wrote:
> Hi Tom,
>
> On Thu, 11 Oct 2018 16:01:58 -0500
> Tom Zanussi wrote:
>
> > From: Tom Zanussi
> >
> > The hist trigger action code currently implements two essentially
> > hard-coded pairs of 'actions' - onmax(), which
Hi Masami,
On Tue, 2018-10-23 at 14:09 +0900, Masami Hiramatsu wrote:
> Hi Tom,
>
> On Thu, 11 Oct 2018 16:01:58 -0500
> Tom Zanussi wrote:
>
> > From: Tom Zanussi
> >
> > The hist trigger action code currently implements two essentially
> > hard-coded pairs of 'actions' - onmax(), which
Hi Leonardo,
Thanks for your patch.
On 10/22/18 11:10 PM, Leonardo Brás wrote:
> Creates DEF_FIELD_ADDR_VAR as a more generic version of the DEF_FIELD_ADD
> macro, allowing usage of a variable name other than the struct element name.
> Also, sets DEF_FIELD_ADDR as a specific usage of
Hi Leonardo,
Thanks for your patch.
On 10/22/18 11:10 PM, Leonardo Brás wrote:
> Creates DEF_FIELD_ADDR_VAR as a more generic version of the DEF_FIELD_ADD
> macro, allowing usage of a variable name other than the struct element name.
> Also, sets DEF_FIELD_ADDR as a specific usage of
On Tue, Oct 23 2018, Theodore Y. Ts'o wrote:
> On Tue, Oct 23, 2018 at 03:25:08PM +1100, NeilBrown wrote:
>>
>> Yes, you could, and you can. But if it was Linus who was behaving
>> inappropriately, where did you go then? This is why I think whatever
>> "code" we have should be overtly a
On Tue, Oct 23 2018, Theodore Y. Ts'o wrote:
> On Tue, Oct 23, 2018 at 03:25:08PM +1100, NeilBrown wrote:
>>
>> Yes, you could, and you can. But if it was Linus who was behaving
>> inappropriately, where did you go then? This is why I think whatever
>> "code" we have should be overtly a
On Tue, Oct 23, 2018 at 01:09:23PM -0700, Matthew Wilcox wrote:
> On Tue, Oct 23, 2018 at 01:48:32PM -0600, Shuah Khan wrote:
> > On 10/23/2018 01:30 PM, Joel Fernandes wrote:
> > > On Tue, Oct 23, 2018 at 11:13:36AM -0600, Shuah Khan wrote:
> > >> I like this proposal. I think we will open up lot
On Tue, Oct 23, 2018 at 01:09:23PM -0700, Matthew Wilcox wrote:
> On Tue, Oct 23, 2018 at 01:48:32PM -0600, Shuah Khan wrote:
> > On 10/23/2018 01:30 PM, Joel Fernandes wrote:
> > > On Tue, Oct 23, 2018 at 11:13:36AM -0600, Shuah Khan wrote:
> > >> I like this proposal. I think we will open up lot
On 10/23/2018 02:09 PM, Matthew Wilcox wrote:
> On Tue, Oct 23, 2018 at 01:48:32PM -0600, Shuah Khan wrote:
>> On 10/23/2018 01:30 PM, Joel Fernandes wrote:
>>> On Tue, Oct 23, 2018 at 11:13:36AM -0600, Shuah Khan wrote:
I like this proposal. I think we will open up lot of test opportunities
On 10/23/2018 02:09 PM, Matthew Wilcox wrote:
> On Tue, Oct 23, 2018 at 01:48:32PM -0600, Shuah Khan wrote:
>> On 10/23/2018 01:30 PM, Joel Fernandes wrote:
>>> On Tue, Oct 23, 2018 at 11:13:36AM -0600, Shuah Khan wrote:
I like this proposal. I think we will open up lot of test opportunities
On 10/23/18 11:53 AM, Suman Anna wrote:
> On 7/27/18 8:14 AM, Loic Pallardy wrote:
>> Memory entry could be allocated in different ways (ioremap,
>> dma_alloc_coherent, internal RAM allocator...).
>> This patch introduces a release ops in rproc_mem_entry structure
>> to associate dedicated release
On 10/23/18 11:53 AM, Suman Anna wrote:
> On 7/27/18 8:14 AM, Loic Pallardy wrote:
>> Memory entry could be allocated in different ways (ioremap,
>> dma_alloc_coherent, internal RAM allocator...).
>> This patch introduces a release ops in rproc_mem_entry structure
>> to associate dedicated release
On Tue, Oct 23 2018, Al Viro wrote:
> On Tue, Oct 23, 2018 at 04:28:03PM +1100, NeilBrown wrote:
>
>> > If that's a clarification, I'm sorry to say that I understand you even
>> > less now.
>> > What are you proposing? Duopoly? How do you deal with disagreements?
>> > Fork?
>> > Revert wars?
On Tue, Oct 23 2018, Al Viro wrote:
> On Tue, Oct 23, 2018 at 04:28:03PM +1100, NeilBrown wrote:
>
>> > If that's a clarification, I'm sorry to say that I understand you even
>> > less now.
>> > What are you proposing? Duopoly? How do you deal with disagreements?
>> > Fork?
>> > Revert wars?
On 10/23/2018 02:13 PM, Ulf Hansson wrote:
> On 23 October 2018 at 10:41, Linus Torvalds
> wrote:
>> So I've obviously started pulling stuff for the merge window, and one
>> of the things I noticed with Greg doing it for the last few weeks was
>> that he has this habit (or automation) to send Ack
On 10/23/2018 02:13 PM, Ulf Hansson wrote:
> On 23 October 2018 at 10:41, Linus Torvalds
> wrote:
>> So I've obviously started pulling stuff for the merge window, and one
>> of the things I noticed with Greg doing it for the last few weeks was
>> that he has this habit (or automation) to send Ack
201 - 300 of 1128 matches
Mail list logo
