Hi all,
This series converts the existing in-kernel xfs documentation to rst
format, links it in with the rest of the kernel's rst documetation, and
then begins pulling in the contents of the Data Structures & Algorithms
book from the xfs-documentation git tree. No changes are made to the
text du
From: Darrick J. Wong
Start adding the main TOC of the XFS data structures and algorithms
book. We'll add the individual sections in later patches.
Signed-off-by: Darrick J. Wong
---
Documentation/conf.py |2
.../filesystems/xfs-data-structures/about.rst
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../filesystems/xfs-data-structures/overview.rst |2
.../self_describing_metadata.rst | 402
.../filesystems/xfs-self-describing-metadata.txt | 350 -
3 files changed, 404
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../xfs-data-structures/common_types.rst | 61
.../filesystems/xfs-data-structures/magic.rst | 277
.../filesystems/xfs-data-structures/overview.rst |2
3 files changed, 340 insertions(+)
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../filesystems/xfs-data-structures/overview.rst |1 +
.../filesystems/xfs-data-structures/testing.rst| 25
2 files changed, 26 insertions(+)
create mode 100644 Documentation/filesystems/xfs-data-structur
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../xfs-data-structures/delayed_logging.rst| 828
.../filesystems/xfs-data-structures/overview.rst |1
.../filesystems/xfs-delayed-logging-design.txt | 793 ---
3 files changed, 82
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../filesystems/xfs-data-structures/overview.rst |1
.../xfs-data-structures/reconstruction.rst | 68
2 files changed, 69 insertions(+)
create mode 100644
Documentation/filesystems/xfs-data-structur
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../filesystems/xfs-data-structures/overview.rst |1
.../filesystems/xfs-data-structures/reflink.rst| 43
2 files changed, 44 insertions(+)
create mode 100644 Documentation/filesystems/xfs-data-structure
Hi all,
This series converts the existing in-kernel xfs documentation to rst
format, links it in with the rest of the kernel's rst documetation, and
then begins pulling in the contents of the Data Structures & Algorithms
book from the xfs-documentation git tree. No changes are made to the
text du
From: Darrick J. Wong
Start adding the main TOC of the XFS data structures and algorithms
book. We'll add the individual sections in later patches.
Signed-off-by: Darrick J. Wong
---
Documentation/conf.py |2
.../filesystems/xfs-data-structures/about.rst
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../filesystems/xfs-data-structures/btrees.rst | 197
.../filesystems/xfs-data-structures/globals.rst|2
2 files changed, 199 insertions(+)
create mode 100644 Documentation/filesystems/xfs-data-structur
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../filesystems/xfs-data-structures/dabtrees.rst | 221
.../filesystems/xfs-data-structures/globals.rst|1
2 files changed, 222 insertions(+)
create mode 100644 Documentation/filesystems/xfs-data-structur
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../filesystems/xfs-data-structures/overview.rst |1 +
.../filesystems/xfs-data-structures/testing.rst| 25
2 files changed, 26 insertions(+)
create mode 100644 Documentation/filesystems/xfs-data-structur
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../filesystems/xfs-data-structures/overview.rst |1
.../xfs-data-structures/reconstruction.rst | 68
2 files changed, 69 insertions(+)
create mode 100644
Documentation/filesystems/xfs-data-structur
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../filesystems/xfs-data-structures/overview.rst |2
.../self_describing_metadata.rst | 402
.../filesystems/xfs-self-describing-metadata.txt | 350 -
3 files changed, 404
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../xfs-data-structures/delayed_logging.rst| 828
.../filesystems/xfs-data-structures/overview.rst |1
.../filesystems/xfs-delayed-logging-design.txt | 793 ---
3 files changed, 82
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../xfs-data-structures/common_types.rst | 61
.../filesystems/xfs-data-structures/magic.rst | 277
.../filesystems/xfs-data-structures/overview.rst |2
3 files changed, 340 insertions(+)
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../filesystems/xfs-data-structures/overview.rst |1
.../filesystems/xfs-data-structures/reflink.rst| 43
2 files changed, 44 insertions(+)
create mode 100644 Documentation/filesystems/xfs-data-structure
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../xfs-data-structures/allocation_groups.rst |2
.../filesystems/xfs-data-structures/rmapbt.rst | 336
2 files changed, 338 insertions(+)
create mode 100644 Documentation/filesystems/xfs-data-structur
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../xfs-data-structures/allocation_groups.rst | 1381
.../filesystems/xfs-data-structures/globals.rst|1
2 files changed, 1382 insertions(+)
create mode 100644
Documentation/filesystems/xfs-data-struct
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../xfs-data-structures/allocation_groups.rst |1
.../filesystems/xfs-data-structures/refcountbt.rst | 154
2 files changed, 155 insertions(+)
create mode 100644 Documentation/filesystems/xfs-data-structur
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../filesystems/xfs-data-structures/globals.rst|1
.../xfs-data-structures/internal_inodes.rst| 208
2 files changed, 209 insertions(+)
create mode 100644
Documentation/filesystems/xfs-data-structu
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../filesystems/xfs-data-structures/globals.rst|1
.../xfs-data-structures/journaling_log.rst | 1442
2 files changed, 1443 insertions(+)
create mode 100644
Documentation/filesystems/xfs-data-struct
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../xfs-data-structures/directories.rst| 1688
.../filesystems/xfs-data-structures/dynamic.rst|1
2 files changed, 1689 insertions(+)
create mode 100644
Documentation/filesystems/xfs-data-struct
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../xfs-data-structures/data_extents.rst | 337
.../filesystems/xfs-data-structures/dynamic.rst|1
2 files changed, 338 insertions(+)
create mode 100644
Documentation/filesystems/xfs-data-structu
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../filesystems/xfs-data-structures/dynamic.rst|2
.../xfs-data-structures/ondisk_inode.rst | 558
2 files changed, 560 insertions(+)
create mode 100644
Documentation/filesystems/xfs-data-structu
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../xfs-data-structures/internal_inodes.rst|2
.../filesystems/xfs-data-structures/rtrmapbt.rst | 230
2 files changed, 232 insertions(+)
create mode 100644 Documentation/filesystems/xfs-data-structur
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../filesystems/xfs-data-structures/auxiliary.rst |2 +
.../filesystems/xfs-data-structures/metadump.rst | 72
2 files changed, 74 insertions(+)
create mode 100644 Documentation/filesystems/xfs-data-structur
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../filesystems/xfs-data-structures/dynamic.rst|1
.../xfs-data-structures/extended_attributes.rst| 933
2 files changed, 934 insertions(+)
create mode 100644
Documentation/filesystems/xfs-data-structu
From: Darrick J. Wong
Signed-off-by: Darrick J. Wong
---
.../filesystems/xfs-data-structures/dynamic.rst|1
.../xfs-data-structures/symbolic_links.rst | 140
2 files changed, 141 insertions(+)
create mode 100644
Documentation/filesystems/xfs-data-structu
* Baoquan He wrote:
> Currently CONFIG_RANDOMIZE_BASE=y is default set, update the relevant
> document about KERNEL_IMAGE_SIZE.
Suggested wording:
x86/KASLR: Update KERNEL_IMAGE_SIZE description
Currently CONFIG_RANDOMIZE_BASE=y is set by default, which makes some of the
old comments
On 10/03/18 at 09:52am, Ingo Molnar wrote:
>
> * Baoquan He wrote:
>
> > Currently CONFIG_RANDOMIZE_BASE=y is default set, update the relevant
> > document about KERNEL_IMAGE_SIZE.
>
> Suggested wording:
>
> x86/KASLR: Update KERNEL_IMAGE_SIZE description
>
> Currently CONFIG_RANDOMIZE_
On 10/02/18 at 11:14am, Ingo Molnar wrote:
>
> * Baoquan He wrote:
> > -8000 - 9fff (=512 MB) kernel text mapping, from
> > phys 0
> > -a000 - feff (1520 MB) module mapping space
> > +fe00 - fe7f (=39 bits, 512 GB) cpu_entr
On Thursday 23 August 2018 05:25 PM, Gustavo Pimentel wrote:
> Change tool compiling process in order to be build using the same
> mechanism used in other linux tools (e.g. iio, perf, etc). This will
> allow in future the buildroot tool to build and integrate this tool in
> a more expeditious wa
On Fri, Sep 21, 2018 at 08:03:30AM -0700, Yu-cheng Yu wrote:
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index e6db475164ed..873765adc244 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -578,6 +578,64 @@ do_general_protection(struct pt_regs *regs,
On Thu, Aug 23, 2018 at 01:55:15PM +0200, Gustavo Pimentel wrote:
> Change tool compiling process in order to be build using the same
> mechanism used in other linux tools (e.g. iio, perf, etc). This will
> allow in future the buildroot tool to build and integrate this tool in
> a more expeditious
Hi Ted,
On Wed, Oct 3, 2018 at 1:25 AM Theodore Y. Ts'o wrote:
>
> On Wed, Oct 03, 2018 at 12:12:10AM +0200, Miguel Ojeda wrote:
> > As I have read, -next is supposed to be a vision of what the merge
> > window will look like after merging everything, i.e. ideally -rc1. For
> > that to work for f
HI Dominique,
On Wed, Oct 3, 2018 at 12:37 AM Dominique Martinet
wrote:
>
> Miguel Ojeda wrote on Wed, Oct 03, 2018:
> > As I have read, -next is supposed to be a vision of what the merge
> > window will look like after merging everything, i.e. ideally -rc1. For
> > that to work for files out-of-
On Wed, 3 Oct 2018 14:14:28 +0200
Miguel Ojeda wrote:
> HI Dominique,
>
> On Wed, Oct 3, 2018 at 12:37 AM Dominique Martinet
> wrote:
> >
> > Miguel Ojeda wrote on Wed, Oct 03, 2018:
> > > As I have read, -next is supposed to be a vision of what the merge
> > > window will look like after mer
Hi Stephen,
On Wed, Oct 3, 2018 at 1:00 AM Stephen Rothwell wrote:
>
> Hi Miguel,
>
> On Wed, 3 Oct 2018 00:36:52 +0200 Dominique Martinet
> wrote:
> >
> > Miguel Ojeda wrote on Wed, Oct 03, 2018:
> > > As I have read, -next is supposed to be a vision of what the merge
> > > window will look li
On 03/10/2018 12:32, Paul Cercueil wrote:
>
> Le 1 oct. 2018 10:48, Daniel Lezcano a
> écrit :
>>
>> On 31/07/2018 00:01, Paul Cercueil wrote:
>>
>> [ ... ]
>>
> +- ingenic,timer-channel: Specifies the TCU channel that
> should be used as + system timer. If not provided, the TCU
>
On 14/09/2018 at 18:20, Nicolas Ferre wrote:
Thierry,
On 28/08/2018 at 15:01, Claudiu Beznea wrote:
Hi,
Please give feedback on these patches which extends the PWM framework in
order to support multiple PWM modes of operations. This series is a rework
of [1] and [2].
This series started with
On Wed, 3 Oct 2018 14:34:28 +0200
Miguel Ojeda wrote:
> When I sent the first email, I assumed that changes in -next were
> supposed to be clean -- my mistake, but please document somewhere how
> -next works! Specially that you are rerere'ing conflicts and
> re-resolving them every day.
Yes, a d
On 03/10/2018 14:51, Paul Cercueil wrote:
>
> Le 3 oct. 2018 2:47 PM, Daniel Lezcano a
> écrit :
>>
>> On 03/10/2018 12:32, Paul Cercueil wrote:
>>>
>>> Le 1 oct. 2018 10:48, Daniel Lezcano
>>> a écrit :
On 31/07/2018 00:01, Paul Cercueil wrote:
[ ... ]
>>> +- i
On 10/02/2018 05:12 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 5:05 PM, John Johansen
> wrote:
>> On 10/02/2018 04:54 PM, Kees Cook wrote:
>>> That's not how I have it currently. It's a comma-separated a string,
>>> including the reserved name "all". The default would just be
>>> "CONFIG_LSM_EN
On Fri, Sep 21, 2018 at 08:03:34AM -0700, Yu-cheng Yu wrote:
> Update _PAGE_DIRTY to _PAGE_DIRTY_BITS in split_2MB_gtt_entry().
>
> In order to support Control Flow Enforcement (CET), _PAGE_DIRTY
> is now _PAGE_DIRTY_HW or _PAGE_DIRTY_SW.
>
> Signed-off-by: Yu-cheng Yu
> ---
> drivers/gpu/drm/i
Document the Cadence I3C gpio expander bindings.
Signed-off-by: Boris Brezillon
Reviewed-by: Rob Herring
---
Changes in v8:
- None
Changes in v7:
- None
Changes in v6:
- None
Changes in v5:
- Add Rob's R-b
Changes in v4:
- Use GPIO_ and IRQ_TYPE_ macros instead of raw numbers
- Fix the unit-
Document sysfs files/directories/symlinks exposed by the I3C subsystem.
Signed-off-by: Boris Brezillon
---
Changes in v8:
- None
Changes in v7:
- Bump KernelVersion to 4.20
- Add new entries under i3c- now that the master controller is
no longer represented as a device under this directory but
Add the I3C documentation describing the protocol, the master driver API
and the device driver API.
Signed-off-by: Boris Brezillon
Reviewed-by: Randy Dunlap
---
Changes in v8:
- None
Changes in v7:
- None
Changes in v6:
- Fix typos reported by Randy
- Add Randy's R-b
Changes in v5:
- Remove u
Hi,
Sorry for the huge delay between v7 and v8 despite the small amount of
things I was asked to fix/rework.
This patch series is adding a new subsystem to support I3C devices.
This is just adding support for basic features. Extra features will
be added afterwards.
There are a few design choice
Add a driver for Cadence I3C GPIO expander.
Signed-off-by: Boris Brezillon
Acked-by: Linus Walleij
---
Changes in v8:
- None
Changes in v7:
- None
Changes in v6:
- Use kmalloc_array() instead of kmalloc(N * sizeof(X))
- Add Linus' ack
Changes in v5:
- Use the !! operator to return 0 or 1 in c
The reg property of devices connected to an I3C bus have 3 cells, and
filling them manually is not trivial. Provides macros to help doing
that.
Signed-off-by: Boris Brezillon
Reviewed-by: Rob Herring
---
Changes in v8:
- None
Changes in v5:
- none
---
include/dt-bindings/i3c/i3c.h | 28 +++
Add a driver for Cadence I3C master IP.
Signed-off-by: Boris Brezillon
---
Changes in v8:
- Adjust code to match changes done in the core (bus embedded in master)
Changes in v7:
- Fix readsl/writesl() usage
- Add a depends on ARM || ARM64 || XTENSA to forbid selection of this
driver on platfor
Document Cadence I3C master DT bindings.
Signed-off-by: Boris Brezillon
Reviewed-by: Rob Herring
---
Changes in v8:
- None
Changes in v7:
- None
Changes in v6:
- None
Changes in v5:
- Add Rob's R-b
Changes in v4:
- Fix example to match the new representation
---
.../devicetree/bindings/i3c/
Create an entry for the I3C subsystem and mark it as maintained by me.
There's no official git repository, patchwork instance, mailing list or
website yet, but this will be added after the subsystem has been
accepted.
Signed-off-by: Boris Brezillon
---
Changes in v8:
- None
Changes in v7:
- Add
A new I3C subsystem has been added and a generic description has been
created to represent the I3C bus and the devices connected on it.
Document this generic representation.
Signed-off-by: Boris Brezillon
Reviewed-by: Rob Herring
---
Changes in v8:
- None
Changes in v7:
- None
Changes in v6:
On Tue, Oct 02, 2018 at 03:12:35PM +0200, Andrey Konovalov wrote:
...
> Changes in v7:
> - Rebased onto 17b57b18 (4.19-rc6).
> - Dropped the "arm64: untag user address in __do_user_fault" patch, since
> the existing patches already handle user faults properly.
> - Dropped the "usb, arm64: untag
On Fri, Sep 21, 2018 at 08:03:33AM -0700, Yu-cheng Yu wrote:
> We are going to create _PAGE_DIRTY_SW for non-hardware, memory
> management purposes. Rename _PAGE_DIRTY to _PAGE_DIRTY_HW and
> _PAGE_BIT_DIRTY to _PAGE_BIT_DIRTY_HW to make these PTE dirty
> bits more clear. There are no functional
On 10/02/2018 07:54 PM, Kees Cook wrote:
On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
wrote:
On 10/02/2018 04:06 PM, Kees Cook wrote:
I think the current proposal (in the other thread) is likely the
sanest approach:
- Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
- Drop CONFIG_SECURITY_APPARM
On 10/03/2018 06:38 AM, Matthew Wilcox wrote:
> On Fri, Sep 21, 2018 at 08:03:33AM -0700, Yu-cheng Yu wrote:
>> We are going to create _PAGE_DIRTY_SW for non-hardware, memory
>> management purposes. Rename _PAGE_DIRTY to _PAGE_DIRTY_HW and
>> _PAGE_BIT_DIRTY to _PAGE_BIT_DIRTY_HW to make these PTE
On Fri, Sep 21, 2018 at 08:03:44AM -0700, Yu-cheng Yu wrote:
> When setting up a signal, the kernel creates a shadow stack
> restore token at the current SHSTK address and then stores the
> token's address in the signal frame, right after the FPU state.
> Before restoring a signal, the kernel verif
On Fri, Sep 21, 2018 at 08:03:42AM -0700, Yu-cheng Yu wrote:
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 5ea1d64cb0b4..b20450dde5b7 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -652,6 +652,9 @@ static void show_smap_vma_flags(struct seq_file *m,
> struct vm
On Wed, 2018-10-03 at 17:08 +0200, Eugene Syromiatnikov wrote:
> On Fri, Sep 21, 2018 at 08:03:42AM -0700, Yu-cheng Yu wrote:
>
> > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> > index 5ea1d64cb0b4..b20450dde5b7 100644
> > --- a/fs/proc/task_mmu.c
> > +++ b/fs/proc/task_mmu.c
> > @@ -652
On Wed, Oct 03, 2018 at 01:54:05PM +0200, Miguel Ojeda wrote:
>
> Exactly. And for this case, I simply assumed Stephen wanted a clean
> series to apply on top of the latest next-* tag (same way we base
> stuff on top of -rc*s). Note that this is *not* really a "tree"
> collecting changes/developme
On Tue, 2018-10-02 at 22:36 -0700, Andy Lutomirski wrote:
> On Tue, Oct 2, 2018 at 9:55 PM Eugene Syromiatnikov wrote:
> >
> > On Fri, Sep 21, 2018 at 08:03:48AM -0700, Yu-cheng Yu wrote:
> > > Create a guard area between VMAs, to detect memory corruption.
> >
> > Do I understand correctly that
On Wed, 2018-10-03 at 06:38 -0700, Matthew Wilcox wrote:
> On Fri, Sep 21, 2018 at 08:03:33AM -0700, Yu-cheng Yu wrote:
> > We are going to create _PAGE_DIRTY_SW for non-hardware, memory
> > management purposes. Rename _PAGE_DIRTY to _PAGE_DIRTY_HW and
> > _PAGE_BIT_DIRTY to _PAGE_BIT_DIRTY_HW to
On Wed, Oct 3, 2018 at 9:06 AM Yu-cheng Yu wrote:
>
> On Tue, 2018-10-02 at 22:36 -0700, Andy Lutomirski wrote:
> > On Tue, Oct 2, 2018 at 9:55 PM Eugene Syromiatnikov wrote:
> > >
> > > On Fri, Sep 21, 2018 at 08:03:48AM -0700, Yu-cheng Yu wrote:
> > > > Create a guard area between VMAs, to dete
On Wed, 2018-10-03 at 12:39 +0200, Eugene Syromiatnikov wrote:
> On Fri, Sep 21, 2018 at 08:03:30AM -0700, Yu-cheng Yu wrote:
> > +dotraplinkage void
> > +do_control_protection(struct pt_regs *regs, long error_code)
> > +{
> > + struct task_struct *tsk;
> > +
> > + RCU_LOCKDEP_WARN(!rcu_is_watc
On Wed, Oct 03, 2018 at 09:00:04AM -0700, Yu-cheng Yu wrote:
> On Tue, 2018-10-02 at 22:36 -0700, Andy Lutomirski wrote:
> > On Tue, Oct 2, 2018 at 9:55 PM Eugene Syromiatnikov wrote:
> > >
> > > On Fri, Sep 21, 2018 at 08:03:48AM -0700, Yu-cheng Yu wrote:
> > > > Create a guard area between VMAs
On Wed, 2018-10-03 at 18:32 +0200, Eugene Syromiatnikov wrote:
> On Wed, Oct 03, 2018 at 09:00:04AM -0700, Yu-cheng Yu wrote:
> > On Tue, 2018-10-02 at 22:36 -0700, Andy Lutomirski wrote:
> > > On Tue, Oct 2, 2018 at 9:55 PM Eugene Syromiatnikov
> > > wrote:
> > > >
> > > > On Fri, Sep 21, 2018 a
On Fri, Sep 21, 2018 at 5:09 PM Yu-cheng Yu wrote:
> When setting up a signal, the kernel creates a shadow stack
> restore token at the current SHSTK address and then stores the
> token's address in the signal frame, right after the FPU state.
> Before restoring a signal, the kernel verifies and t
On Wed, Oct 3, 2018 at 6:32 PM Eugene Syromiatnikov wrote:
> On Wed, Oct 03, 2018 at 09:00:04AM -0700, Yu-cheng Yu wrote:
> > On Tue, 2018-10-02 at 22:36 -0700, Andy Lutomirski wrote:
> > > On Tue, Oct 2, 2018 at 9:55 PM Eugene Syromiatnikov
> > > wrote:
> > > >
> > > > On Fri, Sep 21, 2018 at 0
On Wed, Oct 3, 2018 at 6:39 AM, Stephen Smalley wrote:
> On 10/02/2018 07:54 PM, Kees Cook wrote:
>>
>> On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
>> wrote:
>>>
>>> On 10/02/2018 04:06 PM, Kees Cook wrote:
I think the current proposal (in the other thread) is likely the
sanest a
On Tue, Oct 02, 2018 at 03:12:42PM +0200, Andrey Konovalov wrote:
> diff --git a/Documentation/arm64/tagged-pointers.txt
> b/Documentation/arm64/tagged-pointers.txt
> index a25a99e82bb1..ae877d185fdb 100644
> --- a/Documentation/arm64/tagged-pointers.txt
> +++ b/Documentation/arm64/tagged-pointers
On Fri, Sep 21, 2018 at 08:03:50AM -0700, Yu-cheng Yu wrote:
> arch_prctl(ARCH_CET_STATUS, unsigned long *addr)
> Return CET feature status.
>
> The parameter 'addr' is a pointer to a user buffer.
> On returning to the caller, the kernel fills the following
> information:
>
>
On Tue, 2 Oct 2018, John Johansen wrote:
> To me a list like
> lsm.enable=X,Y,Z
What about even simpler:
lsm=selinux,!apparmor,yama
>
> is best as a single explicit enable list, and it would be best to avoid
> lsm.disable as it just introduces confusion.
>
> I do think per-LSM bootparams lo
On Wed, Oct 3, 2018 at 11:17 AM, James Morris wrote:
> On Tue, 2 Oct 2018, John Johansen wrote:
>> To me a list like
>> lsm.enable=X,Y,Z
>
> What about even simpler:
>
> lsm=selinux,!apparmor,yama
We're going to have lsm.order=, so I'd like to keep it with a dot
separator (this makes it more li
On Wed, 3 Oct 2018, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 11:17 AM, James Morris wrote:
> > On Tue, 2 Oct 2018, John Johansen wrote:
> >> To me a list like
> >> lsm.enable=X,Y,Z
> >
> > What about even simpler:
> >
> > lsm=selinux,!apparmor,yama
>
> We're going to have lsm.order=, so I'd l
On Wed, 2018-10-03 at 15:22 +0200, Boris Brezillon wrote:
> The reg property of devices connected to an I3C bus have 3 cells, and
> filling them manually is not trivial. Provides macros to help doing
> that.
This patch logic seems excessively fragile.
> Signed-off-by: Boris Brezillon
> Reviewed-
Hi Joe,
On Wed, Oct 3, 2018 at 8:37 PM Joe Perches wrote:
> On Wed, 2018-10-03 at 15:22 +0200, Boris Brezillon wrote:
> > The reg property of devices connected to an I3C bus have 3 cells, and
> > filling them manually is not trivial. Provides macros to help doing
> > that.
>
> This patch logic se
On Fri, Sep 21, 2018 at 08:05:46AM -0700, Yu-cheng Yu wrote:
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index bffa9ef47832..230f65ee881e 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -434,6 +435,23 @@ static __init int setu
On Wed, 03 Oct 2018 11:37:17 -0700
Joe Perches wrote:
> On Wed, 2018-10-03 at 15:22 +0200, Boris Brezillon wrote:
> > The reg property of devices connected to an I3C bus have 3 cells, and
> > filling them manually is not trivial. Provides macros to help doing
> > that.
>
> This patch logic see
On Wed, 2018-10-03 at 20:45 +0200, Geert Uytterhoeven wrote:
> Hi Joe,
>
> On Wed, Oct 3, 2018 at 8:37 PM Joe Perches wrote:
> > On Wed, 2018-10-03 at 15:22 +0200, Boris Brezillon wrote:
> > > The reg property of devices connected to an I3C bus have 3 cells, and
> > > filling them manually is not
On Wed, 3 Oct 2018 20:59:53 +0200
Boris Brezillon wrote:
> On Wed, 03 Oct 2018 11:37:17 -0700
> Joe Perches wrote:
>
> > On Wed, 2018-10-03 at 15:22 +0200, Boris Brezillon wrote:
> > > The reg property of devices connected to an I3C bus have 3 cells, and
> > > filling them manually is not tri
On 10/03/2018 01:26 PM, Kees Cook wrote:
On Wed, Oct 3, 2018 at 6:39 AM, Stephen Smalley wrote:
On 10/02/2018 07:54 PM, Kees Cook wrote:
On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
wrote:
On 10/02/2018 04:06 PM, Kees Cook wrote:
I think the current proposal (in the other thread) is lik
On Fri, Sep 21, 2018 at 08:05:47AM -0700, Yu-cheng Yu wrote:
> Indirect branch tracking provides an optional legacy code bitmap
> that indicates locations of non-IBT compatible code. When set,
> each bit in the bitmap represents a page in the linear address is
> legacy code.
>
> We allocate the b
On Wed, Oct 3, 2018 at 11:28 AM, James Morris wrote:
> On Wed, 3 Oct 2018, Kees Cook wrote:
>
>> On Wed, Oct 3, 2018 at 11:17 AM, James Morris wrote:
>> > On Tue, 2 Oct 2018, John Johansen wrote:
>> >> To me a list like
>> >> lsm.enable=X,Y,Z
>> >
>> > What about even simpler:
>> >
>> > lsm=sel
pt., 31 sie 2018 o 21:46 Brian Norris napisał(a):
>
> Hi,
>
> On Fri, Aug 10, 2018 at 10:04:57AM +0200, Bartosz Golaszewski wrote:
> > Most boards use the EEPROM to store the MAC address. This series adds
> > support for cell lookups to the nvmem framework, registers relevant
> > cells for all use
On Fri, Sep 21, 2018 at 08:05:48AM -0700, Yu-cheng Yu wrote:
> The indirect branch tracking legacy bitmap takes a large address
> space. This causes may_expand_vm() failure on the address limit
> check. For a IBT-enabled task, add the bitmap size to the
> address limit.
>
> Signed-off-by: Yu-che
On Wed, Oct 03, 2018 at 10:15:23PM +0200, Bartosz Golaszewski wrote:
> The only user of arch_get_platform_mac_address() is sparc. It returns
> an address that seems to be read from some kind of EEPROM. I'm not
> familiar with this arch though. I'm wondering if we could somehow
> seamlessly remove t
On Wed, Oct 3, 2018 at 1:10 PM, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 11:28 AM, James Morris wrote:
>> On Wed, 3 Oct 2018, Kees Cook wrote:
>>
>>> On Wed, Oct 3, 2018 at 11:17 AM, James Morris wrote:
>>> > On Tue, 2 Oct 2018, John Johansen wrote:
>>> >> To me a list like
>>> >> lsm.enable=
On 10/3/2018 1:15 PM, Bartosz Golaszewski wrote:
pt., 31 sie 2018 o 21:46 Brian Norris napisał(a):
Hi,
On Fri, Aug 10, 2018 at 10:04:57AM +0200, Bartosz Golaszewski wrote:
Most boards use the EEPROM to store the MAC address. This series adds
support for cell lookups to the nvmem framework
On Wed, 3 Oct 2018, Kees Cook wrote:
> I should also note that I don't want to leave CONFIG_DEFAULT_SECURITY
> in, since it's just a way to disable all the other majors.
Right, default doesn't make sense anymore.
--
James Morris
On Wed, Oct 03, 2018 at 06:52:40PM +0200, Jann Horn wrote:
> On Wed, Oct 3, 2018 at 6:32 PM Eugene Syromiatnikov wrote:
> > I'm not sure, however, whether such a change that provides no ability
> > to configure or affect it will go well with all the supported
> > architectures.
>
> Is there a con
Hi Ted,
On Wed, Oct 3, 2018 at 5:33 PM Theodore Y. Ts'o wrote:
>
> On Wed, Oct 03, 2018 at 01:54:05PM +0200, Miguel Ojeda wrote:
> >
> > Exactly. And for this case, I simply assumed Stephen wanted a clean
> > series to apply on top of the latest next-* tag (same way we base
> > stuff on top of -r
On Wed, 3 Oct 2018, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 11:28 AM, James Morris wrote:
> > On Wed, 3 Oct 2018, Kees Cook wrote:
> >
> >> On Wed, Oct 3, 2018 at 11:17 AM, James Morris wrote:
> >> > On Tue, 2 Oct 2018, John Johansen wrote:
> >> >> To me a list like
> >> >> lsm.enable=X,Y,Z
On Wed, Oct 3, 2018 at 11:23 PM Miguel Ojeda
wrote:
> On Wed, Oct 3, 2018 at 5:33 PM Theodore Y. Ts'o wrote:
> > had done with full consideration, specifically for this reason. Even
> > if the definition was different, my definition *had* been fully tested
> > with over a 27+ VM hours of regress
On Fri, Sep 21, 2018 at 08:03:45AM -0700, Yu-cheng Yu wrote:
> Look in .note.gnu.property of an ELF file and check if Shadow Stack needs
> to be enabled for the task.
>
> Signed-off-by: H.J. Lu
> Signed-off-by: Yu-cheng Yu
> ---
> arch/x86/Kconfig | 4 +
> arch/x86/inc
On Wed, Oct 3, 2018 at 2:34 PM, James Morris wrote:
> On Wed, 3 Oct 2018, Kees Cook wrote:
>
>> On Wed, Oct 3, 2018 at 11:28 AM, James Morris wrote:
>> > On Wed, 3 Oct 2018, Kees Cook wrote:
>> >
>> >> On Wed, Oct 3, 2018 at 11:17 AM, James Morris wrote:
>> >> > On Tue, 2 Oct 2018, John Johansen
On 10/3/18 4:55 PM, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 2:34 PM, James Morris wrote:
>> On Wed, 3 Oct 2018, Kees Cook wrote:
>>
>>> On Wed, Oct 3, 2018 at 11:28 AM, James Morris wrote:
On Wed, 3 Oct 2018, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 11:17 AM, James Morris wrote:
1 - 100 of 107 matches
Mail list logo
