* Re: [PATCH] Documentation/stackprotector: powerpc supports stack protector
From: Bhupesh Sharma @ 2019-06-05 9:41 UTC (permalink / raw)
To: Michael Ellerman
Cc: Jonathan Corbet, linuxppc-dev, Arnd Bergmann, Bhupesh SHARMA,
Benjamin Herrenschmidt, Paul Mackerras, Linux Kernel Mailing List,
Linux Doc Mailing List
In-Reply-To: <87ef4eodwf.fsf@concordia.ellerman.id.au>
Hi Jonathan,
On Fri, May 31, 2019 at 8:44 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Jonathan Corbet <corbet@lwn.net> writes:
> > On Thu, 30 May 2019 18:37:46 +0530
> > Bhupesh Sharma <bhsharma@redhat.com> wrote:
> >
> >> > This should probably go via the documentation tree?
> >> >
> >> > Acked-by: Michael Ellerman <mpe@ellerman.id.au>
> >>
> >> Thanks for the review Michael.
> >> I am ok with this going through the documentation tree as well.
> >
> > Works for me too, but I don't seem to find the actual patch anywhere I
> > look. Can you send me a copy?
>
> You can get it from lore:
>
> https://lore.kernel.org/linuxppc-dev/1559212177-7072-1-git-send-email-bhsharma@redhat.com/raw
>
> Or patchwork (automatically adds my ack):
>
> https://patchwork.ozlabs.org/patch/1107706/mbox/
>
> Or Bhupesh can send it to you :)
Please let me know if I should send out the patch again, this time
Cc'ing you and the doc-list.
Thanks,
Bhupesh
^ permalink raw reply
* Re: [PATCH v2 08/22] gpu: i915.rst: Fix references to renamed files
From: Jani Nikula @ 2019-06-05 9:35 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Joonas Lahtinen, Rodrigo Vivi, Maarten Lankhorst,
Maxime Ripard, Sean Paul, David Airlie, Daniel Vetter, intel-gfx,
dri-devel
In-Reply-To: <bd7dd29b9fb2101c954c8cfb2c3b4efc7d277045.1559656538.git.mchehab+samsung@kernel.org>
On Tue, 04 Jun 2019, Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function Hardware workarounds ./drivers/gpu/drm/i915/intel_workarounds.c' failed with return code 1
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function Logical Rings, Logical Ring Contexts and Execlists ./drivers/gpu/drm/i915/intel_lrc.c' failed with return code 1
> WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal ./drivers/gpu/drm/i915/intel_lrc.c' failed with return code 2
>
> Fixes: 112ed2d31a46 ("drm/i915: Move GraphicsTechnology files under gt/")
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Thanks for the patch, I picked this via drm-intel because the commit
being fixed is not in Linus' tree yet.
BR,
Jani.
> ---
> Documentation/gpu/i915.rst | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 055df45596c1..6c75380b2928 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -61,7 +61,7 @@ Intel GVT-g Host Support(vGPU device model)
> Workarounds
> -----------
>
> -.. kernel-doc:: drivers/gpu/drm/i915/intel_workarounds.c
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_workarounds.c
> :doc: Hardware workarounds
>
> Display Hardware Handling
> @@ -379,10 +379,10 @@ User Batchbuffer Execution
> Logical Rings, Logical Ring Contexts and Execlists
> --------------------------------------------------
>
> -.. kernel-doc:: drivers/gpu/drm/i915/intel_lrc.c
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_lrc.c
> :doc: Logical Rings, Logical Ring Contexts and Execlists
>
> -.. kernel-doc:: drivers/gpu/drm/i915/intel_lrc.c
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_lrc.c
> :internal:
>
> Global GTT views
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply
* Re: [PATCH 03/10] mfd / platform: cros_ec: Miscellaneous character device to talk with the EC
From: Lee Jones @ 2019-06-05 9:21 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Guenter Roeck, Ezequiel Garcia, Enric Balletbo i Serra,
linux-kernel, Gwendal Grignou, Guenter Roeck, Benson Leung,
kernel, Dmitry Torokhov, Gustavo Pimentel, Randy Dunlap,
Lorenzo Pieralisi, linux-doc, Enno Luebbers, Guido Kiener,
Thomas Gleixner, Kishon Vijay Abraham I, Jonathan Corbet, Wu Hao,
Kate Stewart, Tycho Andersen, Gerd Hoffmann, Jilayne Lovejoy
In-Reply-To: <20190605084813.GA26984@kroah.com>
On Wed, 05 Jun 2019, Greg Kroah-Hartman wrote:
> On Wed, Jun 05, 2019 at 09:40:02AM +0100, Lee Jones wrote:
> > On Wed, 05 Jun 2019, Greg Kroah-Hartman wrote:
> >
> > > On Wed, Jun 05, 2019 at 07:48:39AM +0100, Lee Jones wrote:
> > > > On Tue, 04 Jun 2019, Greg Kroah-Hartman wrote:
> > > > > On Tue, Jun 04, 2019 at 11:39:21AM -0700, Guenter Roeck wrote:
> > > > > > On Tue, Jun 4, 2019 at 11:35 AM Greg Kroah-Hartman
> > > > > > <gregkh@linuxfoundation.org> wrote:
> > > > > > >
> > > > > > > On Tue, Jun 04, 2019 at 01:58:38PM -0300, Ezequiel Garcia wrote:
> > > > > > > > Hey Greg,
> > > > > > > >
> > > > > > > > > > + dev_info(&pdev->dev, "Created misc device /dev/%s\n",
> > > > > > > > > > + data->misc.name);
> > > > > > > > >
> > > > > > > > > No need to be noisy, if all goes well, your code should be quiet.
> > > > > > > > >
> > > > > > > >
> > > > > > > > I sometimes wonder about this being noise or not, so I will slightly
> > > > > > > > hijack this thread for this discussion.
> > > > > > > >
> > > > > > > > >From a kernel developer point-of-view, or even from a platform
> > > > > > > > developer or user with a debugging hat point-of-view, having
> > > > > > > > a "device created" or "device registered" message is often very useful.
> > > > > > >
> > > > > > > For you, yes. For someone with 30000 devices attached to their system,
> > > > > > > it is not, and causes booting to take longer than it should be.
> > > >
> > > > Who has 30,000 devices attached to their systems?
> > >
> > > More than you might imagine.
> > >
> > > > I would argue that
> > > > in these special corner-cases, they should knock the log-level *down*
> > > > a notch. For the rest of us who run normal platforms, an extra second
> > > > of boot time renders a more forthcoming/useful system than if each of
> > > > our devices initialised silently.
> > > >
> > > > Personally I like to know what devices I have on my system, and the
> > > > kernel log is the first place I look. As far as I'm concerned, for
> > > > the most part, if it's not in the kernel log, I don't have it.
> > >
> > > Then you "do not have" lots of devices, as we have been removing these
> > > messages for a number of years now :)
> > >
> > > > "Oh wow, I didn't know I had XXX functionality on this platform."
> > > >
> > > > In my real job, I am currently enabling some newly released AArch64
> > > > based laptops for booting with ACPI. I must have wasted a day whilst
> > > > enabling some of the devices the system relies upon, just to find
> > > > out that 90% of them were actually probing semi-fine (at least probe()
> > > > was succeeding), just silently. *grumble*
> > >
> > > Yup, that's normal. If you want to see what devices are in the system,
> > > look in /sys/devices/ as that is what it is for, not the kernel log.
> >
> > My guess is that less than 1% of Linux users use /sys/devices in this
> > way. It's a very unfriendly interface. Besides, when enabling a new
> > platform, access to sysfs comes too far down the line to be useful in
> > the majority of cases.
>
> `lshw` is your friend :)
Provided you have a command line (with `lshw` installed) and a
working keyboard. ;)
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 03/10] mfd / platform: cros_ec: Miscellaneous character device to talk with the EC
From: Greg Kroah-Hartman @ 2019-06-05 8:48 UTC (permalink / raw)
To: Lee Jones
Cc: Guenter Roeck, Ezequiel Garcia, Enric Balletbo i Serra,
linux-kernel, Gwendal Grignou, Guenter Roeck, Benson Leung,
kernel, Dmitry Torokhov, Gustavo Pimentel, Randy Dunlap,
Lorenzo Pieralisi, linux-doc, Enno Luebbers, Guido Kiener,
Thomas Gleixner, Kishon Vijay Abraham I, Jonathan Corbet, Wu Hao,
Kate Stewart, Tycho Andersen, Gerd Hoffmann, Jilayne Lovejoy
In-Reply-To: <20190605084002.GP4797@dell>
On Wed, Jun 05, 2019 at 09:40:02AM +0100, Lee Jones wrote:
> On Wed, 05 Jun 2019, Greg Kroah-Hartman wrote:
>
> > On Wed, Jun 05, 2019 at 07:48:39AM +0100, Lee Jones wrote:
> > > On Tue, 04 Jun 2019, Greg Kroah-Hartman wrote:
> > > > On Tue, Jun 04, 2019 at 11:39:21AM -0700, Guenter Roeck wrote:
> > > > > On Tue, Jun 4, 2019 at 11:35 AM Greg Kroah-Hartman
> > > > > <gregkh@linuxfoundation.org> wrote:
> > > > > >
> > > > > > On Tue, Jun 04, 2019 at 01:58:38PM -0300, Ezequiel Garcia wrote:
> > > > > > > Hey Greg,
> > > > > > >
> > > > > > > > > + dev_info(&pdev->dev, "Created misc device /dev/%s\n",
> > > > > > > > > + data->misc.name);
> > > > > > > >
> > > > > > > > No need to be noisy, if all goes well, your code should be quiet.
> > > > > > > >
> > > > > > >
> > > > > > > I sometimes wonder about this being noise or not, so I will slightly
> > > > > > > hijack this thread for this discussion.
> > > > > > >
> > > > > > > >From a kernel developer point-of-view, or even from a platform
> > > > > > > developer or user with a debugging hat point-of-view, having
> > > > > > > a "device created" or "device registered" message is often very useful.
> > > > > >
> > > > > > For you, yes. For someone with 30000 devices attached to their system,
> > > > > > it is not, and causes booting to take longer than it should be.
> > >
> > > Who has 30,000 devices attached to their systems?
> >
> > More than you might imagine.
> >
> > > I would argue that
> > > in these special corner-cases, they should knock the log-level *down*
> > > a notch. For the rest of us who run normal platforms, an extra second
> > > of boot time renders a more forthcoming/useful system than if each of
> > > our devices initialised silently.
> > >
> > > Personally I like to know what devices I have on my system, and the
> > > kernel log is the first place I look. As far as I'm concerned, for
> > > the most part, if it's not in the kernel log, I don't have it.
> >
> > Then you "do not have" lots of devices, as we have been removing these
> > messages for a number of years now :)
> >
> > > "Oh wow, I didn't know I had XXX functionality on this platform."
> > >
> > > In my real job, I am currently enabling some newly released AArch64
> > > based laptops for booting with ACPI. I must have wasted a day whilst
> > > enabling some of the devices the system relies upon, just to find
> > > out that 90% of them were actually probing semi-fine (at least probe()
> > > was succeeding), just silently. *grumble*
> >
> > Yup, that's normal. If you want to see what devices are in the system,
> > look in /sys/devices/ as that is what it is for, not the kernel log.
>
> My guess is that less than 1% of Linux users use /sys/devices in this
> way. It's a very unfriendly interface. Besides, when enabling a new
> platform, access to sysfs comes too far down the line to be useful in
> the majority of cases.
`lshw` is your friend :)
^ permalink raw reply
* Re: [PATCH 03/10] mfd / platform: cros_ec: Miscellaneous character device to talk with the EC
From: Lee Jones @ 2019-06-05 8:40 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Guenter Roeck, Ezequiel Garcia, Enric Balletbo i Serra,
linux-kernel, Gwendal Grignou, Guenter Roeck, Benson Leung,
kernel, Dmitry Torokhov, Gustavo Pimentel, Randy Dunlap,
Lorenzo Pieralisi, linux-doc, Enno Luebbers, Guido Kiener,
Thomas Gleixner, Kishon Vijay Abraham I, Jonathan Corbet, Wu Hao,
Kate Stewart, Tycho Andersen, Gerd Hoffmann, Jilayne Lovejoy
In-Reply-To: <20190605080241.GC9693@kroah.com>
On Wed, 05 Jun 2019, Greg Kroah-Hartman wrote:
> On Wed, Jun 05, 2019 at 07:48:39AM +0100, Lee Jones wrote:
> > On Tue, 04 Jun 2019, Greg Kroah-Hartman wrote:
> > > On Tue, Jun 04, 2019 at 11:39:21AM -0700, Guenter Roeck wrote:
> > > > On Tue, Jun 4, 2019 at 11:35 AM Greg Kroah-Hartman
> > > > <gregkh@linuxfoundation.org> wrote:
> > > > >
> > > > > On Tue, Jun 04, 2019 at 01:58:38PM -0300, Ezequiel Garcia wrote:
> > > > > > Hey Greg,
> > > > > >
> > > > > > > > + dev_info(&pdev->dev, "Created misc device /dev/%s\n",
> > > > > > > > + data->misc.name);
> > > > > > >
> > > > > > > No need to be noisy, if all goes well, your code should be quiet.
> > > > > > >
> > > > > >
> > > > > > I sometimes wonder about this being noise or not, so I will slightly
> > > > > > hijack this thread for this discussion.
> > > > > >
> > > > > > >From a kernel developer point-of-view, or even from a platform
> > > > > > developer or user with a debugging hat point-of-view, having
> > > > > > a "device created" or "device registered" message is often very useful.
> > > > >
> > > > > For you, yes. For someone with 30000 devices attached to their system,
> > > > > it is not, and causes booting to take longer than it should be.
> >
> > Who has 30,000 devices attached to their systems?
>
> More than you might imagine.
>
> > I would argue that
> > in these special corner-cases, they should knock the log-level *down*
> > a notch. For the rest of us who run normal platforms, an extra second
> > of boot time renders a more forthcoming/useful system than if each of
> > our devices initialised silently.
> >
> > Personally I like to know what devices I have on my system, and the
> > kernel log is the first place I look. As far as I'm concerned, for
> > the most part, if it's not in the kernel log, I don't have it.
>
> Then you "do not have" lots of devices, as we have been removing these
> messages for a number of years now :)
>
> > "Oh wow, I didn't know I had XXX functionality on this platform."
> >
> > In my real job, I am currently enabling some newly released AArch64
> > based laptops for booting with ACPI. I must have wasted a day whilst
> > enabling some of the devices the system relies upon, just to find
> > out that 90% of them were actually probing semi-fine (at least probe()
> > was succeeding), just silently. *grumble*
>
> Yup, that's normal. If you want to see what devices are in the system,
> look in /sys/devices/ as that is what it is for, not the kernel log.
My guess is that less than 1% of Linux users use /sys/devices in this
way. It's a very unfriendly interface. Besides, when enabling a new
platform, access to sysfs comes too far down the line to be useful in
the majority of cases.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [dm-devel] [PATCH v12] dm: add support to directly boot to a mapped device
From: Zdenek Kabelac @ 2019-06-05 8:35 UTC (permalink / raw)
To: Stephen Boyd, Helen Koike, dm-devel
Cc: wad, keescook, snitzer, linux-doc, richard.weinberger,
linux-kernel, linux-lvm, enric.balletbo, kernel, agk
In-Reply-To: <5cf6c7e6.1c69fb81.e1551.8ac4@mx.google.com>
Dne 04. 06. 19 v 21:35 Stephen Boyd napsal(a):
> Quoting Helen Koike (2019-06-04 10:38:59)
>> On 6/3/19 8:02 PM, Stephen Boyd wrote:
>>>
>>> I'm trying to boot a mainline linux kernel on a chromeos device with dm
>>> verity and a USB stick but it's not working for me even with this patch.
>>> I've had to hack around two problems:
>>>
>>> 1) rootwait isn't considered
>>>
>>> 2) verity doesn't seem to accept UUID for <hash_dev> or <dev>
>>>
>>> For the first problem, it happens every boot for me because I'm trying
>>> to boot off of a USB stick and it's behind a hub that takes a few
>>> seconds to enumerate. If I hack up the code to call dm_init_init() after
>>> the 'rootdelay' cmdline parameter is used then I can make this work. It
>>> would be much nicer if the whole mechanism didn't use a late initcall
>>> though. If it used a hook from prepare_namespace() and then looped
>>> waiting for devices to create when rootwait was specified it would work.
>>
>> The patch was implemented with late initcall partially to be contained
>> in drivers/md/*, but to support rootwait, adding a hook from
>> prepare_namespace seems the way to go indeed.
>
> Alright, great.
>
>>
>>>
>>> The second problem is that in chromeos we have the bootloader fill out
>>> the UUID of the kernel partition (%U) and then we have another parameter
>>> that indicates the offset from that kernel partition to add to the
>>> kernel partition (typically 1, i.e. PARTNROFF=1) to find the root
>>> filesystem partition. The way verity seems to work here is that we need
>>> to specify a path like /dev/sda3 or the major:minor number of the device
Hi
As not a direct dm developer - isn't this going a bit too far ? -
This way you will need to soon move halve of the userspace functionality into
kernel space.
IMHO would be way more progressive to start using initramdisk and let
userspace resolve all the issue.
Clearly once you start to wait for some 'devices' to appear - then you will
need to way for CORRECT device as well - since sda,sdb... goes in random
order, so you would need to parse disk headers and so on.
What you are effectively doing at this moment is you are shifting/ballooning
'ramdisk' code into kernel image - just to be named a kernel.
So why it is so big deal to start to use ramdisk on ChromeOS?
That would have solved most of problems you have or you will have instantly.
Regards
Zdenek
^ permalink raw reply
* Re: [PATCH 03/10] mfd / platform: cros_ec: Miscellaneous character device to talk with the EC
From: Greg Kroah-Hartman @ 2019-06-05 8:02 UTC (permalink / raw)
To: Lee Jones
Cc: Guenter Roeck, Ezequiel Garcia, Enric Balletbo i Serra,
linux-kernel, Gwendal Grignou, Guenter Roeck, Benson Leung,
kernel, Dmitry Torokhov, Gustavo Pimentel, Randy Dunlap,
Lorenzo Pieralisi, linux-doc, Enno Luebbers, Guido Kiener,
Thomas Gleixner, Kishon Vijay Abraham I, Jonathan Corbet, Wu Hao,
Kate Stewart, Tycho Andersen, Gerd Hoffmann, Jilayne Lovejoy
In-Reply-To: <20190605064839.GH4797@dell>
On Wed, Jun 05, 2019 at 07:48:39AM +0100, Lee Jones wrote:
> On Tue, 04 Jun 2019, Greg Kroah-Hartman wrote:
> > On Tue, Jun 04, 2019 at 11:39:21AM -0700, Guenter Roeck wrote:
> > > On Tue, Jun 4, 2019 at 11:35 AM Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Tue, Jun 04, 2019 at 01:58:38PM -0300, Ezequiel Garcia wrote:
> > > > > Hey Greg,
> > > > >
> > > > > > > + dev_info(&pdev->dev, "Created misc device /dev/%s\n",
> > > > > > > + data->misc.name);
> > > > > >
> > > > > > No need to be noisy, if all goes well, your code should be quiet.
> > > > > >
> > > > >
> > > > > I sometimes wonder about this being noise or not, so I will slightly
> > > > > hijack this thread for this discussion.
> > > > >
> > > > > >From a kernel developer point-of-view, or even from a platform
> > > > > developer or user with a debugging hat point-of-view, having
> > > > > a "device created" or "device registered" message is often very useful.
> > > >
> > > > For you, yes. For someone with 30000 devices attached to their system,
> > > > it is not, and causes booting to take longer than it should be.
>
> Who has 30,000 devices attached to their systems?
More than you might imagine.
> I would argue that
> in these special corner-cases, they should knock the log-level *down*
> a notch. For the rest of us who run normal platforms, an extra second
> of boot time renders a more forthcoming/useful system than if each of
> our devices initialised silently.
>
> Personally I like to know what devices I have on my system, and the
> kernel log is the first place I look. As far as I'm concerned, for
> the most part, if it's not in the kernel log, I don't have it.
Then you "do not have" lots of devices, as we have been removing these
messages for a number of years now :)
> "Oh wow, I didn't know I had XXX functionality on this platform."
>
> In my real job, I am currently enabling some newly released AArch64
> based laptops for booting with ACPI. I must have wasted a day whilst
> enabling some of the devices the system relies upon, just to find
> out that 90% of them were actually probing semi-fine (at least probe()
> was succeeding), just silently. *grumble*
Yup, that's normal. If you want to see what devices are in the system,
look in /sys/devices/ as that is what it is for, not the kernel log.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 09/22] docs: zh_CN: avoid duplicate citation references
From: Alex Shi @ 2019-06-05 7:56 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet, Harry Wei
In-Reply-To: <caf96b7ac3c4a3db66b6d6d2651849d2a70e3e76.1559656538.git.mchehab+samsung@kernel.org>
On 2019/6/4 10:17 下午, Mauro Carvalho Chehab wrote:
> -内核是用C语言 [c-language]_ 编写的。更准确地说，内核通常是用 ``gcc`` [gcc]_
> -在 ``-std=gnu89`` [gcc-c-dialect-options]_ 下编译的：ISO C90的 GNU 方言（
> +内核是用C语言 :ref:`c-language <cn_c-language>` 编写的。更准确地说，内核通常是用 ``gcc`` :ref:`gcc <cn_gcc>`
It looks better to remove ``gcc`` here. otherwise 2 'gcc' words show here is weird.
> +在 ``-std=gnu89`` :ref:`gcc-c-dialect-options <cn_gcc-c-dialect-options>` 下编译的：ISO C90的 GNU 方言（
> 包括一些C99特性）
>
> -这种方言包含对语言 [gnu-extensions]_ 的许多扩展，当然，它们许多都在内核中使用。
> +这种方言包含对语言 :ref:`gnu-extensions <cn_gnu-extensions>` 的许多扩展，当然，它们许多都在内核中使用。
>
> -对于一些体系结构，有一些使用 ``clang`` [clang]_ 和 ``icc`` [icc]_ 编译内核
> +对于一些体系结构，有一些使用 ``clang`` :ref:`clang <cn_clang>` 和 ``icc`` :ref:`icc <cn_icc>` 编译内核
and remove ``clang``, ``icc`` too.
> 的支持，尽管在编写此文档时还没有完成，仍需要第三方补丁。
>
Thanks
Alex
^ permalink raw reply
* Re: [PATCH 03/10] mfd / platform: cros_ec: Miscellaneous character device to talk with the EC
From: Lee Jones @ 2019-06-05 6:48 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Guenter Roeck, Ezequiel Garcia, Enric Balletbo i Serra,
linux-kernel, Gwendal Grignou, Guenter Roeck, Benson Leung,
kernel, Dmitry Torokhov, Gustavo Pimentel, Randy Dunlap,
Lorenzo Pieralisi, linux-doc, Enno Luebbers, Guido Kiener,
Thomas Gleixner, Kishon Vijay Abraham I, Jonathan Corbet, Wu Hao,
Kate Stewart, Tycho Andersen, Gerd Hoffmann, Jilayne Lovejoy
In-Reply-To: <20190604185953.GA2061@kroah.com>
On Tue, 04 Jun 2019, Greg Kroah-Hartman wrote:
> On Tue, Jun 04, 2019 at 11:39:21AM -0700, Guenter Roeck wrote:
> > On Tue, Jun 4, 2019 at 11:35 AM Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Tue, Jun 04, 2019 at 01:58:38PM -0300, Ezequiel Garcia wrote:
> > > > Hey Greg,
> > > >
> > > > > > + dev_info(&pdev->dev, "Created misc device /dev/%s\n",
> > > > > > + data->misc.name);
> > > > >
> > > > > No need to be noisy, if all goes well, your code should be quiet.
> > > > >
> > > >
> > > > I sometimes wonder about this being noise or not, so I will slightly
> > > > hijack this thread for this discussion.
> > > >
> > > > >From a kernel developer point-of-view, or even from a platform
> > > > developer or user with a debugging hat point-of-view, having
> > > > a "device created" or "device registered" message is often very useful.
> > >
> > > For you, yes. For someone with 30000 devices attached to their system,
> > > it is not, and causes booting to take longer than it should be.
Who has 30,000 devices attached to their systems? I would argue that
in these special corner-cases, they should knock the log-level *down*
a notch. For the rest of us who run normal platforms, an extra second
of boot time renders a more forthcoming/useful system than if each of
our devices initialised silently.
Personally I like to know what devices I have on my system, and the
kernel log is the first place I look. As far as I'm concerned, for
the most part, if it's not in the kernel log, I don't have it.
"Oh wow, I didn't know I had XXX functionality on this platform."
In my real job, I am currently enabling some newly released AArch64
based laptops for booting with ACPI. I must have wasted a day whilst
enabling some of the devices the system relies upon, just to find
out that 90% of them were actually probing semi-fine (at least probe()
was succeeding), just silently. *grumble*
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v2 06/22] docs: mark orphan documents as such
From: Andrew Donnellan @ 2019-06-05 6:16 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet,
Frederic Barrat, Maxime Coquelin, Alexandre Torgue,
Maarten Lankhorst, Maxime Ripard, Sean Paul, David Airlie,
Daniel Vetter, Georgi Djakov, Matan Ziv-Av,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
linuxppc-dev, linux-stm32, linux-arm-kernel, dri-devel, linux-pm,
platform-driver-x86
In-Reply-To: <4afa83787acec906c383978dc01f286940e28616.1559656538.git.mchehab+samsung@kernel.org>
On 5/6/19 12:17 am, Mauro Carvalho Chehab wrote:
> Sphinx doesn't like orphan documents:
>
> Documentation/accelerators/ocxl.rst: WARNING: document isn't included in any toctree
> Documentation/arm/stm32/overview.rst: WARNING: document isn't included in any toctree
> Documentation/arm/stm32/stm32f429-overview.rst: WARNING: document isn't included in any toctree
> Documentation/arm/stm32/stm32f746-overview.rst: WARNING: document isn't included in any toctree
> Documentation/arm/stm32/stm32f769-overview.rst: WARNING: document isn't included in any toctree
> Documentation/arm/stm32/stm32h743-overview.rst: WARNING: document isn't included in any toctree
> Documentation/arm/stm32/stm32mp157-overview.rst: WARNING: document isn't included in any toctree
> Documentation/gpu/msm-crash-dump.rst: WARNING: document isn't included in any toctree
> Documentation/interconnect/interconnect.rst: WARNING: document isn't included in any toctree
> Documentation/laptops/lg-laptop.rst: WARNING: document isn't included in any toctree
> Documentation/powerpc/isa-versions.rst: WARNING: document isn't included in any toctree
> Documentation/virtual/kvm/amd-memory-encryption.rst: WARNING: document isn't included in any toctree
> Documentation/virtual/kvm/vcpu-requests.rst: WARNING: document isn't included in any toctree
>
> So, while they aren't on any toctree, add :orphan: to them, in order
> to silent this warning.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
ocxl:
Acked-by: Andrew Donnellan <ajd@linux.ibm.com>
We should find somewhere to put it...
> ---
> Documentation/accelerators/ocxl.rst | 2 ++
> Documentation/arm/stm32/overview.rst | 2 ++
> Documentation/arm/stm32/stm32f429-overview.rst | 2 ++
> Documentation/arm/stm32/stm32f746-overview.rst | 2 ++
> Documentation/arm/stm32/stm32f769-overview.rst | 2 ++
> Documentation/arm/stm32/stm32h743-overview.rst | 2 ++
> Documentation/arm/stm32/stm32mp157-overview.rst | 2 ++
> Documentation/gpu/msm-crash-dump.rst | 2 ++
> Documentation/interconnect/interconnect.rst | 2 ++
> Documentation/laptops/lg-laptop.rst | 2 ++
> Documentation/powerpc/isa-versions.rst | 2 ++
> 11 files changed, 22 insertions(+)
>
> diff --git a/Documentation/accelerators/ocxl.rst b/Documentation/accelerators/ocxl.rst
> index 14cefc020e2d..b1cea19a90f5 100644
> --- a/Documentation/accelerators/ocxl.rst
> +++ b/Documentation/accelerators/ocxl.rst
> @@ -1,3 +1,5 @@
> +:orphan:
> +
> ========================================================
> OpenCAPI (Open Coherent Accelerator Processor Interface)
> ========================================================
> diff --git a/Documentation/arm/stm32/overview.rst b/Documentation/arm/stm32/overview.rst
> index 85cfc8410798..f7e734153860 100644
> --- a/Documentation/arm/stm32/overview.rst
> +++ b/Documentation/arm/stm32/overview.rst
> @@ -1,3 +1,5 @@
> +:orphan:
> +
> ========================
> STM32 ARM Linux Overview
> ========================
> diff --git a/Documentation/arm/stm32/stm32f429-overview.rst b/Documentation/arm/stm32/stm32f429-overview.rst
> index 18feda97f483..65bbb1c3b423 100644
> --- a/Documentation/arm/stm32/stm32f429-overview.rst
> +++ b/Documentation/arm/stm32/stm32f429-overview.rst
> @@ -1,3 +1,5 @@
> +:orphan:
> +
> STM32F429 Overview
> ==================
>
> diff --git a/Documentation/arm/stm32/stm32f746-overview.rst b/Documentation/arm/stm32/stm32f746-overview.rst
> index b5f4b6ce7656..42d593085015 100644
> --- a/Documentation/arm/stm32/stm32f746-overview.rst
> +++ b/Documentation/arm/stm32/stm32f746-overview.rst
> @@ -1,3 +1,5 @@
> +:orphan:
> +
> STM32F746 Overview
> ==================
>
> diff --git a/Documentation/arm/stm32/stm32f769-overview.rst b/Documentation/arm/stm32/stm32f769-overview.rst
> index 228656ced2fe..f6adac862b17 100644
> --- a/Documentation/arm/stm32/stm32f769-overview.rst
> +++ b/Documentation/arm/stm32/stm32f769-overview.rst
> @@ -1,3 +1,5 @@
> +:orphan:
> +
> STM32F769 Overview
> ==================
>
> diff --git a/Documentation/arm/stm32/stm32h743-overview.rst b/Documentation/arm/stm32/stm32h743-overview.rst
> index 3458dc00095d..c525835e7473 100644
> --- a/Documentation/arm/stm32/stm32h743-overview.rst
> +++ b/Documentation/arm/stm32/stm32h743-overview.rst
> @@ -1,3 +1,5 @@
> +:orphan:
> +
> STM32H743 Overview
> ==================
>
> diff --git a/Documentation/arm/stm32/stm32mp157-overview.rst b/Documentation/arm/stm32/stm32mp157-overview.rst
> index 62e176d47ca7..2c52cd020601 100644
> --- a/Documentation/arm/stm32/stm32mp157-overview.rst
> +++ b/Documentation/arm/stm32/stm32mp157-overview.rst
> @@ -1,3 +1,5 @@
> +:orphan:
> +
> STM32MP157 Overview
> ===================
>
> diff --git a/Documentation/gpu/msm-crash-dump.rst b/Documentation/gpu/msm-crash-dump.rst
> index 757cd257e0d8..240ef200f76c 100644
> --- a/Documentation/gpu/msm-crash-dump.rst
> +++ b/Documentation/gpu/msm-crash-dump.rst
> @@ -1,3 +1,5 @@
> +:orphan:
> +
> =====================
> MSM Crash Dump Format
> =====================
> diff --git a/Documentation/interconnect/interconnect.rst b/Documentation/interconnect/interconnect.rst
> index c3e004893796..56e331dab70e 100644
> --- a/Documentation/interconnect/interconnect.rst
> +++ b/Documentation/interconnect/interconnect.rst
> @@ -1,5 +1,7 @@
> .. SPDX-License-Identifier: GPL-2.0
>
> +:orphan:
> +
> =====================================
> GENERIC SYSTEM INTERCONNECT SUBSYSTEM
> =====================================
> diff --git a/Documentation/laptops/lg-laptop.rst b/Documentation/laptops/lg-laptop.rst
> index aa503ee9b3bc..f2c2ffe31101 100644
> --- a/Documentation/laptops/lg-laptop.rst
> +++ b/Documentation/laptops/lg-laptop.rst
> @@ -1,5 +1,7 @@
> .. SPDX-License-Identifier: GPL-2.0+
>
> +:orphan:
> +
> LG Gram laptop extra features
> =============================
>
> diff --git a/Documentation/powerpc/isa-versions.rst b/Documentation/powerpc/isa-versions.rst
> index 812e20cc898c..66c24140ebf1 100644
> --- a/Documentation/powerpc/isa-versions.rst
> +++ b/Documentation/powerpc/isa-versions.rst
> @@ -1,3 +1,5 @@
> +:orphan:
> +
> CPU to ISA Version Mapping
> ==========================
>
>
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH 00/15] kbuild: refactor headers_install and support compile-test of UAPI headers
From: Masahiro Yamada @ 2019-06-05 2:37 UTC (permalink / raw)
To: Linux Kbuild mailing list
Cc: Song Liu, open list:DOCUMENTATION, Benjamin Herrenschmidt,
Palmer Dabbelt, Heiko Carstens, Alexei Starovoitov, David Howells,
Paul Mackerras, linux-riscv, Vincent Chen, Sam Ravnborg,
linux-s390, Vasily Gorbik, Daniel Borkmann, Jonathan Corbet,
Michael Ellerman, Helge Deller, Christian Borntraeger,
Yonghong Song, arcml, Albert Ou, Arnd Bergmann, Jani Nikula,
Greentime Hu, James E.J. Bottomley, Michal Marek, linux-parisc,
Vineet Gupta, Randy Dunlap, Linux Kernel Mailing List, Networking,
bpf, linuxppc-dev, Martin KaFai Lau
In-Reply-To: <20190604101409.2078-1-yamada.masahiro@socionext.com>
On Tue, Jun 4, 2019 at 7:15 PM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
>
> Multiple people have suggested to compile-test UAPI headers.
>
> Currently, Kbuild provides simple sanity checks by headers_check
> but they are not enough to catch bugs.
>
> The most recent patch I know is David Howells' work:
> https://patchwork.kernel.org/patch/10590203/
>
> I agree that we need better tests for UAPI headers,
> but I want to integrate it in a clean way.
>
> The idea that has been in my mind is to compile each header
> to make sure the selfcontainedness.
For convenience, I pushed this series at
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
uapi-header-test-v1
(13/15 was replaced with v2)
If you want to test it quickly, please check-out it, then
$ make -j8 allmodconfig usr/
(As I noted in the commit log, you need to use
a compiler that provides <stdlib.h>, <sys/time.h>, etc.)
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH v2] Add a document on rebasing and merging
From: Theodore Ts'o @ 2019-06-05 1:54 UTC (permalink / raw)
To: Jonathan Corbet
Cc: linux-doc, LKML, Linus Torvalds, Geert Uytterhoeven,
David Rientjes
In-Reply-To: <20190604134835.16fc6bfa@lwn.net>
On Tue, Jun 04, 2019 at 01:48:35PM -0600, Jonathan Corbet wrote:
> +
> +Maintaining a subsystem, as a general rule, requires a familiarity with
> the +Git source-code management system. Git is a powerful tool with a lot
> of +features; as is often the case with such tools, there are right and
> wrong +ways to use those features. This document looks in particular at
> the use +of rebasing and merging. Maintainers often get in trouble when
> they use +those tools incorrectly, but avoiding problems is not actually
> all that +hard.
FYI, it looks like your patch somehow got hit by your text editor (or
MUA's) line wrapping...
> +
> + - Realize that the rebasing a patch series changes the environment in
> + which it was developed and, likely, invalidates much of the testing
> that
> + was done. A rebased patch series should, as a general rule, be treated
> + like new code and retested from the beginning.
Shouldn't "reparenting" be used in this paragraph?
I suppose if a patch is getting dropped or modified that can
invalidate some of the testing (although it really depends on the
nature of what's being dropped or modified). And if it's just adding
a Tested-by tag or a CVE number in the commit description, it's not
going to invalidate any testing.
As an aside, I wonder if git could pass down some kind of hint at "git
fetch" time that a particular branch is one that is subject to
frequent history rewriting, so it shouldn't be used as the basis for
further work (unless the developer is someone who is really good at
the "git rebase --onto ..." syntax).
> +Even in the absence of known conflicts, doing a test merge before sending
> a +pull request is a good idea. It may alert you to problems that you
> somehow +didn't see from linux-next and helps to understand exactly what
> you are +asking upstream to do.
Some maintainers will actually do a test merge and then run regression
tests on the result --- more than just a "it builds, ship it!" :-)
> +
> +Another reason for doing merges of upstream or another subsystem tree is
> to +resolve dependencies. These dependency issues do happen at times, and
> +sometimes a cross-merge with another tree is the best way to resolve them;
> +as always, in such situations, the merge commit should explain why the
> +merge has been done. Take a momehnt to do it right; people will read those
> +changelogs.
It might also be useful to mention it might be useful to put the
commits which are needed to solve the dependency problem on its own
separate branch, based off of something like -rc2, and then each of
the trees which need the prerequisite commits can merge in that
branch.
BTW, this is another example where, if we couldn't figure this out in
advance, I might consider it worthwhile to separate out prerequisite
patches, and reparent them on top of -rc2, so that other trees don't
have to do a cross-merge which pulls in half of some other subsystem's
branch. Rewriting history on one branch and reparenting the changes
so they are on their own branch might be a good tradeoff if it avoids
messy cross-merges on multiple other trees. It also avoids this
problem:
> .... If that subsystem tree fails to be pulled
> +upstream, whatever problems it had will block the merging of your tree as
> +well.
- Ted
^ permalink raw reply
* Re: [PATCH v4 04/18] kunit: test: add kunit_stream a std::stream like logger
From: Brendan Higgins @ 2019-06-05 0:47 UTC (permalink / raw)
To: Stephen Boyd
Cc: Frank Rowand, Greg KH, Josh Poimboeuf, Kees Cook, Kieran Bingham,
Luis Chamberlain, Peter Zijlstra, Rob Herring, shuah,
Theodore Ts'o, Masahiro Yamada, devicetree, dri-devel,
kunit-dev, open list:DOCUMENTATION, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK,
linux-nvdimm, linux-um, Sasha Levin, Bird, Timothy,
Amir Goldstein, Dan Carpenter, Daniel Vetter, Jeff Dike,
Joel Stanley, Julia Lawall, Kevin Hilman, Knut Omang,
Logan Gunthorpe, Michael Ellerman, Petr Mladek, Randy Dunlap,
Richard Weinberger, David Rientjes, Steven Rostedt, wfg
In-Reply-To: <20190517175841.F3396216FD@mail.kernel.org>
On Fri, May 17, 2019 at 10:58 AM Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting Brendan Higgins (2019-05-14 15:16:57)
> > diff --git a/kunit/kunit-stream.c b/kunit/kunit-stream.c
> > new file mode 100644
> > index 0000000000000..1884f1b550888
> > --- /dev/null
> > +++ b/kunit/kunit-stream.c
> > @@ -0,0 +1,152 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * C++ stream style string formatter and printer used in KUnit for outputting
> > + * KUnit messages.
> > + *
> > + * Copyright (C) 2019, Google LLC.
> > + * Author: Brendan Higgins <brendanhiggins@google.com>
> > + */
> > +
> > +#include <kunit/test.h>
> > +#include <kunit/kunit-stream.h>
> > +#include <kunit/string-stream.h>
> > +
> > +static const char *kunit_stream_get_level(struct kunit_stream *this)
> > +{
> > + unsigned long flags;
> > + const char *level;
> > +
> > + spin_lock_irqsave(&this->lock, flags);
> > + level = this->level;
> > + spin_unlock_irqrestore(&this->lock, flags);
> > +
> > + return level;
>
> Please remove this whole function and inline it to the one call-site.
>
> > +}
> > +
> > +void kunit_stream_set_level(struct kunit_stream *this, const char *level)
> > +{
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&this->lock, flags);
> > + this->level = level;
> > + spin_unlock_irqrestore(&this->lock, flags);
>
> I don't get the locking here. What are we protecting against? Are tests
> running in parallel using the same kunit_stream? If so, why is the level
> changeable in one call and then adding strings is done in a different
> function call? It would make sense to combine the level setting and
> string adding so that it's one atomic operation if it's truly a parallel
> operation, or remove the locking entirely.
I think you are right. I am not sure it makes sense for two separate
threads to share a kunit_stream; even if locked properly, it would end
up printing out corrupted text.
In anycase, I think it makes sense to decide the level when the stream
is allocated which would sidestep this issue entirely.
> > +}
> > +
> > +void kunit_stream_add(struct kunit_stream *this, const char *fmt, ...)
> > +{
> > + va_list args;
> > + struct string_stream *stream = this->internal_stream;
> > +
> > + va_start(args, fmt);
> > +
> > + if (string_stream_vadd(stream, fmt, args) < 0)
> > + kunit_err(this->test, "Failed to allocate fragment: %s\n", fmt);
> > +
> > + va_end(args);
> > +}
> > +
> > +void kunit_stream_append(struct kunit_stream *this,
> > + struct kunit_stream *other)
> > +{
> > + struct string_stream *other_stream = other->internal_stream;
> > + const char *other_content;
> > +
> > + other_content = string_stream_get_string(other_stream);
> > +
> > + if (!other_content) {
> > + kunit_err(this->test,
> > + "Failed to get string from second argument for appending.\n");
> > + return;
> > + }
> > +
> > + kunit_stream_add(this, other_content);
> > +}
> > +
> > +void kunit_stream_clear(struct kunit_stream *this)
> > +{
> > + string_stream_clear(this->internal_stream);
> > +}
> > +
> > +void kunit_stream_commit(struct kunit_stream *this)
>
> Should this be rather called kunit_stream_flush()?
So the intention is that the string in the buffer will not get printed
out until commit is called. In this way, you can build up a message
and then decide not to print it. This is useful when you are parsing
through a lot of data that would be useful in debugging a failing or
broken test, but are not yet sure if it is going to pass or not.
I think flush has the connotation, that you are just forcing the
buffer to get written out now, but that it will happen regardless
eventually, where commit has the correct connotation that you *must*
call it in order to write out the data stored in the buffer.
Seems as though I should probably add this distinction to the
kernel-doc comment.
> > +{
> > + struct string_stream *stream = this->internal_stream;
> > + struct string_stream_fragment *fragment;
> > + const char *level;
> > + char *buf;
> > +
> > + level = kunit_stream_get_level(this);
> > + if (!level) {
> > + kunit_err(this->test,
> > + "Stream was committed without a specified log level.\n");
>
> Drop the full-stop?
Whoops, nice catch. Will fix in next revision.
> > + level = KERN_ERR;
> > + kunit_stream_set_level(this, level);
> > + }
> > +
> > + buf = string_stream_get_string(stream);
> > + if (!buf) {
> > + kunit_err(this->test,
>
> Can you grow a local variable for 'this->test'? It's used many times.
Sure, will fix in next revision.
> Also, 'this' is not very kernel idiomatic. We usually name variables by
> their type instead of 'this' which is a keyword in other languages.
> Perhaps it could be named 'kstream'?
Seems reasonable. Will fix in next revision.
> > + "Could not allocate buffer, dumping stream:\n");
> > + list_for_each_entry(fragment, &stream->fragments, node) {
> > + kunit_err(this->test, fragment->fragment);
> > + }
> > + kunit_err(this->test, "\n");
> > + goto cleanup;
> > + }
> > +
> > + kunit_printk(level, this->test, buf);
> > + kfree(buf);
> > +
> > +cleanup:
> > + kunit_stream_clear(this);
> > +}
> > +
> > +static int kunit_stream_init(struct kunit_resource *res, void *context)
> > +{
> > + struct kunit *test = context;
> > + struct kunit_stream *stream;
> > +
> > + stream = kzalloc(sizeof(*stream), GFP_KERNEL);
>
> Of course, here it's called 'stream', so maybe it should be 'kstream'
> here too.
Will do.
>
> > + if (!stream)
> > + return -ENOMEM;
> > +
> > + res->allocation = stream;
> > + stream->test = test;
> > + spin_lock_init(&stream->lock);
> > + stream->internal_stream = new_string_stream();
>
> Can new_string_stream() be renamed to alloc_string_stream()? Sorry, I
> just see so much C++ isms in here it's hard to read from the kernel
> developer perspective.
No problem. WIll fix in next revision.
> > +
> > + if (!stream->internal_stream) {
>
> Nitpick: Please join this to the "allocation" event above instead of
> keeping it separated.
Yeah, that's a lot cleaner. Will do.
> > + kfree(stream);
> > + return -ENOMEM;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static void kunit_stream_free(struct kunit_resource *res)
> > +{
> > + struct kunit_stream *stream = res->allocation;
> > +
> > + if (!string_stream_is_empty(stream->internal_stream)) {
> > + kunit_err(stream->test,
> > + "End of test case reached with uncommitted stream entries.\n");
> > + kunit_stream_commit(stream);
> > + }
> > +
> > + destroy_string_stream(stream->internal_stream);
> > + kfree(stream);
> > +}
> > +
> > +struct kunit_stream *kunit_new_stream(struct kunit *test)
> > +{
> > + struct kunit_resource *res;
> > +
> > + res = kunit_alloc_resource(test,
> > + kunit_stream_init,
> > + kunit_stream_free,
> > + test);
> > +
> > + if (res)
> > + return res->allocation;
> > + else
> > + return NULL;
>
> Don't have if (...) return ...; else return ..., just return instead of
> else.
Sorry. Will fix.
Thanks!
^ permalink raw reply
* Re: [PATCH v4 03/18] kunit: test: add string_stream a std::stream like string builder
From: Brendan Higgins @ 2019-06-05 0:19 UTC (permalink / raw)
To: Stephen Boyd
Cc: Frank Rowand, Greg KH, Josh Poimboeuf, Kees Cook, Kieran Bingham,
Luis Chamberlain, Peter Zijlstra, Rob Herring, shuah,
Theodore Ts'o, Masahiro Yamada, devicetree, dri-devel,
kunit-dev, open list:DOCUMENTATION, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK,
linux-nvdimm, linux-um, Sasha Levin, Bird, Timothy,
Amir Goldstein, Dan Carpenter, Daniel Vetter, Jeff Dike,
Joel Stanley, Julia Lawall, Kevin Hilman, Knut Omang,
Logan Gunthorpe, Michael Ellerman, Petr Mladek, Randy Dunlap,
Richard Weinberger, David Rientjes, Steven Rostedt, wfg
In-Reply-To: <20190517174300.7949F20848@mail.kernel.org>
On Fri, May 17, 2019 at 10:43 AM Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting Brendan Higgins (2019-05-14 15:16:56)
> > A number of test features need to do pretty complicated string printing
> > where it may not be possible to rely on a single preallocated string
> > with parameters.
> >
> > So provide a library for constructing the string as you go similar to
> > C++'s std::string.
> >
> > Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> > Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
>
> Is there any reason why we can't use the seqfile API for this? These
> both share a similar goal, formatting strings into a buffer to be read
> later. Maybe some new APIs would be needed to extract the buffer
> differently, but I hope we could share the code.
I can see why you are asking. It seems as though they are trying to do
*similar* things, and it seems possible that we might be able to
extract some common functionality out of seq_file that could replace
this; however, it looks like it would be require a significant
refactoring of seq_file to separate out the file system specific bits
from the more general stringbuilder functionality.
In my opinion, a refactoring like this makes no sense in this
patchset; it probably belongs in its own patchset (preferably as a
follow on). I also am not sure if the FS people would appreciate
indirection that serves them no benefit, but I can ask if you like.
> If it can't be used, can you please add the reasoning to the commit text
> here?
Will do.
Thanks!
^ permalink raw reply
* Re: [PATCH v4 02/18] kunit: test: add test resource management API
From: Brendan Higgins @ 2019-06-04 23:34 UTC (permalink / raw)
To: Stephen Boyd
Cc: Frank Rowand, Greg KH, Josh Poimboeuf, Kees Cook, Kieran Bingham,
Luis Chamberlain, Peter Zijlstra, Rob Herring, shuah,
Theodore Ts'o, Masahiro Yamada, devicetree, dri-devel,
kunit-dev, open list:DOCUMENTATION, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK,
linux-nvdimm, linux-um, Sasha Levin, Bird, Timothy,
Amir Goldstein, Dan Carpenter, Daniel Vetter, Jeff Dike,
Joel Stanley, Julia Lawall, Kevin Hilman, Knut Omang,
Logan Gunthorpe, Michael Ellerman, Petr Mladek, Randy Dunlap,
Richard Weinberger, David Rientjes, Steven Rostedt, wfg
In-Reply-To: <20190517003847.0962F2082E@mail.kernel.org>
On Thu, May 16, 2019 at 5:38 PM Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting Brendan Higgins (2019-05-14 15:16:55)
> > diff --git a/kunit/test.c b/kunit/test.c
> > index 86f65ba2bcf92..a15e6f8c41582 100644
> > --- a/kunit/test.c
> > +++ b/kunit/test.c
> [..]
> > +
> > +void *kunit_kmalloc(struct kunit *test, size_t size, gfp_t gfp)
> > +{
> > + struct kunit_kmalloc_params params;
> > + struct kunit_resource *res;
> > +
> > + params.size = size;
> > + params.gfp = gfp;
> > +
> > + res = kunit_alloc_resource(test,
> > + kunit_kmalloc_init,
> > + kunit_kmalloc_free,
> > + ¶ms);
> > +
> > + if (res)
> > + return res->allocation;
> > + else
> > + return NULL;
>
> Can be written as
>
> if (res)
> return ....
> return
>
> and some static analysis tools prefer this.
Sounds reasonable, will fix in next revision.
> > +}
> > +
> > +void kunit_cleanup(struct kunit *test)
> > +{
> > + struct kunit_resource *resource, *resource_safe;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&test->lock, flags);
>
> Ah ok, test->lock is protecting everything now? Does it need to be a
> spinlock, or can it be a mutex?
No it needs to be a spin lock. There are some conceivable
circumstances where the test object can be accessed by code in which
it isn't safe to sleep.
> > + list_for_each_entry_safe(resource,
> > + resource_safe,
> > + &test->resources,
> > + node) {
> > + kunit_free_resource(test, resource);
> > + }
> > + spin_unlock_irqrestore(&test->lock, flags);
> > +}
> > +
^ permalink raw reply
* Re: [PATCH v2 11/22] docs: it: license-rules.rst: get rid of warnings
From: Federico Vaga @ 2019-06-04 21:53 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <6a7cfac6d9a2f14475c8b9baef0f55e4996b9210.1559656538.git.mchehab+samsung@kernel.org>
On Tuesday, June 4, 2019 4:17:45 PM CEST Mauro Carvalho Chehab wrote:
> There's a wrong identation on a code block, and it tries to use
> a reference that was not defined at the Italian translation.
>
> Documentation/translations/it_IT/process/license-rules.rst:329: WARNING:
> Literal block expected; none found.
> Documentation/translations/it_IT/process/license-rules.rst:332: WARNING:
> Unexpected indentation.
> Documentation/translations/it_IT/process/license-rules.rst:339: WARNING:
> Block quote ends without a blank line; unexpected unindent.
> Documentation/translations/it_IT/process/license-rules.rst:341: WARNING:
> Unexpected indentation.
> Documentation/translations/it_IT/process/license-rules.rst:305: WARNING:
> Unknown target name: "metatags".
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Reviewed-by: Federico Vaga <federico.vaga@vaga.pv.it>
> ---
> .../it_IT/process/license-rules.rst | 28 +++++++++----------
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/translations/it_IT/process/license-rules.rst
> b/Documentation/translations/it_IT/process/license-rules.rst index
> f058e06996dc..4cd87a3a7bf9 100644
> --- a/Documentation/translations/it_IT/process/license-rules.rst
> +++ b/Documentation/translations/it_IT/process/license-rules.rst
> @@ -303,7 +303,7 @@ essere categorizzate in:
> LICENSES/dual
>
> I file in questa cartella contengono il testo completo della rispettiva
> - licenza e i suoi `Metatags`_. I nomi dei file sono identici agli
> + licenza e i suoi `Metatag`_. I nomi dei file sono identici agli
> identificatori di licenza SPDX che dovrebbero essere usati nei file
> sorgenti.
>
> @@ -326,19 +326,19 @@ essere categorizzate in:
>
> Esempio del formato del file::
>
> - Valid-License-Identifier: MPL-1.1
> - SPDX-URL: https://spdx.org/licenses/MPL-1.1.html
> - Usage-Guide:
> - Do NOT use. The MPL-1.1 is not GPL2 compatible. It may only be used
> for - dual-licensed files where the other license is GPL2 compatible. -
> If you end up using this it MUST be used together with a GPL2
> compatible - license using "OR".
> - To use the Mozilla Public License version 1.1 put the following SPDX
> - tag/value pair into a comment according to the placement guidelines in
> - the licensing rules documentation:
> - SPDX-License-Identifier: MPL-1.1
> - License-Text:
> - Full license text
> + Valid-License-Identifier: MPL-1.1
> + SPDX-URL: https://spdx.org/licenses/MPL-1.1.html
> + Usage-Guide:
> + Do NOT use. The MPL-1.1 is not GPL2 compatible. It may only be used
> for + dual-licensed files where the other license is GPL2 compatible.
> + If you end up using this it MUST be used together with a GPL2
> compatible + license using "OR".
> + To use the Mozilla Public License version 1.1 put the following SPDX
> + tag/value pair into a comment according to the placement guidelines
> in + the licensing rules documentation:
> + SPDX-License-Identifier: MPL-1.1
> + License-Text:
> + Full license text
^ permalink raw reply
* Re: [PATCH RFC] Rough draft document on merging and rebasing
From: Theodore Ts'o @ 2019-06-04 20:43 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: Linus Torvalds, LKML, linux-doc
In-Reply-To: <20190604130837.24ea1d7b@lwn.net>
On Tue, Jun 04, 2019 at 01:08:37PM -0600, Jonathan Corbet wrote:
> On Sat, 1 Jun 2019 11:42:48 -0400
> "Theodore Ts'o" <tytso@mit.edu> wrote:
>
> > Finally, I'm bit concerned about anything which states absolutes,
> > because there are people who tend to be real stickler for the rules,
> > and if they see something stated in absolute terms, they fail to
> > understand that there are exceptions that are well understood, and in
> > use for years before the existence of the document which is trying to
> > codify best practices.
>
> Hence the "there are exceptions" text at the bottom of the document :)
>
> Anyway, I'll rework it to try to take your comments into account. Maybe
> we should consistently say "rebasing" for changing the parent commit of a
> patch set, and "history modification" for the other tricks...?
Those names sound good to me. Thanks!!
- Ted
^ permalink raw reply
* Re: [PATCH v4 1/2] fTPM: firmware TPM running in TEE
From: Sasha Levin @ 2019-06-04 20:09 UTC (permalink / raw)
To: Sumit Garg
Cc: peterhuewe, Jarkko Sakkinen, jgg, corbet,
Linux Kernel Mailing List, linux-doc, linux-integrity,
Microsoft Linux Kernel List, Thirupathaiah Annapureddy,
Bryan Kelly (CSI), tee-dev
In-Reply-To: <CAFA6WYM1NrghG9qxUhrm76kopvBx9nmCL9XnRs11ysb2Yr0+Qw@mail.gmail.com>
On Tue, Jun 04, 2019 at 11:45:52AM +0530, Sumit Garg wrote:
>On Thu, 30 May 2019 at 20:58, Sasha Levin <sashal@kernel.org> wrote:
>> + /* Open context with TEE driver */
>> + pvt_data->ctx = tee_client_open_context(NULL, ftpm_tee_match, NULL,
>> + NULL);
>> + if (IS_ERR(pvt_data->ctx)) {
>> + dev_err(dev, "%s:tee_client_open_context failed\n", __func__);
>
>Is this well tested? I see this misleading error multiple times as
>follows although TEE driver works pretty well.
Yes, this was all functionally tested.
Why is this error message misleading? I'd be happy to fix it.
>Module built with "CONFIG_TCG_FTPM_TEE=y"
>
>[ 1.436878] ftpm-tee tpm@0: ftpm_tee_probe:tee_client_open_context failed
>[ 1.509471] ftpm-tee tpm@0: ftpm_tee_probe:tee_client_open_context failed
>[ 1.517268] ftpm-tee tpm@0: ftpm_tee_probe:tee_client_open_context failed
>[ 1.525596] ftpm-tee tpm@0: ftpm_tee_probe:tee_client_open_context failed
Does the TEE have the fTPM implementation and such? Could you provide
details about your testing environment (hardware, fTPM verions, etc)?
--
Thanks,
Sasha
^ permalink raw reply
* [PATCH v2] Add a document on rebasing and merging
From: Jonathan Corbet @ 2019-06-04 19:48 UTC (permalink / raw)
To: linux-doc
Cc: LKML, Linus Torvalds, Theodore Ts'o, Geert Uytterhoeven,
David Rientjes
Every merge window seems to involve at least one episode where subsystem
maintainers don't manage their trees as Linus would like. Document the
expectations so that at least he has something to point people to.
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
Changes in v2:
- Try to clear up "reparenting" v. "history modification"
- Make the "don't rebase public branches" rule into more of a guideline
- Fix typos noted by Geert
- Rename the document to better reflect its contents
Documentation/maintainer/index.rst | 1 +
.../maintainer/rebasing-and-merging.rst | 216 ++++++++++++++++++
2 files changed, 217 insertions(+)
create mode 100644 Documentation/maintainer/rebasing-and-merging.rst
diff --git a/Documentation/maintainer/index.rst
b/Documentation/maintainer/index.rst index 2a14916930cb..56e2c09dfa39
100644 --- a/Documentation/maintainer/index.rst
+++ b/Documentation/maintainer/index.rst
@@ -10,5 +10,6 @@ additions to this manual.
:maxdepth: 2
configure-git
+ rebasing-and-merging
pull-requests
diff --git a/Documentation/maintainer/rebasing-and-merging.rst
b/Documentation/maintainer/rebasing-and-merging.rst new file mode 100644
index 000000000000..2987bd45dfb2
--- /dev/null
+++ b/Documentation/maintainer/rebasing-and-merging.rst
@@ -0,0 +1,216 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+====================
+Rebasing and merging
+====================
+
+Maintaining a subsystem, as a general rule, requires a familiarity with
the +Git source-code management system. Git is a powerful tool with a lot
of +features; as is often the case with such tools, there are right and
wrong +ways to use those features. This document looks in particular at
the use +of rebasing and merging. Maintainers often get in trouble when
they use +those tools incorrectly, but avoiding problems is not actually
all that +hard.
+
+One thing to be aware of in general is that, unlike many other projects,
+the kernel community is not scared by seeing merge commits in its
+development history. Indeed, given the scale of the project, avoiding
+merges would be nearly impossible. Some problems encountered by
+maintainers result from a desire to avoid merges, while others come from
+merging a little too often.
+
+Rebasing
+========
+
+"Rebasing" is the process of changing the history of a series of commits
+within a repository. There are two different types of operations that are
+referred to as rebasing since both are done with the ``git rebase``
+command, but there are significant differences between them:
+
+ - Rebasing can change the parent (starting) commit upon which a series of
+ patches is built. For example, a rebase operation could take a patch
+ set built on the previous kernel release and base it, instead, on the
+ current release. We'll call this operation "reparenting" in the
+ discussion below.
+
+ - Changing the history of a set of patches by fixing (or deleting) broken
+ commits, adding patches, adding tags to commit changelogs, or changing
+ the order in which commits are applied. In the following text, this
+ type of operation will be referred to as "history modification"
+
+The term "rebasing" will be used to refer to both of the above operations.
+Used properly, rebasing can yield a cleaner and clearer development
+history; used improperly, it can obscure that history and introduce bugs.
+
+There are a few rules of thumb that can help developers to avoid the worst
+perils of rebasing:
+
+ - History that has been exposed to the world beyond your private system
+ should usually not be changed. Others may have pulled a copy of your
+ tree and built on it; modifying your tree will create pain for them.
If
+ work is in need of rebasing, that is usually a sign that it is not yet
+ ready to be committed to a public repository.
+
+ That said, there are always exceptions. Some trees (linux-next being
+ a significant example) are frequently rebased by their nature, and
+ developers know not to base work on them. Developers will sometimes
+ expose an unstable branch for others to test with or for automated
+ testing services. If you do expose a branch that may be unstable in
+ this way, be sure that prospective users know not to base work on it.
+
+ - Do not rebase a branch that contains history created by others. If you
+ have pulled changes from another developer's repository, you are now a
+ custodian of their history. You should not change it. With few
+ exceptions, for example, a broken commit in a tree like this should be
+ explicitly reverted rather than disappeared via history modification.
+
+ - Do not reparent a tree without a good reason to do so. Just being on a
+ newer base or avoiding a merge with an upstream repository is not
+ generally a good reason.
+
+ - If you must reparent a repository, do not pick some random kernel
commit
+ as the new base. The kernel is often in a relatively unstable state
+ between release points; basing development on one of those points
+ increases the chances of running into surprising bugs. When a patch
+ series must move to a new base, pick a stable point (such as one of
+ the -rc releases) to move to.
+
+ - Realize that the rebasing a patch series changes the environment in
+ which it was developed and, likely, invalidates much of the testing
that
+ was done. A rebased patch series should, as a general rule, be treated
+ like new code and retested from the beginning.
+
+A frequent cause of merge-window trouble is when Linus is presented with a
+patch series that has clearly been reparented, often to a random commit,
+shortly before the pull request was sent. The chances of such a series
+having been adequately tested are relatively low - as are the chances of
+the pull request being acted upon.
+
+If, instead, rebasing is limited to private trees, commits are based on a
+well-known starting point, and they are well tested, the potential for
+trouble is low.
+
+Merging
+=======
+
+Merging is a common operation in the kernel development process; the 5.1
+development cycle included 1,126 merge commits - nearly 9% of the total.
+Kernel work is accumulated in over 100 different subsystem trees, each of
+which may contain multiple topic branches; each branch is usually
developed +independently of the others. So naturally, at least merge will
be required +before any given branch finds its way into an upstream
repository. +
+Many projects require that branches in pull requests be based on the
+current trunk so that no merge commits appear in the history. The kernel
+is not such a project; any rebasing of branches to avoid merges will, as
+described above, lead to certain trouble.
+
+Subsystem maintainers find themselves having to do two types of merges:
+from lower-level subsystem trees and from others, either sibling trees or
+the mainline. The best practices to follow differ in those two
situations. +
+Merging from lower-level trees
+------------------------------
+
+Larger subsystems tend to have multiple levels of maintainers, with the
+lower-level maintainers sending pull requests to the higher levels.
Acting +on such a pull request will almost certainly generate a merge
commit; that +is as it should be. In fact, subsystem maintainers may want
to use +the --no-ff flag to force the addition of a merge commit in the
rare cases +where one would not normally be created so that the reasons
for the merge +can be recorded. The changelog for the merge should, for
any kind of +merge, say *why* the merge is being done. For a lower-level
tree, "why" is +usually a summary of the changes that will come with that
pull. +
+Maintainers at all levels should be using signed tags on their pull
+requests, and upstream maintainers should verify the tags when pulling
+branches. Failure to do so threatens the security of the development
+process as a whole.
+
+As per the rules outlined above, once you have merged somebody else's
+history into your tree, you cannot rebase that branch, even if you
+otherwise would be able to.
+
+Merging from sibling or upstream trees
+--------------------------------------
+
+While merges from downstream are common and unremarkable, merges from
other +trees tend to be a red flag when it comes time to push a branch
upstream. +Such merges need to be carefully thought about and well
justified, or +there's a good chance that a subsequent pull request will
be rejected. +
+It is natural to want to merge the master branch into a repository; it can
+help to make sure that there are no conflicts with parallel development
and +generally gives a warm, fuzzy feeling of being up-to-date. But this
+temptation should be avoided almost all of the time.
+
+Why is that? Merges with upstream will muddy the development history of
+your own branch. They will significantly increase your chances of
+encountering bugs from elsewhere in the community and make it hard to
+ensure that the work you are managing is stable and ready for upstream.
+Frequent merges can also obscure problems with the development process in
+your tree; they can hide interactions with other trees that should not be
+happening (often) in a well-managed branch.
+
+One of the most frequent causes of merge-related trouble is when a
+maintainer merges with the upstream in order to resolve merge conflicts
+before sending a pull request. Again, this temptation is easy enough to
+understand, but it should absolutely be avoided. This is especially true
+for the final pull request: Linus is adamant that he would much rather see
+merge conflicts than unnecessary back merges. Seeing the conflicts lets
+him know where potential problem areas are. He does a lot of merges (382
+in the 5.1 development cycle) and has gotten quite good at conflict
+resolution - often better than the developers involved.
+
+So what should a maintainer do when there is a conflict between their
+subsystem branch and the mainline? The most important step is to warn
+Linus in the pull request that the conflict will happen; if nothing else,
+that demonstrates an awareness of how your branch fits into the whole.
For +especially difficult conflicts, create and push a *separate* branch
to show +how you would resolve things. Mention that branch in your pull
request, +but the pull request itself should be for the unmerged branch.
+
+Even in the absence of known conflicts, doing a test merge before sending
a +pull request is a good idea. It may alert you to problems that you
somehow +didn't see from linux-next and helps to understand exactly what
you are +asking upstream to do.
+
+Another reason for doing merges of upstream or another subsystem tree is
to +resolve dependencies. These dependency issues do happen at times, and
+sometimes a cross-merge with another tree is the best way to resolve them;
+as always, in such situations, the merge commit should explain why the
+merge has been done. Take a moment to do it right; people will read those
+changelogs.
+
+Often, though, dependency issues indicate that a change of approach is
+needed. Merging another subsystem tree to resolve a dependency risks
+bringing in other bugs. If that subsystem tree fails to be pulled
+upstream, whatever problems it had will block the merging of your tree as
+well. Possible alternatives include agreeing with the maintainer to carry
+both sets of changes in one of the trees or creating a special branch
+dedicated to the dependent commits. If the dependency is related to major
+infrastructural changes, the right solution might be to hold the dependent
+commits for one development cycle so that those changes have time to
+stabilize in the mainline.
+
+Finally
+=======
+
+It is relatively common to merge with the mainline toward the beginning of
+the development cycle in order to pick up changes and fixes done elsewhere
+in the tree. As always, such a merge should pick a well-known release
+point rather than some random spot. If your upstream-bound branch has
+emptied entirely into the mainline during the merge window, you can pull
it +forward with a command like::
+
+ git merge v5.2-rc1^0
+
+The "^0" will cause Git to do a fast-forward merge (which should be
+possible in this situation), thus avoiding the addition of a spurious
merge +commit.
+
+The guidelines laid out above are just that: guidelines. There will
always +be situations that call out for a different solution, and these
guidelines +should not prevent developers from doing the right thing when
the need +arises. But one should always think about whether the need has
truly +arisen and be prepared to explain why something abnormal needs to
be done. --
2.21.0
^ permalink raw reply related
* Re: [PATCH] Documentation/dm-init: fix multi device example
From: Stephen Boyd @ 2019-06-04 19:37 UTC (permalink / raw)
To: Helen Koike, dm-devel
Cc: wad, keescook, snitzer, linux-doc, richard.weinberger,
linux-kernel, linux-lvm, enric.balletbo, kernel, agk, Helen Koike,
Jonathan Corbet
In-Reply-To: <20190604182719.15944-1-helen.koike@collabora.com>
Quoting Helen Koike (2019-06-04 11:27:19)
> The example in the docs regarding multiple device-mappers is invalid (it
> has a wrong number of arguments), it's a left over from previous
> versions of the patch.
> Replace the example with an valid and tested one.
>
> Signed-off-by: Helen Koike <helen.koike@collabora.com>
>
> ---
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
^ permalink raw reply
* Re: [PATCH v12] dm: add support to directly boot to a mapped device
From: Stephen Boyd @ 2019-06-04 19:35 UTC (permalink / raw)
To: Helen Koike, dm-devel
Cc: wad, keescook, snitzer, linux-doc, richard.weinberger,
linux-kernel, linux-lvm, enric.balletbo, kernel, agk
In-Reply-To: <d6b4fb26-9a1b-0acd-ce4a-e48322a17e7d@collabora.com>
Quoting Helen Koike (2019-06-04 10:38:59)
> On 6/3/19 8:02 PM, Stephen Boyd wrote:
> >
> > I'm trying to boot a mainline linux kernel on a chromeos device with dm
> > verity and a USB stick but it's not working for me even with this patch.
> > I've had to hack around two problems:
> >
> > 1) rootwait isn't considered
> >
> > 2) verity doesn't seem to accept UUID for <hash_dev> or <dev>
> >
> > For the first problem, it happens every boot for me because I'm trying
> > to boot off of a USB stick and it's behind a hub that takes a few
> > seconds to enumerate. If I hack up the code to call dm_init_init() after
> > the 'rootdelay' cmdline parameter is used then I can make this work. It
> > would be much nicer if the whole mechanism didn't use a late initcall
> > though. If it used a hook from prepare_namespace() and then looped
> > waiting for devices to create when rootwait was specified it would work.
>
> The patch was implemented with late initcall partially to be contained
> in drivers/md/*, but to support rootwait, adding a hook from
> prepare_namespace seems the way to go indeed.
Alright, great.
>
> >
> > The second problem is that in chromeos we have the bootloader fill out
> > the UUID of the kernel partition (%U) and then we have another parameter
> > that indicates the offset from that kernel partition to add to the
> > kernel partition (typically 1, i.e. PARTNROFF=1) to find the root
> > filesystem partition. The way verity seems to work here is that we need
> > to specify a path like /dev/sda3 or the major:minor number of the device
> > on the commandline to make this work. It would be better if we could add
> > in support for the PARTNROFF style that name_to_dev_t() handles so we
> > can specify the root partition like we're currently doing. I suspect we
> > should be able to add support for this into the device mapper layer so
> > that we can specify devices this way.
>
> hmm, I didn't test this yet but at least from what I can see in the
> code, verity_ctr() calls dm_get_device() that ends up calling
> name_to_dev_t() which should take care of PARTNROFF, this requires a bit
> more investigation.
>
Ok, thanks for pointing that out. Sorry I totally missed this codepath
and I should have investigated more. It works for me with the PARTNROFF
syntax that we've been using, so the problem is the rootwait stuff.
^ permalink raw reply
* Re: [PATCH RFC] Rough draft document on merging and rebasing
From: Geert Uytterhoeven @ 2019-06-04 19:32 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Theodore Ts'o, Linus Torvalds, LKML, open list:DOCUMENTATION
In-Reply-To: <20190604130837.24ea1d7b@lwn.net>
Hi Jon,
On Tue, Jun 4, 2019 at 9:09 PM Jonathan Corbet <corbet@lwn.net> wrote:
> On Sat, 1 Jun 2019 11:42:48 -0400
> "Theodore Ts'o" <tytso@mit.edu> wrote:
> > Finally, I'm bit concerned about anything which states absolutes,
> > because there are people who tend to be real stickler for the rules,
> > and if they see something stated in absolute terms, they fail to
> > understand that there are exceptions that are well understood, and in
> > use for years before the existence of the document which is trying to
> > codify best practices.
>
> Hence the "there are exceptions" text at the bottom of the document :)
>
> Anyway, I'll rework it to try to take your comments into account. Maybe
> we should consistently say "rebasing" for changing the parent commit of a
> patch set, and "history modification" for the other tricks...?
Or just "reworking a branch" for the other tricks?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v12] dm: add support to directly boot to a mapped device
From: Ezequiel Garcia @ 2019-06-04 19:21 UTC (permalink / raw)
To: Helen Koike, Stephen Boyd, dm-devel
Cc: wad, keescook, snitzer, linux-doc, richard.weinberger,
linux-kernel, linux-lvm, enric.balletbo, kernel, agk
In-Reply-To: <d6b4fb26-9a1b-0acd-ce4a-e48322a17e7d@collabora.com>
Hi Stephen,
On Tue, 2019-06-04 at 14:38 -0300, Helen Koike wrote:
> Hi Stephen,
>
> On 6/3/19 8:02 PM, Stephen Boyd wrote:
> > Quoting Helen Koike (2019-02-21 12:33:34)
> > > Add a "create" module parameter, which allows device-mapper targets to be
> > > configured at boot time. This enables early use of dm targets in the boot
> > > process (as the root device or otherwise) without the need of an initramfs.
> > >
> > > The syntax used in the boot param is based on the concise format from the
> > > dmsetup tool to follow the rule of least surprise:
> > >
> > > sudo dmsetup table --concise /dev/mapper/lroot
> > >
> > > Which is:
> > > dm-mod.create=<name>,<uuid>,<minor>,<flags>,<table>[,<table>+][;<name>,<uuid>,<minor>,<flags>,<table>[,<table>+]+]
> > >
> > > Where,
> > > <name> ::= The device name.
> > > <uuid> ::= xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | ""
> > > <minor> ::= The device minor number | ""
> > > <flags> ::= "ro" | "rw"
> > > <table> ::= <start_sector> <num_sectors> <target_type> <target_args>
> > > <target_type> ::= "verity" | "linear" | ...
> > >
> > > For example, the following could be added in the boot parameters:
> > > dm-mod.create="lroot,,,rw, 0 4096 linear 98:16 0, 4096 4096 linear 98:32 0" root=/dev/dm-0
> > >
> > > Only the targets that were tested are allowed and the ones that doesn't
> > > change any block device when the dm is create as read-only. For example,
> > > mirror and cache targets are not allowed. The rationale behind this is
> > > that if the user makes a mistake, choosing the wrong device to be the
> > > mirror or the cache can corrupt data.
> > >
> > > The only targets allowed are:
> > > * crypt
> > > * delay
> > > * linear
> > > * snapshot-origin
> > > * striped
> > > * verity
> > >
> > > Co-developed-by: Will Drewry <wad@chromium.org>
> > > Co-developed-by: Kees Cook <keescook@chromium.org>
> > > Co-developed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> > > Signed-off-by: Helen Koike <helen.koike@collabora.com>
> > >
> > > ---
> > >
> >
> > I'm trying to boot a mainline linux kernel on a chromeos device with dm
> > verity and a USB stick but it's not working for me even with this patch.
> > I've had to hack around two problems:
> >
> > 1) rootwait isn't considered
> >
> > 2) verity doesn't seem to accept UUID for <hash_dev> or <dev>
> >
> > For the first problem, it happens every boot for me because I'm trying
> > to boot off of a USB stick and it's behind a hub that takes a few
> > seconds to enumerate. If I hack up the code to call dm_init_init() after
> > the 'rootdelay' cmdline parameter is used then I can make this work. It
> > would be much nicer if the whole mechanism didn't use a late initcall
> > though. If it used a hook from prepare_namespace() and then looped
> > waiting for devices to create when rootwait was specified it would work.
>
> The patch was implemented with late initcall partially to be contained
> in drivers/md/*, but to support rootwait, adding a hook from
> prepare_namespace seems the way to go indeed.
>
Thanks for bringing this up.
Helen and I have been looking at this code, and we think it's possible
to move things around and add some helpers, so we can implement rootwait
behavior, without actually cluttering init/do_mounts.c.
And along the way, we might get the chance to clean-up this code even
further.
Regards,
Eze
^ permalink raw reply
* Re: [PATCH RFC] Rough draft document on merging and rebasing
From: Jonathan Corbet @ 2019-06-04 19:08 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Linus Torvalds, LKML, linux-doc
In-Reply-To: <20190601154248.GA17800@mit.edu>
On Sat, 1 Jun 2019 11:42:48 -0400
"Theodore Ts'o" <tytso@mit.edu> wrote:
> Finally, I'm bit concerned about anything which states absolutes,
> because there are people who tend to be real stickler for the rules,
> and if they see something stated in absolute terms, they fail to
> understand that there are exceptions that are well understood, and in
> use for years before the existence of the document which is trying to
> codify best practices.
Hence the "there are exceptions" text at the bottom of the document :)
Anyway, I'll rework it to try to take your comments into account. Maybe
we should consistently say "rebasing" for changing the parent commit of a
patch set, and "history modification" for the other tricks...?
Thanks for taking a look,
jon
^ permalink raw reply
* Re: [PATCH 03/10] mfd / platform: cros_ec: Miscellaneous character device to talk with the EC
From: Greg Kroah-Hartman @ 2019-06-04 18:59 UTC (permalink / raw)
To: Guenter Roeck
Cc: Ezequiel Garcia, Enric Balletbo i Serra, linux-kernel,
Gwendal Grignou, Guenter Roeck, Benson Leung, Lee Jones, kernel,
Dmitry Torokhov, Gustavo Pimentel, Randy Dunlap,
Lorenzo Pieralisi, linux-doc, Enno Luebbers, Guido Kiener,
Thomas Gleixner, Kishon Vijay Abraham I, Jonathan Corbet, Wu Hao,
Kate Stewart, Tycho Andersen, Gerd Hoffmann, Jilayne Lovejoy
In-Reply-To: <CABXOdTfU9KaBDhQcwvBGWCmVfnd02_ZFmPGtJsCtGQ-iO9A3Qw@mail.gmail.com>
On Tue, Jun 04, 2019 at 11:39:21AM -0700, Guenter Roeck wrote:
> On Tue, Jun 4, 2019 at 11:35 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, Jun 04, 2019 at 01:58:38PM -0300, Ezequiel Garcia wrote:
> > > Hey Greg,
> > >
> > > > > + dev_info(&pdev->dev, "Created misc device /dev/%s\n",
> > > > > + data->misc.name);
> > > >
> > > > No need to be noisy, if all goes well, your code should be quiet.
> > > >
> > >
> > > I sometimes wonder about this being noise or not, so I will slightly
> > > hijack this thread for this discussion.
> > >
> > > >From a kernel developer point-of-view, or even from a platform
> > > developer or user with a debugging hat point-of-view, having
> > > a "device created" or "device registered" message is often very useful.
> >
> > For you, yes. For someone with 30000 devices attached to their system,
> > it is not, and causes booting to take longer than it should be.
> >
> > > In fact, I wish people would do this more often, so I don't have to
> > > deal with dynamic debug, or hack my way:
> > >
> > > diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c
> > > index 4589631798c9..473549b26bb2 100644
> > > --- a/drivers/media/i2c/ov5647.c
> > > +++ b/drivers/media/i2c/ov5647.c
> > > @@ -603,7 +603,7 @@ static int ov5647_probe(struct i2c_client *client,
> > > if (ret < 0)
> > > goto error;
> > >
> > > - dev_dbg(dev, "OmniVision OV5647 camera driver probed\n");
> > > + dev_info(dev, "OmniVision OV5647 camera driver probed\n");
> > > return 0;
> > > error:
> > > media_entity_cleanup(&sd->entity);
> > >
> > > In some subsystems, it's even a behavior I'm more or less relying on:
> > >
> > > $ git grep v4l2_info.*registered drivers/media/ | wc -l
> > > 26
> > >
> > > And on the downsides, I can't find much. It's just one little line,
> > > that is not even noticed unless you have logging turned on.
> >
> > Its better to be quiet, which is why the "default driver registration"
> > macros do not have any printk messages in them. When converting drivers
> > over to it, we made the boot process much more sane, don't try to go and
> > add messages for no good reason back in please.
> >
> > dynamic debugging can be enabled on a module and line-by-line basis,
> > even from the boot command line. So if you need debugging, you can
> > always ask someone to just reboot or unload/load the module and get the
> > message that way.
> >
>
> Can we by any chance make this an official policy ? I am kind of tired
> having to argue about this over and over again.
Sure, but how does anyone make any "official policy" in the kernel? :)
I could just go through and delete all "look ma, a new driver/device!"
messages, but that might be annoying...
thanks,
greg k-h
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox