On Wed, Mar 28, 2018 at 09:55:07AM -0700, Kees Cook wrote:
>On Wed, Mar 28, 2018 at 8:26 AM, Shea Levy wrote:
>> Now only those architectures that have custom initrd free requirements
>> need to define free_initrd_mem.
>>
>> Signed-off-by: Shea Levy
>
>Yay consolidation! :)
>
>> --- a/usr/Kconfig
On Thu, 29 Mar 2018 09:37:52 +1100
Oliver wrote:
> On Thu, Mar 29, 2018 at 9:14 AM, Russell King - ARM Linux
> wrote:
> > On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
> >>
> >>
> >> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
> >> > On Wed, Mar 28, 2018 at 10:58:5
On Thu, Mar 29, 2018 at 9:14 AM, Russell King - ARM Linux
wrote:
> On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
>>
>>
>> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
>> > On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
>> >> On 03/28/2018 10:26 AM, Shea Levy
On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
>
>
> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
> > On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
> >> On 03/28/2018 10:26 AM, Shea Levy wrote:
> >>> Now only those architectures that have custom initrd free
> On 28 Mar 2018, at 02:49, Matthew Wilcox wrote:
>
> On Tue, Mar 27, 2018 at 03:53:53PM -0700, Kees Cook wrote:
>> I agree: pushing this off to libc leaves a lot of things unprotected.
>> I think this should live in the kernel. The question I have is about
>> making it maintainable/readable/etc
Signed-off-by: Shea Levy
---
arch/arc/mm/init.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
index ba145065c579..7bcf23ab1756 100644
--- a/arch/arc/mm/init.c
+++ b/arch/arc/mm/init.c
@@ -229,10 +229,3 @@ void __ref free_initmem(void)
{
On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
> On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
>> On 03/28/2018 10:26 AM, Shea Levy wrote:
>>> Now only those architectures that have custom initrd free requirements
>>> need to define free_initrd_mem.
>> ...
>>> --- a/arch/a
> On 28 Mar 2018, at 01:16, Theodore Y. Ts'o wrote:
>
> On Tue, Mar 27, 2018 at 04:51:08PM +0300, Ilya Smith wrote:
>>> /dev/[u]random is not sufficient?
>>
>> Using /dev/[u]random makes 3 syscalls - open, read, close. This is a
>> performance
>> issue.
>
> You may want to take a look at the g
> On 27 Mar 2018, at 17:38, Michal Hocko wrote:
>
> On Tue 27-03-18 16:51:08, Ilya Smith wrote:
>>
>>> On 27 Mar 2018, at 10:24, Michal Hocko wrote:
>>>
>>> On Mon 26-03-18 22:45:31, Ilya Smith wrote:
> On 26 Mar 2018, at 11:46, Michal Hocko wrote:
>
> On Fri 23-03-18 20:5
On Wed, Mar 28, 2018 at 8:26 AM, Shea Levy wrote:
> Now only those architectures that have custom initrd free requirements
> need to define free_initrd_mem.
>
> Signed-off-by: Shea Levy
Yay consolidation! :)
> --- a/usr/Kconfig
> +++ b/usr/Kconfig
> @@ -233,3 +233,7 @@ config INITRAMFS_COMPRESS
On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
> On 03/28/2018 10:26 AM, Shea Levy wrote:
> > Now only those architectures that have custom initrd free requirements
> > need to define free_initrd_mem.
> ...
> > --- a/arch/arc/mm/init.c
> > +++ b/arch/arc/mm/init.c
> > @@ -229,10 +229,
Hi Rob,
Rob Landley writes:
> On 03/28/2018 10:26 AM, Shea Levy wrote:
>> Now only those architectures that have custom initrd free requirements
>> need to define free_initrd_mem.
> ...
>> --- a/arch/arc/mm/init.c
>> +++ b/arch/arc/mm/init.c
>> @@ -229,10 +229,3 @@ void __ref free_initmem(void)
On 03/28/2018 10:26 AM, Shea Levy wrote:
> Now only those architectures that have custom initrd free requirements
> need to define free_initrd_mem.
...
> --- a/arch/arc/mm/init.c
> +++ b/arch/arc/mm/init.c
> @@ -229,10 +229,3 @@ void __ref free_initmem(void)
> {
> free_initmem_default(-1);
>
Now only those architectures that have custom initrd free requirements
need to define free_initrd_mem.
Signed-off-by: Shea Levy
---
arch/alpha/mm/init.c | 8
arch/arc/mm/init.c| 7 ---
arch/arm/Kconfig | 1 +
arch/arm64/Kconfig| 1 +
arch/blackfin/K
Adding linux-snps and linux-arch mailing lists.
> Revert the clearing of __GFP_ZERO in dma_alloc_attrs and move it to
> dma_direct_alloc for now. While most common architectures always zero dma
> cohereny allocations (and x86 did so since day one) this is not documented
> and at least arc and s39
On Wed, Mar 28, 2018 at 2:04 PM, Christoph Hellwig wrote:
>> +#ifdef CONFIG_INITRAMFS_GENERIC_UNLOAD
>> +void free_initrd_mem(unsigned long start, unsigned long end)
>> +{
>> + free_reserved_area((void *)start, (void *)end, -1, "initrd");
>> +}
>> +#endif
>
> Given how trivial this is and ho
> +#ifdef CONFIG_INITRAMFS_GENERIC_UNLOAD
> +void free_initrd_mem(unsigned long start, unsigned long end)
> +{
> + free_reserved_area((void *)start, (void *)end, -1, "initrd");
> +}
> +#endif
Given how trivial this is and how many architectures can use it I'd
reverse the polarity and add a C
> > The logical question is why?
>
> 1. See that's another platform with ARC core so maybe in case of ARM
>DMA allocator already zeroes pages regardless provided flags -
>personally I didn't check that.
Yes, most architectures always clear memory returned by dma_alloc*.
Looks like a few d
18 matches
Mail list logo
