The memory hotplug description in Documentation/memory-hotplug.txt is
already formatted as ReST and can be easily added to admin-guide/mm
section.
While on it, slightly update formatting to make it consistent with the
doc-guide.
Signed-off-by: Mike Rapoport
---
Documentation/admin-guide/mm/inde
Hi,
Recently I've noticed that Documentation/memory-hotplug.txt is
1) mostly formatted
2) in a wrong place
These patches split the memory-hotplug.txt to two parts: user/admin
interface and memory hotplug notifier API and place these parts in the
correct places, with some formatting changes
The memory hotplug notifier description is about kernel internals rather
than admin/user visible API. Place it appropriately.
Signed-off-by: Mike Rapoport
---
Documentation/admin-guide/mm/memory-hotplug.rst| 83 -
Documentation/core-api/index.rst | 2 +
Hi all,
This series fixes some problems that were brought up during review for
the XFS documentation which I hadn't known about when pushing the ext4
documentation during the 4.19 cycle.
The first patch moves the ext4 mount option and sysfs knob information
into the Linux administration guide.
T
From: Darrick J. Wong
Move the ext4 mount option and other administrative stuff to the Linux
administrator's guide.
Signed-off-by: Darrick J. Wong
---
Documentation/admin-guide/ext4.rst | 574 ++
Documentation/admin-guide/index.rst |1
Documentation
Hi,
So my eyesight still hasn't fully recovered, so in the meantime it's
been difficult to read the online documentation. Here's some stylesheet
overrides I've been using to make it easier for me to read them:
https://djwong.org/docs/kdoc/index.html
---
From: Darrick J. Wong
My eyesight is not
On 10/4/18 5:59 PM, Darrick J. Wong wrote:
> Hi all,
>
> This series fixes some problems that were brought up during review for
> the XFS documentation which I hadn't known about when pushing the ext4
> documentation during the 4.19 cycle.
>
> The first patch moves the ext4 mount option and sysfs
On Wed, Oct 3, 2018 at 3:22 PM Boris Brezillon
wrote:
> Document the Cadence I3C gpio expander bindings.
>
> Signed-off-by: Boris Brezillon
> Reviewed-by: Rob Herring
> ---
> Changes in v8:
> - None
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
Hi Ted,
On Thu, Oct 4, 2018 at 7:02 AM Theodore Y. Ts'o wrote:
> In this case, yes. Again, I emphasize that I was using the ext4.h
> cleanup as an *example*. The point I was trying to make was that your
> change did *not* do a full set of deep ext4 regression tests because
> the your change did
śr., 3 paź 2018 o 23:04 Florian Fainelli napisał(a):
>
>
>
> 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
On Fri, Sep 21, 2018 at 08:05:50AM -0700, Yu-cheng Yu wrote:
> Update ARCH_CET_STATUS and ARCH_CET_DISABLE to include Indirect
> Branch Tracking features.
>
> Introduce:
>
> arch_prctl(ARCH_CET_LEGACY_BITMAP, unsigned long *addr)
> Enable the Indirect Branch Tracking legacy code bitmap.
>
>
On Thu, Oct 4, 2018 at 1:06 PM Bartosz Golaszewski wrote:
> śr., 3 paź 2018 o 23:04 Florian Fainelli napisał(a):
> > 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
Just catching up on this thread, so please excuse any unintentional
misquotes here.
> > > > David: I couldn't find a place in sparc code where any ethernet device
> > > > would be registered, so is there a chance that nobody is using it?
> > >
> > > SPARC uses a true Open Firmware implementation,
On Thu, Oct 4, 2018 at 4:36 PM Sowmini Varadhan
wrote:
>
> Just catching up on this thread, so please excuse any unintentional
> misquotes here.
>
> > > > > David: I couldn't find a place in sparc code where any ethernet device
> > > > > would be registered, so is there a chance that nobody is usi
On Thu, 2018-10-04 at 15:28 +0200, Eugene Syromiatnikov wrote:
> On Fri, Sep 21, 2018 at 08:05:50AM -0700, Yu-cheng Yu wrote:
> > Update ARCH_CET_STATUS and ARCH_CET_DISABLE to include Indirect
> > Branch Tracking features.
> >
> > Introduce:
> >
> > arch_prctl(ARCH_CET_LEGACY_BITMAP, unsigned lo
On Tue, 2018-10-02 at 19:15 +0200, Borislav Petkov wrote:
> On Fri, Sep 21, 2018 at 08:03:27AM -0700, Yu-cheng Yu wrote:
> >
> > diff --git a/arch/x86/include/asm/fpu/xstate.h
> > b/arch/x86/include/asm/fpu/xstate.h
> > index 9b382e5157ed..a32dc5f8c963 100644
> > --- a/arch/x86/include/asm/fpu/xst
On Wed, Oct 3, 2018 at 10:38 PM, John Johansen
wrote:
> but distinct of first exclusive (major) will likely be going away
> once full lsm stacking land.
Right -- then policy loading because the "enabled" flag. The point is
to get us to where we don't care about exclusivity at all.
-Kees
--
Kee
> On Oct 4, 2018, at 8:37 AM, Yu-cheng Yu wrote:
>
>> On Thu, 2018-10-04 at 15:28 +0200, Eugene Syromiatnikov wrote:
>>> On Fri, Sep 21, 2018 at 08:05:50AM -0700, Yu-cheng Yu wrote:
>>> Update ARCH_CET_STATUS and ARCH_CET_DISABLE to include Indirect
>>> Branch Tracking features.
>>>
>>> Introduce:
On Fri, Sep 21, 2018 at 8:10 AM 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 bitmap on
On Thu, Oct 4, 2018 at 9:08 AM Florian Weimer wrote:
>
> * Yu-cheng Yu:
>
> > On Thu, 2018-10-04 at 15:28 +0200, Eugene Syromiatnikov wrote:
> >> On Fri, Sep 21, 2018 at 08:05:50AM -0700, Yu-cheng Yu wrote:
> >> > Update ARCH_CET_STATUS and ARCH_CET_DISABLE to include Indirect
> >> > Branch Tracki
* Yu-cheng Yu:
> On Thu, 2018-10-04 at 15:28 +0200, Eugene Syromiatnikov wrote:
>> On Fri, Sep 21, 2018 at 08:05:50AM -0700, Yu-cheng Yu wrote:
>> > Update ARCH_CET_STATUS and ARCH_CET_DISABLE to include Indirect
>> > Branch Tracking features.
>> >
>> > Introduce:
>> >
>> > arch_prctl(ARCH_CET_L
On Wed, Oct 3, 2018 at 10:56 PM, John Johansen
wrote:
> On 10/03/2018 01:36 PM, Kees Cook wrote:
>> I still think we should have all built LSMs enabled by default, with
>> CONFIG_LSM_DISABLE available to turn stuff off. CONFIG_LSM_ORDER
>
> and this as a distro ubuntu does not want.
> Ubuntu wants
On Thu, 2018-10-04 at 09:12 -0700, Andy Lutomirski wrote:
> On Thu, Oct 4, 2018 at 9:08 AM Florian Weimer wrote:
> >
> > * Yu-cheng Yu:
> >
> > > On Thu, 2018-10-04 at 15:28 +0200, Eugene Syromiatnikov wrote:
> > > > On Fri, Sep 21, 2018 at 08:05:50AM -0700, Yu-cheng Yu wrote:
> > > > > Update A
On Wed, 3 Oct 2018, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 2:34 PM, James Morris wrote:
> > On Wed, 3 Oct 2018, Kees Cook wrote:
> >
> > - All LSMs which are built are NOT enabled by default
> >
> > - You specify enablement and order via a Kconfig:
> >
> > CONFIG_LSM="selinux,yama"
On Thu, Oct 4, 2018 at 10:49 AM, James Morris wrote:
> On Wed, 3 Oct 2018, Kees Cook wrote:
>> Then someone boots the system with:
>>
>> selinux=1 security=selinux
>>
>> In what order does selinux get initialized relative to yama?
>> (apparmor, flagged as a "legacy major", would have been disabled
On Thu, 4 Oct 2018, Kees Cook wrote:
> On Thu, Oct 4, 2018 at 10:49 AM, James Morris wrote:
> > On Wed, 3 Oct 2018, Kees Cook wrote:
> >> Then someone boots the system with:
> >>
> >> selinux=1 security=selinux
> >>
> >> In what order does selinux get initialized relative to yama?
> >> (apparmor,
26 matches
Mail list logo
