On July 4, 2019 9:36:11 AM PDT, Daniel Kiper wrote:
>The setup_data is a bit awkward to use for extremely large data
>objects,
>both because the setup_data header has to be adjacent to the data
>object
>and because it has a 32-bit length field. However, it is important that
>intermediate stages of
On July 4, 2019 9:36:12 AM PDT, Daniel Kiper wrote:
>This field contains maximal allowed type for setup_data and
>setup_indirect structs.
>
>And finally bump setup_header version in arch/x86/boot/header.S.
>
>Suggested-by: H. Peter Anvin
>Signed-off-by: Daniel Kiper
>Reviewed-by: Ross Philipson
On July 4, 2019 9:36:10 AM PDT, Daniel Kiper wrote:
>The relationships between the headers are analogous to the various data
>sections:
>
> setup_header = .data
> boot_params/setup_data = .bss
>
>What is missing from the above list? That's right:
>
> kernel_info = .rodata
>
>We have been (ab)us
On September 25, 2019 11:01:39 PM PDT, Ingo Molnar wrote:
>* Cao jin wrote:
>
>> The fields marked with (reloc) actually are not dedicated for
>writing,
>> but communicating info for relocatable kernel with boot loaders. For
>> example:
>>
>>
>> Field name:
On September 26, 2019 12:55:51 AM PDT, Cao jin wrote:
>On 9/26/19 2:01 PM, Ingo Molnar wrote:
>> * Cao jin wrote:
>>
>>> The fields marked with (reloc) actually are not dedicated for
>writing,
>>> but communicating info for relocatable kernel with boot loaders. For
>>> example:
>>>
>>> =
On September 26, 2019 8:20:28 AM PDT, Randy Dunlap
wrote:
>On 9/26/19 12:58 AM, h...@zytor.com wrote:
>> On September 26, 2019 12:55:51 AM PDT, Cao jin
> wrote:
>>> On 9/26/19 2:01 PM, Ingo Molnar wrote:
* Cao jin wrote:
> The fields marked with (reloc) actually are not dedicated f
On September 26, 2019 1:20:02 AM PDT, Cao jin wrote:
>On 9/26/19 3:58 PM, h...@zytor.com wrote:
>> On September 26, 2019 12:55:51 AM PDT, Cao jin
> wrote:
>>> On 9/26/19 2:01 PM, Ingo Molnar wrote:
* Cao jin wrote:
> The fields marked with (reloc) actually are not dedicated for
>>>
On March 7, 2019 3:12:07 PM PST, Joel Fernandes wrote:
>Enrico,
>
>On Thu, Mar 07, 2019 at 11:11:22PM +0100, Enrico Weigelt, metux IT
>consult wrote:
>> On 07.03.19 21:55, Greg KH wrote:
>>
>> > Ick, no, no more squashfs please, let's just kill that mess once
>and for
>> > all :)
>>
>> okay, the
On May 29, 2019 7:15:00 AM PDT, Marco Elver wrote:
>This patch is a pre-requisite for enabling KASAN bitops
>instrumentation:
>moves boot_cpu_has feature test out of the uaccess region, as
>boot_cpu_has uses test_bit. With instrumentation, the KASAN check would
>otherwise be flagged by objtool.
>
On May 31, 2019 2:57:36 AM PDT, Marco Elver wrote:
>On Wed, 29 May 2019 at 16:29, wrote:
>>
>> On May 29, 2019 7:15:00 AM PDT, Marco Elver wrote:
>> >This patch is a pre-requisite for enabling KASAN bitops
>> >instrumentation:
>> >moves boot_cpu_has feature test out of the uaccess region, as
>>
On February 16, 2018 1:47:35 PM PST, Victor Kamensky wrote:
>
>
>On Fri, 16 Feb 2018, Rob Landley wrote:
>
>>
>> On 02/16/2018 02:59 PM, H. Peter Anvin wrote:
>>> On 02/16/18 12:33, Taras Kondratiuk wrote:
Many of the Linux security/integrity features are dependent on file
metadata, stor
On February 17, 2018 4:15:12 PM PST, Mimi Zohar
wrote:
>On Fri, 2018-02-16 at 12:59 -0800, H. Peter Anvin wrote:
>> On 02/16/18 12:33, Taras Kondratiuk wrote:
>> > Many of the Linux security/integrity features are dependent on file
>> > metadata, stored as extended attributes (xattrs), for making
On February 17, 2018 4:15:12 PM PST, Mimi Zohar
wrote:
>On Fri, 2018-02-16 at 12:59 -0800, H. Peter Anvin wrote:
>> On 02/16/18 12:33, Taras Kondratiuk wrote:
>> > Many of the Linux security/integrity features are dependent on file
>> > metadata, stored as extended attributes (xattrs), for making
On November 10, 2018 7:22:29 AM PST, Juergen Gross wrote:
>On 09/11/2018 23:23, H. Peter Anvin wrote:
>> I just noticed this patch -- I missed it because the cover message
>> seemed far more harmless so I didn't notice this change.
>>
>> THIS PATCH IS FATALLY WRONG AND NEEDS TO BE IMMEDIATELY REV
On January 19, 2019 3:25:03 PM PST, Joel Fernandes
wrote:
>On Sat, Jan 19, 2019 at 12:43:35PM -0500, Daniel Colascione wrote:
>> On Sat, Jan 19, 2019 at 11:27 AM Joel Fernandes
> wrote:
>> >
>> > On Sat, Jan 19, 2019 at 09:25:32AM +0100, Greg KH wrote:
>> > > On Fri, Jan 18, 2019 at 05:55:43PM -0
On January 19, 2019 2:36:06 AM PST, Greg KH wrote:
>On Sat, Jan 19, 2019 at 02:28:00AM -0800, Christoph Hellwig wrote:
>> This seems like a pretty horrible idea and waste of kernel memory.
>
>It's only a waste if you want it to be a waste, i.e. if you load the
>kernel module.
>
>This really isn't
On January 20, 2019 5:45:53 PM PST, Joel Fernandes
wrote:
>On Sun, Jan 20, 2019 at 01:58:15PM -0800, h...@zytor.com wrote:
>> On January 20, 2019 8:10:03 AM PST, Joel Fernandes
> wrote:
>> >On Sat, Jan 19, 2019 at 11:01:13PM -0800, h...@zytor.com wrote:
>> >> On January 19, 2019 2:36:06 AM PST, G
On January 20, 2019 8:10:03 AM PST, Joel Fernandes
wrote:
>On Sat, Jan 19, 2019 at 11:01:13PM -0800, h...@zytor.com wrote:
>> On January 19, 2019 2:36:06 AM PST, Greg KH
> wrote:
>> >On Sat, Jan 19, 2019 at 02:28:00AM -0800, Christoph Hellwig wrote:
>> >> This seems like a pretty horrible idea an
On January 24, 2019 12:59:29 PM PST, Joel Fernandes
wrote:
>On Thu, Jan 24, 2019 at 07:57:26PM +0100, Karim Yaghmour wrote:
>>
>> On 1/23/19 11:37 PM, Daniel Colascione wrote:
>[..]
>> > > Personally I advocated a more aggressive approach with Joel in
>private:
>> > > just put the darn headers s
On January 25, 2019 11:15:52 AM PST, Daniel Colascione
wrote:
>On Fri, Jan 25, 2019 at 11:01 AM wrote:
>>
>> On January 24, 2019 12:59:29 PM PST, Joel Fernandes
> wrote:
>> >On Thu, Jan 24, 2019 at 07:57:26PM +0100, Karim Yaghmour wrote:
>> >>
>> >> On 1/23/19 11:37 PM, Daniel Colascione wrote:
On October 25, 2016 4:36:41 PM PDT, Jonathan Corbet wrote:
>[Adding Peter to CC]
>
>On Mon, 24 Oct 2016 09:00:33 -0200
>Mauro Carvalho Chehab wrote:
>
>> Probably, unicode is something that we might remove from the
>> docs, as all modern systems support it. Yet, this chapter
>> is fun, as it ment
21 matches
Mail list logo
