Re: [PATCH v3 -next 2/2] ARM: dts: sunxi: add support for Orange Pi Zero board
On Fri, Dec 02, 2016 at 11:05:13PM +0800, Icenowy Zheng wrote: > Orange Pi Zero is a board that came with the new Allwinner H2+ SoC and a > SDIO Wi-Fi chip by Allwinner (XR819). > > Add a device tree file for it. > > Signed-off-by: Icenowy Zheng Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [RFC PATCH v3 10/20] Add support to access boot related data in the clear
On 12/7/2016 7:19 AM, Matt Fleming wrote:
> On Wed, 09 Nov, at 06:36:31PM, Tom Lendacky wrote:
>> Boot data (such as EFI related data) is not encrypted when the system is
>> booted and needs to be accessed unencrypted. Add support to apply the
>> proper attributes to the EFI page tables and to the early_memremap and
>> memremap APIs to identify the type of data being accessed so that the
>> proper encryption attribute can be applied.
>>
>> Signed-off-by: Tom Lendacky
>> ---
>> arch/x86/include/asm/e820.h|1
>> arch/x86/kernel/e820.c | 16 +++
>> arch/x86/mm/ioremap.c | 89
>>
>> arch/x86/platform/efi/efi_64.c | 12 -
>> drivers/firmware/efi/efi.c | 33 +++
>> include/linux/efi.h|2 +
>> kernel/memremap.c |8 +++-
>> mm/early_ioremap.c | 18 +++-
>> 8 files changed, 172 insertions(+), 7 deletions(-)
>
> FWIW, I think this version is an improvement over all the previous
> ones.
>
> [...]
>
>> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
>> index ff542cd..ee347c2 100644
>> --- a/arch/x86/mm/ioremap.c
>> +++ b/arch/x86/mm/ioremap.c
>> @@ -20,6 +20,9 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>> +#include
>>
>> #include "physaddr.h"
>>
>> @@ -418,6 +421,92 @@ void unxlate_dev_mem_ptr(phys_addr_t phys, void *addr)
>> iounmap((void __iomem *)((unsigned long)addr & PAGE_MASK));
>> }
>>
>> +static bool memremap_setup_data(resource_size_t phys_addr,
>> +unsigned long size)
>> +{
>> +u64 paddr;
>> +
>> +if (phys_addr == boot_params.hdr.setup_data)
>> +return true;
>> +
>
> Why is the setup_data linked list not traversed when checking for
> matching addresses? Am I reading this incorrectly? I don't see how
> this can work.
Yeah, I caught that too after I sent this out. I think the best way to
handle this would be to create a list/array of setup data addresses in
the parse_setup_data() routine and then check the address against that
list in this routine.
>
>> +paddr = boot_params.efi_info.efi_memmap_hi;
>> +paddr <<= 32;
>> +paddr |= boot_params.efi_info.efi_memmap;
>> +if (phys_addr == paddr)
>> +return true;
>> +
>> +paddr = boot_params.efi_info.efi_systab_hi;
>> +paddr <<= 32;
>> +paddr |= boot_params.efi_info.efi_systab;
>> +if (phys_addr == paddr)
>> +return true;
>> +
>> +if (efi_table_address_match(phys_addr))
>> +return true;
>> +
>> +return false;
>> +}
>> +
>> +static bool memremap_apply_encryption(resource_size_t phys_addr,
>> + unsigned long size)
>> +{
>> +/* SME is not active, just return true */
>> +if (!sme_me_mask)
>> +return true;
>> +
>> +/* Check if the address is part of the setup data */
>> +if (memremap_setup_data(phys_addr, size))
>> +return false;
>> +
>> +/* Check if the address is part of EFI boot/runtime data */
>> +switch (efi_mem_type(phys_addr)) {
>> +case EFI_BOOT_SERVICES_DATA:
>> +case EFI_RUNTIME_SERVICES_DATA:
>> +return false;
>> +}
>
> EFI_LOADER_DATA is notable by its absence.
>
> We use that memory type for allocations inside of the EFI boot stub
> that are than used while the kernel is running. One use that comes to
> mind is for initrd files, see handle_cmdline_files().
>
> Oh I see you handle that in PATCH 9, never mind.
>
>> diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
>> index 58b0f80..3f89179 100644
>> --- a/arch/x86/platform/efi/efi_64.c
>> +++ b/arch/x86/platform/efi/efi_64.c
>> @@ -221,7 +221,13 @@ int __init efi_setup_page_tables(unsigned long
>> pa_memmap, unsigned num_pages)
>> if (efi_enabled(EFI_OLD_MEMMAP))
>> return 0;
>>
>> -efi_scratch.efi_pgt = (pgd_t *)__pa(efi_pgd);
>> +/*
>> + * Since the PGD is encrypted, set the encryption mask so that when
>> + * this value is loaded into cr3 the PGD will be decrypted during
>> + * the pagetable walk.
>> + */
>> +efi_scratch.efi_pgt = (pgd_t *)__sme_pa(efi_pgd);
>> +
>> pgd = efi_pgd;
>>
>> /*
>
> Do all callers of __pa() in arch/x86 need fixing up like this?
No, currently this is only be needed when we're dealing with values that
will be used in the cr3 register.
Thanks,
Tom
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pci-error-recover: doc cleanup
On Fri, 9 Dec 2016 14:37:47 +0800 Cao jin wrote: > I am little confused too, even not sure if we are talking the same > *fatal error*, I am talking the fatal error defined in PCI Express spec, > chapter 6.2.2.2.1: Therein lies my original discomfort with the change; it didn't seem to make sense to talk about recovering from a fatal error. Perhaps making it "is done whenever a fatal error (as defined in section 6.2.2.2.1) has been detected that can be "solved" by resetting the link" or something like that to make it clear how the term is being used? Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pci-error-recover: doc cleanup
On Fri, 9 Dec 2016 14:44:25 +0800 Linas Vepstas wrote: > On Fri, Dec 9, 2016 at 2:37 PM, Cao jin wrote: > > > > > > On 12/09/2016 02:24 PM, Linas Vepstas wrote: > >> I suppose I'm confused, but I recall that link resets are non-fatal. > >> Fatal errors typically require that the the pci adapter be completely > >> reset, any adapter firmware to be reloaded from scratch, the device > >> driver has to kill all device state and start from scratch. Its huge. > >> If the fatal error is on pci device that is under a block device > >> holding a file system, then (usually) there is no way to recover, > >> because the block layer (and file system) cannot deal with a block > >> device that disappeared and then reappeared some few seconds later. > >> (maybe some future zfs or lvm or btrfs might be able to deal with > >> this, but not today) > >> > >> By contrast, link resets are far more gentle: the device driver might > >> have to discard some half-full FIFO's, or cancel some in-flight > >> commands, but can otherwise gracefully recover without telling the > >> higher layers that there were any problems. > >> > >> --linas > >> > > > > I am little confused too, even not sure if we are talking the same > > *fatal error*, I am talking the fatal error defined in PCI Express spec, > > chapter 6.2.2.2.1: > > > > Fatal errors are uncorrectable error conditions which render the > > particular Link and related hardware unreliable. For Fatal errors, a > > reset of the components on the Link may be required to return to > > reliable operation. Platform handling of Fatal errors, and any efforts > > to limit the effects of these errors, is platform implementation specific. > > > > Link reset means set *secondary bus reset* bit in pci bridge config > > space, can reset the link and device simultaneously, is the strongest > > kind of reset as I know. > > OK, well, its been far too many years, and I don't have the PCI spec > at my fingertips. > Isn't there a link reset that can be performed, without forcing a device > reset? > > The intent was that some PCI link errors are due to vibration, > ground-bounce, humidity, etc. and that these errors can be detected > and do not corrupt the device state or the device driver state. Since > they are not associated with data corruption (or rather, the > corruption is local to the link), these can be recovered by reseting > just the link, without resetting the whole adapter. They may require > reseting some device-driver state, but not all of it. > > However, this was all decided before the PCI-E spec was written, so > maybe the newer PCI-E specs now say something different. Perhaps you're thinking of link retraining? That sort of error would be considered correctable, not fatal. Fatal errors are uncorrected errors and a bigger hammer is needed to deal with them, such as a link reset. Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 02/10] module: fix memory leak on early load_module() failures
On Thu, 8 Dec 2016, Luis R. Rodriguez wrote:
> While looking for early possible module loading failures I was
> able to reproduce a memory leak possible with kmemleak. There
> are a few rare ways to trigger a failure:
>
> o we've run into a failure while processing kernel parameters
> (parse_args() returns an error)
> o mod_sysfs_setup() fails
> o we're a live patch module and copy_module_elf() fails
>
> Chances of running into this issue is really low.
>
> kmemleak splat:
>
> unreferenced object 0x9f2c4ada1b00 (size 32):
> comm "kworker/u16:4", pid 82, jiffies 4294897636 (age 681.816s)
> hex dump (first 32 bytes):
> 6d 65 6d 73 74 69 63 6b 30 00 00 00 00 00 00 00 memstick0...
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> backtrace:
> [] kmemleak_alloc+0x4a/0xa0
> [] __kmalloc_track_caller+0x126/0x230
> [] kstrdup+0x31/0x60
> [] kstrdup_const+0x24/0x30
> [] kvasprintf_const+0x7a/0x90
> [] kobject_set_name_vargs+0x21/0x90
> [] dev_set_name+0x47/0x50
> [] memstick_check+0x95/0x33c [memstick]
> [] process_one_work+0x1f3/0x4b0
> [] worker_thread+0x48/0x4e0
> [] kthread+0xc9/0xe0
> [] ret_from_fork+0x1f/0x40
> [] 0x
>
> Signed-off-by: Luis R. Rodriguez
Reviewed-by: Miroslav Benes
What about
Fixes: e180a6b7759a ("param: fix charp parameters set via sysfs")
?
Miroslav
> ---
> kernel/module.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kernel/module.c b/kernel/module.c
> index f7482db0f843..e420ed67e533 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -3722,6 +3722,7 @@ static int load_module(struct load_info *info, const
> char __user *uargs,
> mod_sysfs_teardown(mod);
> coming_cleanup:
> mod->state = MODULE_STATE_GOING;
> + destroy_params(mod->kp, mod->num_kp);
> blocking_notifier_call_chain(&module_notify_list,
>MODULE_STATE_GOING, mod);
> klp_module_going(mod);
> --
> 2.10.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] dma-buf: Final bits of doc polish
- Put all the remaing bits of the old doc into suitable places in the new sphinx world. - Also document the poll support, we forgot to do that. - Delete dma-buf-sharing.txt. Cc: linux-doc@vger.kernel.org Cc: Jonathan Corbet Cc: Sumit Semwal Signed-off-by: Daniel Vetter --- Documentation/dma-buf-sharing.txt| 47 --- Documentation/driver-api/dma-buf.rst | 48 drivers/dma-buf/dma-buf.c| 22 + 3 files changed, 70 insertions(+), 47 deletions(-) delete mode 100644 Documentation/dma-buf-sharing.txt diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt deleted file mode 100644 index 74c99edb7976.. --- a/Documentation/dma-buf-sharing.txt +++ /dev/null @@ -1,47 +0,0 @@ -DMA Buffer Sharing API Guide - - -Sumit Semwal - - - - -Other Interfaces Exposed to Userspace on the dma-buf FD --- - -- Since kernel 3.12 the dma-buf FD supports the llseek system call, but only - with offset=0 and whence=SEEK_END|SEEK_SET. SEEK_SET is supported to allow - the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other - llseek operation will report -EINVAL. - - If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all - cases. Userspace can use this to detect support for discovering the dma-buf - size using llseek. - -Miscellaneous notes - -- Any exporters or users of the dma-buf buffer sharing framework must have - a 'select DMA_SHARED_BUFFER' in their respective Kconfigs. - -- In order to avoid fd leaks on exec, the FD_CLOEXEC flag must be set - on the file descriptor. This is not just a resource leak, but a - potential security hole. It could give the newly exec'd application - access to buffers, via the leaked fd, to which it should otherwise - not be permitted access. - - The problem with doing this via a separate fcntl() call, versus doing it - atomically when the fd is created, is that this is inherently racy in a - multi-threaded app[3]. The issue is made worse when it is library code - opening/creating the file descriptor, as the application may not even be - aware of the fd's. - - To avoid this problem, userspace must have a way to request O_CLOEXEC - flag be set when the dma-buf fd is created. So any API provided by - the exporting driver to create a dmabuf fd must provide a way to let - userspace control setting of O_CLOEXEC flag passed in to dma_buf_fd(). - -References: -[1] struct dma_buf_ops in include/linux/dma-buf.h -[2] All interfaces mentioned above defined in include/linux/dma-buf.h -[3] https://lwn.net/Articles/236486/ diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 92e417035e16..31671b469627 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -46,6 +46,48 @@ The buffer-user same area of memory. This interface is provided by :c:type:`struct dma_buf_attachment `. +Any exporters or users of the dma-buf buffer sharing framework must have a +'select DMA_SHARED_BUFFER' in their respective Kconfigs. + +Userspace Interface Notes +~ + +Mostly a DMA buffer file descriptor is simply an opaque object for userspace, +and hence the generic interface exposed is very minimal. There's a few things to +consider though: + +- Since kernel 3.12 the dma-buf FD supports the llseek system call, but only + with offset=0 and whence=SEEK_END|SEEK_SET. SEEK_SET is supported to allow + the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other + llseek operation will report -EINVAL. + + If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all + cases. Userspace can use this to detect support for discovering the dma-buf + size using llseek. + +- In order to avoid fd leaks on exec, the FD_CLOEXEC flag must be set + on the file descriptor. This is not just a resource leak, but a + potential security hole. It could give the newly exec'd application + access to buffers, via the leaked fd, to which it should otherwise + not be permitted access. + + The problem with doing this via a separate fcntl() call, versus doing it + atomically when the fd is created, is that this is inherently racy in a + multi-threaded app[3]. The issue is made worse when it is library code + opening/creating the file descriptor, as the application may not even be + aware of the fd's. + + To avoid this problem, userspace must have a way to request O_CLOEXEC + flag be set when the dma-buf fd is created. So any API provided by + the exporting driver to create a dmabuf fd must provide a way to let + userspace control setting of O_CLOEXEC flag passed in to dma_buf_fd(). + +- Memory mapp
[PATCH 3/5] dma-buf: Reorganize device dma access docs
- Put the initial overview for dma-buf into dma-buf.rst. - Put all the comments about detailed semantics into the right kernel-doc comment for functions or ops structure member. - To allow that detail, switch the reworked kerneldoc to inline style for dma_buf_ops. - Tie everything together into a much more streamlined overview comment, relying on the hyperlinks for all the details. - Also sprinkle some links into the kerneldoc for dma_buf and dma_buf_attachment to tie it all together. Cc: linux-doc@vger.kernel.org Cc: Jonathan Corbet Cc: Sumit Semwal Signed-off-by: Daniel Vetter --- Documentation/dma-buf-sharing.txt| 222 --- Documentation/driver-api/dma-buf.rst | 38 ++ drivers/dma-buf/dma-buf.c| 64 +- drivers/dma-buf/sync_file.c | 1 - include/linux/dma-buf.h | 133 + 5 files changed, 207 insertions(+), 251 deletions(-) diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index ca44c5820585..dca2fb7ac3b4 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -5,228 +5,6 @@ -This document serves as a guide to device-driver writers on what is the dma-buf -buffer sharing API, how to use it for exporting and using shared buffers. - -Any device driver which wishes to be a part of DMA buffer sharing, can do so as -either the 'exporter' of buffers, or the 'user' of buffers. - -Say a driver A wants to use buffers created by driver B, then we call B as the -exporter, and A as buffer-user. - -The exporter -- implements and manages operations[1] for the buffer -- allows other users to share the buffer by using dma_buf sharing APIs, -- manages the details of buffer allocation, -- decides about the actual backing storage where this allocation happens, -- takes care of any migration of scatterlist - for all (shared) users of this - buffer, - -The buffer-user -- is one of (many) sharing users of the buffer. -- doesn't need to worry about how the buffer is allocated, or where. -- needs a mechanism to get access to the scatterlist that makes up this buffer - in memory, mapped into its own address space, so it can access the same area - of memory. - -dma-buf operations for device dma only --- - -The dma_buf buffer sharing API usage contains the following steps: - -1. Exporter announces that it wishes to export a buffer -2. Userspace gets the file descriptor associated with the exported buffer, and - passes it around to potential buffer-users based on use case -3. Each buffer-user 'connects' itself to the buffer -4. When needed, buffer-user requests access to the buffer from exporter -5. When finished with its use, the buffer-user notifies end-of-DMA to exporter -6. when buffer-user is done using this buffer completely, it 'disconnects' - itself from the buffer. - - -1. Exporter's announcement of buffer export - - The buffer exporter announces its wish to export a buffer. In this, it - connects its own private buffer data, provides implementation for operations - that can be performed on the exported dma_buf, and flags for the file - associated with this buffer. All these fields are filled in struct - dma_buf_export_info, defined via the DEFINE_DMA_BUF_EXPORT_INFO macro. - - Interface: - DEFINE_DMA_BUF_EXPORT_INFO(exp_info) - struct dma_buf *dma_buf_export(struct dma_buf_export_info *exp_info) - - If this succeeds, dma_buf_export allocates a dma_buf structure, and - returns a pointer to the same. It also associates an anonymous file with this - buffer, so it can be exported. On failure to allocate the dma_buf object, - it returns NULL. - - 'exp_name' in struct dma_buf_export_info is the name of exporter - to - facilitate information while debugging. It is set to KBUILD_MODNAME by - default, so exporters don't have to provide a specific name, if they don't - wish to. - - DEFINE_DMA_BUF_EXPORT_INFO macro defines the struct dma_buf_export_info, - zeroes it out and pre-populates exp_name in it. - - -2. Userspace gets a handle to pass around to potential buffer-users - - Userspace entity requests for a file-descriptor (fd) which is a handle to the - anonymous file associated with the buffer. It can then share the fd with other - drivers and/or processes. - - Interface: - int dma_buf_fd(struct dma_buf *dmabuf, int flags) - - This API installs an fd for the anonymous file associated with this buffer; - returns either 'fd', or error. - -3. Each buffer-user 'connects' itself to the buffer - - Each buffer-user now gets a reference to the buffer, using the fd passed to - it. - - Interface: - struct dma_buf *dma_buf_get(int fd) - - This API will return a reference to the dma_buf, and increment refcount for - it. - - After this, the buffer-user needs to attach its device with the buffer, wh
[PATCH 4/5] dma-buf: Update cpu access documentation
- Again move the information relevant for driver writers next to the callbacks. - Put the overview and userspace interface documentation into a DOC: section within the code. - Remove the text that mmap needs to be coherent - since the DMA_BUF_IOCTL_SYNC landed that's no longer the case. But keep the text that for pte zapping exporters need to adjust the address space. - Add a FIXME that kmap and the new begin/end stuff used by the SYNC ioctl don't really mix correctly. That's something I just realized while doing this doc rework. - Augment function and structure docs like usual. Cc: linux-doc@vger.kernel.org Cc: Jonathan Corbet Cc: Sumit Semwal Signed-off-by: Daniel Vetter --- Documentation/dma-buf-sharing.txt| 213 --- Documentation/driver-api/dma-buf.rst | 6 + drivers/dma-buf/dma-buf.c| 121 include/linux/dma-buf.h | 91 +-- 4 files changed, 210 insertions(+), 221 deletions(-) diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index dca2fb7ac3b4..74c99edb7976 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -6,205 +6,6 @@ -Kernel cpu access to a dma-buf buffer object - - -The motivation to allow cpu access from the kernel to a dma-buf object from the -importers side are: -- fallback operations, e.g. if the devices is connected to a usb bus and the - kernel needs to shuffle the data around first before sending it away. -- full transparency for existing users on the importer side, i.e. userspace - should not notice the difference between a normal object from that subsystem - and an imported one backed by a dma-buf. This is really important for drm - opengl drivers that expect to still use all the existing upload/download - paths. - -Access to a dma_buf from the kernel context involves three steps: - -1. Prepare access, which invalidate any necessary caches and make the object - available for cpu access. -2. Access the object page-by-page with the dma_buf map apis -3. Finish access, which will flush any necessary cpu caches and free reserved - resources. - -1. Prepare access - - Before an importer can access a dma_buf object with the cpu from the kernel - context, it needs to notify the exporter of the access that is about to - happen. - - Interface: - int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, - enum dma_data_direction direction) - - This allows the exporter to ensure that the memory is actually available for - cpu access - the exporter might need to allocate or swap-in and pin the - backing storage. The exporter also needs to ensure that cpu access is - coherent for the access direction. The direction can be used by the exporter - to optimize the cache flushing, i.e. access with a different direction (read - instead of write) might return stale or even bogus data (e.g. when the - exporter needs to copy the data to temporary storage). - - This step might fail, e.g. in oom conditions. - -2. Accessing the buffer - - To support dma_buf objects residing in highmem cpu access is page-based using - an api similar to kmap. Accessing a dma_buf is done in aligned chunks of - PAGE_SIZE size. Before accessing a chunk it needs to be mapped, which returns - a pointer in kernel virtual address space. Afterwards the chunk needs to be - unmapped again. There is no limit on how often a given chunk can be mapped - and unmapped, i.e. the importer does not need to call begin_cpu_access again - before mapping the same chunk again. - - Interfaces: - void *dma_buf_kmap(struct dma_buf *, unsigned long); - void dma_buf_kunmap(struct dma_buf *, unsigned long, void *); - - There are also atomic variants of these interfaces. Like for kmap they - facilitate non-blocking fast-paths. Neither the importer nor the exporter (in - the callback) is allowed to block when using these. - - Interfaces: - void *dma_buf_kmap_atomic(struct dma_buf *, unsigned long); - void dma_buf_kunmap_atomic(struct dma_buf *, unsigned long, void *); - - For importers all the restrictions of using kmap apply, like the limited - supply of kmap_atomic slots. Hence an importer shall only hold onto at most 2 - atomic dma_buf kmaps at the same time (in any given process context). - - dma_buf kmap calls outside of the range specified in begin_cpu_access are - undefined. If the range is not PAGE_SIZE aligned, kmap needs to succeed on - the partial chunks at the beginning and end but may return stale or bogus - data outside of the range (in these partial chunks). - - Note that these calls need to always succeed. The exporter needs to complete - any preparations that might fail in begin_cpu_access. - - For some cases the overhead of kmap can be too high, a vmap interface -
[PATCH 2/5] dma-buf: Update kerneldoc for sync_file_create
This was missed when adding a dma_fence_get call. While at it also
remove the kerneldoc for the static inline helper - no point
documenting internals down to every detail.
Fixes: 30cd85dd6edc ("dma-buf/sync_file: hold reference to fence when creating
sync_file")
Cc: Gustavo Padovan
Cc: Sean Paul
Cc: linux-doc@vger.kernel.org
Cc: Jonathan Corbet
Cc: Sumit Semwal
Signed-off-by: Daniel Vetter
---
drivers/dma-buf/sync_file.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 6d802f2d2881..d5179d7e8575 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -67,9 +67,10 @@ static void fence_check_cb_func(struct dma_fence *f, struct
dma_fence_cb *cb)
* sync_file_create() - creates a sync file
* @fence: fence to add to the sync_fence
*
- * Creates a sync_file containg @fence. Once this is called, the sync_file
- * takes ownership of @fence. The sync_file can be released with
- * fput(sync_file->file). Returns the sync_file or NULL in case of error.
+ * Creates a sync_file containg @fence. This function acquires and additional
+ * reference of @fence for the newly-created &sync_file, if it succeeds. The
+ * sync_file can be released with fput(sync_file->file). Returns the
+ * sync_file or NULL in case of error.
*/
struct sync_file *sync_file_create(struct dma_fence *fence)
{
@@ -90,13 +91,6 @@ struct sync_file *sync_file_create(struct dma_fence *fence)
}
EXPORT_SYMBOL(sync_file_create);
-/**
- * sync_file_fdget() - get a sync_file from an fd
- * @fd:fd referencing a fence
- *
- * Ensures @fd references a valid sync_file, increments the refcount of the
- * backing file. Returns the sync_file or NULL in case of error.
- */
static struct sync_file *sync_file_fdget(int fd)
{
struct file *file = fget(fd);
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] dma-buf: Extract dma-buf.rst
Just prep work to polish and consolidate all the dma-buf related documenation. Unfortunately I didn't discover a way to both integrate this new file into the overall toc while keeping it at the current place. Work around that by moving it into the overall driver-api/index.rst. Cc: linux-doc@vger.kernel.org Cc: Jonathan Corbet Cc: Sumit Semwal Signed-off-by: Daniel Vetter --- Documentation/driver-api/dma-buf.rst| 73 + Documentation/driver-api/index.rst | 1 + Documentation/driver-api/infrastructure.rst | 70 --- include/linux/dma-fence.h | 1 - 4 files changed, 74 insertions(+), 71 deletions(-) create mode 100644 Documentation/driver-api/dma-buf.rst diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst new file mode 100644 index ..a9b457a4b949 --- /dev/null +++ b/Documentation/driver-api/dma-buf.rst @@ -0,0 +1,73 @@ +Buffer Sharing and Synchronization +== + +The dma-buf subsystem provides the framework for sharing buffers for +hardware (DMA) access across multiple device drivers and subsystems, and +for synchronizing asynchronous hardware access. + +This is used, for example, by drm "prime" multi-GPU support, but is of +course not limited to GPU use cases. + +The three main components of this are: (1) dma-buf, representing a +sg_table and exposed to userspace as a file descriptor to allow passing +between devices, (2) fence, which provides a mechanism to signal when +one device as finished access, and (3) reservation, which manages the +shared or exclusive fence(s) associated with the buffer. + +Shared DMA Buffers +-- + +.. kernel-doc:: drivers/dma-buf/dma-buf.c + :export: + +.. kernel-doc:: include/linux/dma-buf.h + :internal: + +Reservation Objects +--- + +.. kernel-doc:: drivers/dma-buf/reservation.c + :doc: Reservation Object Overview + +.. kernel-doc:: drivers/dma-buf/reservation.c + :export: + +.. kernel-doc:: include/linux/reservation.h + :internal: + +DMA Fences +-- + +.. kernel-doc:: drivers/dma-buf/dma-fence.c + :export: + +.. kernel-doc:: include/linux/dma-fence.h + :internal: + +Seqno Hardware Fences +~ + +.. kernel-doc:: drivers/dma-buf/seqno-fence.c + :export: + +.. kernel-doc:: include/linux/seqno-fence.h + :internal: + +DMA Fence Array +~~~ + +.. kernel-doc:: drivers/dma-buf/dma-fence-array.c + :export: + +.. kernel-doc:: include/linux/dma-fence-array.h + :internal: + +DMA Fence uABI/Sync File + + +.. kernel-doc:: drivers/dma-buf/sync_file.c + :export: + +.. kernel-doc:: include/linux/sync_file.h + :internal: + diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index 8e259c5d0322..1d9d2fe57179 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -16,6 +16,7 @@ available subsections can be seen below. basics infrastructure + dma-buf message-based sound frame-buffer diff --git a/Documentation/driver-api/infrastructure.rst b/Documentation/driver-api/infrastructure.rst index a0d65eb49055..0bb0b5fc9512 100644 --- a/Documentation/driver-api/infrastructure.rst +++ b/Documentation/driver-api/infrastructure.rst @@ -46,76 +46,6 @@ Device Drivers Base .. kernel-doc:: drivers/base/bus.c :export: -Buffer Sharing and Synchronization --- - -The dma-buf subsystem provides the framework for sharing buffers for -hardware (DMA) access across multiple device drivers and subsystems, and -for synchronizing asynchronous hardware access. - -This is used, for example, by drm "prime" multi-GPU support, but is of -course not limited to GPU use cases. - -The three main components of this are: (1) dma-buf, representing a -sg_table and exposed to userspace as a file descriptor to allow passing -between devices, (2) fence, which provides a mechanism to signal when -one device as finished access, and (3) reservation, which manages the -shared or exclusive fence(s) associated with the buffer. - -dma-buf -~~~ - -.. kernel-doc:: drivers/dma-buf/dma-buf.c - :export: - -.. kernel-doc:: include/linux/dma-buf.h - :internal: - -reservation -~~~ - -.. kernel-doc:: drivers/dma-buf/reservation.c - :doc: Reservation Object Overview - -.. kernel-doc:: drivers/dma-buf/reservation.c - :export: - -.. kernel-doc:: include/linux/reservation.h - :internal: - -fence -~ - -.. kernel-doc:: drivers/dma-buf/dma-fence.c - :export: - -.. kernel-doc:: include/linux/dma-fence.h - :internal: - -.. kernel-doc:: drivers/dma-buf/seqno-fence.c - :export: - -.. kernel-doc:: include/linux/seqno-fence.h - :internal: - -.. kernel-doc:: drivers/dma-buf/dma-fence-array.c - :export: - -.. kernel-doc:: include/linux/dma-fence-array.h - :internal: - -.. kernel-doc:: drivers/dma-buf/reservation.c -
Re: [RFC 10/10] kmod: add a sanity check on module loading
On Thu, 2016-12-08 at 11:49 -0800, Luis R. Rodriguez wrote:
>
> Although this does get us in the business of keeping alias maps in
> kernel, the the work to support and maintain this is trivial.
You've implemented a special treatment for request_module("fs-$X")in
finished_kmod_load(), but there are many more aliases defined (and
used) in the kernel. Do you plan to implement special code for "char-
major-$X", "crypto-$X", "binfmt-$X" etc. later?
Regards
Martin
--
Dr. Martin Wilck , Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 10/10] kmod: add a sanity check on module loading
On Fri, Dec 9, 2016 at 12:03 PM, Martin Wilck wrote:
> On Thu, 2016-12-08 at 11:49 -0800, Luis R. Rodriguez wrote:
>>
>> Although this does get us in the business of keeping alias maps in
>> kernel, the the work to support and maintain this is trivial.
>
> You've implemented a special treatment for request_module("fs-$X")in
> finished_kmod_load(), but there are many more aliases defined (and
> used) in the kernel. Do you plan to implement special code for "char-
> major-$X", "crypto-$X", "binfmt-$X" etc. later?
Yeah, no, that is just complete garbage.
Those module aliases already exist in the module info section. We just
don't parse the alias tags in the kernel.
So the real fix is to make find_module_all() just do that.
Doing random ad-hoc "let's prefix with 'fs-xyz'" games are completely
unacceptable. That's just pure shit. Stop this idiocy.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] sphinxification for dma-buf docs
On Fri, 9 Dec 2016 19:53:04 +0100 Daniel Vetter wrote: > Not yet everything in this area, I still want to sprinkle nice docs around all > the fence code. Especially some text to explain implicit vs. explicit fencing > and how it's all supposed to work. > > But just cleanup in the dma-buf part was quite a bit of work, and I'd like to > get feedback on that before moving on. No complaints here - except that I had to go looking around to find this 0/5 posting explaining what the overall goal was...:) It seems like just the sort of thing we want to be doing to pull the docs together in a more rational way. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dma-buf: Final bits of doc polish
- Put all the remaing bits of the old doc into suitable places in the new sphinx world. - Also document the poll support, we forgot to do that. - Delete dma-buf-sharing.txt. v2: Don't forget to update MAINTAINERS. Cc: linux-doc@vger.kernel.org Cc: Jonathan Corbet Cc: Sumit Semwal Signed-off-by: Daniel Vetter --- Documentation/dma-buf-sharing.txt| 47 --- Documentation/driver-api/dma-buf.rst | 48 MAINTAINERS | 2 +- drivers/dma-buf/dma-buf.c| 22 + 4 files changed, 71 insertions(+), 48 deletions(-) delete mode 100644 Documentation/dma-buf-sharing.txt diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt deleted file mode 100644 index 74c99edb7976.. --- a/Documentation/dma-buf-sharing.txt +++ /dev/null @@ -1,47 +0,0 @@ -DMA Buffer Sharing API Guide - - -Sumit Semwal - - - - -Other Interfaces Exposed to Userspace on the dma-buf FD --- - -- Since kernel 3.12 the dma-buf FD supports the llseek system call, but only - with offset=0 and whence=SEEK_END|SEEK_SET. SEEK_SET is supported to allow - the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other - llseek operation will report -EINVAL. - - If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all - cases. Userspace can use this to detect support for discovering the dma-buf - size using llseek. - -Miscellaneous notes - -- Any exporters or users of the dma-buf buffer sharing framework must have - a 'select DMA_SHARED_BUFFER' in their respective Kconfigs. - -- In order to avoid fd leaks on exec, the FD_CLOEXEC flag must be set - on the file descriptor. This is not just a resource leak, but a - potential security hole. It could give the newly exec'd application - access to buffers, via the leaked fd, to which it should otherwise - not be permitted access. - - The problem with doing this via a separate fcntl() call, versus doing it - atomically when the fd is created, is that this is inherently racy in a - multi-threaded app[3]. The issue is made worse when it is library code - opening/creating the file descriptor, as the application may not even be - aware of the fd's. - - To avoid this problem, userspace must have a way to request O_CLOEXEC - flag be set when the dma-buf fd is created. So any API provided by - the exporting driver to create a dmabuf fd must provide a way to let - userspace control setting of O_CLOEXEC flag passed in to dma_buf_fd(). - -References: -[1] struct dma_buf_ops in include/linux/dma-buf.h -[2] All interfaces mentioned above defined in include/linux/dma-buf.h -[3] https://lwn.net/Articles/236486/ diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 92e417035e16..31671b469627 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -46,6 +46,48 @@ The buffer-user same area of memory. This interface is provided by :c:type:`struct dma_buf_attachment `. +Any exporters or users of the dma-buf buffer sharing framework must have a +'select DMA_SHARED_BUFFER' in their respective Kconfigs. + +Userspace Interface Notes +~ + +Mostly a DMA buffer file descriptor is simply an opaque object for userspace, +and hence the generic interface exposed is very minimal. There's a few things to +consider though: + +- Since kernel 3.12 the dma-buf FD supports the llseek system call, but only + with offset=0 and whence=SEEK_END|SEEK_SET. SEEK_SET is supported to allow + the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other + llseek operation will report -EINVAL. + + If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all + cases. Userspace can use this to detect support for discovering the dma-buf + size using llseek. + +- In order to avoid fd leaks on exec, the FD_CLOEXEC flag must be set + on the file descriptor. This is not just a resource leak, but a + potential security hole. It could give the newly exec'd application + access to buffers, via the leaked fd, to which it should otherwise + not be permitted access. + + The problem with doing this via a separate fcntl() call, versus doing it + atomically when the fd is created, is that this is inherently racy in a + multi-threaded app[3]. The issue is made worse when it is library code + opening/creating the file descriptor, as the application may not even be + aware of the fd's. + + To avoid this problem, userspace must have a way to request O_CLOEXEC + flag be set when the dma-buf fd is created. So any API provided by + the exporting driver to create a dmabuf fd must provide a way to let +
[PATCH] Add +~800M crashkernel explaination
When trying to configure crashkernel greater than about 800 MB, the kernel fails to allocate memory on x86 and x86_64. This is due to an undocumented limit that the crashkernel and other low memory items must be allocated below 896 MB unless the ",high" option is given. This updates the documentation to explain this and what I understand the limitations to be on the option. Signed-off-by: Robert LeBlanc --- Documentation/kdump/kdump.txt | 22 +- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt index b0eb27b..aa3efa8 100644 --- a/Documentation/kdump/kdump.txt +++ b/Documentation/kdump/kdump.txt @@ -256,7 +256,9 @@ While the "crashkernel=size[@offset]" syntax is sufficient for most configurations, sometimes it's handy to have the reserved memory dependent on the value of System RAM -- that's mostly for distributors that pre-setup the kernel command line to avoid a unbootable system after some memory has -been removed from the machine. +been removed from the machine. If you need to allocate more than ~800M +for x86 or x86_64 then you must use the simple format as the format +',high' conflicts with the separators of ranges. The syntax is: @@ -282,11 +284,21 @@ Boot into System Kernel 1) Update the boot loader (such as grub, yaboot, or lilo) configuration files as necessary. -2) Boot the system kernel with the boot parameter "crashkernel=Y@X", +2) Boot the system kernel with the boot parameter "crashkernel=Y[@X | ,high]", where Y specifies how much memory to reserve for the dump-capture kernel - and X specifies the beginning of this reserved memory. For example, - "crashkernel=64M@16M" tells the system kernel to reserve 64 MB of memory - starting at physical address 0x0100 (16MB) for the dump-capture kernel. + and X specifies the beginning of this reserved memory or ',high' to load in + high memory. For example, "crashkernel=64M@16M" tells the system + kernel to reserve 64 MB of memory starting at physical address + 0x0100 (16MB) for the dump-capture kernel. + + Specifying "crashkernel=1G,high" tells the system kernel to reserve 1 GB + of memory using high memory for the dump-capture kernel, there may also + be some low memory allocated as well. If you need more than ~800M for + the crash kernel to operate (volumes on FC/iSCSI, large volumes, systemd + added to the previous, etc), you need to specify ',high' since without + it crashkerenel has to try and fit under 896M along with some other + items and will fail to allocate memory. High memory may only be relevant + on x86 and x86_64. On x86 and x86_64, use "crashkernel=64M@16M". -- 2.10.2 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add +~800M crashkernel explaination
On 12/09/16 at 05:22pm, Robert LeBlanc wrote: > When trying to configure crashkernel greater than about 800 MB, the > kernel fails to allocate memory on x86 and x86_64. This is due to an > undocumented limit that the crashkernel and other low memory items must > be allocated below 896 MB unless the ",high" option is given. This > updates the documentation to explain this and what I understand the > limitations to be on the option. This is true, but not very accurate. You found it's about 800M, it's becasue usually the current kernel need about 40M space to run, and some extra reservation before reserve_crashkernel invocation, another ~10M. However it's normal case, people may build modules into or have some special code to bloat kernel. This patch makes sense to address the low|high issue, it might be not good so determined to say ~800M. > > Signed-off-by: Robert LeBlanc > --- > Documentation/kdump/kdump.txt | 22 +- > 1 file changed, 17 insertions(+), 5 deletions(-) > > diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt > index b0eb27b..aa3efa8 100644 > --- a/Documentation/kdump/kdump.txt > +++ b/Documentation/kdump/kdump.txt > @@ -256,7 +256,9 @@ While the "crashkernel=size[@offset]" syntax is > sufficient for most > configurations, sometimes it's handy to have the reserved memory dependent > on the value of System RAM -- that's mostly for distributors that pre-setup > the kernel command line to avoid a unbootable system after some memory has > -been removed from the machine. > +been removed from the machine. If you need to allocate more than ~800M > +for x86 or x86_64 then you must use the simple format as the format > +',high' conflicts with the separators of ranges. > > The syntax is: > > @@ -282,11 +284,21 @@ Boot into System Kernel > 1) Update the boot loader (such as grub, yaboot, or lilo) configuration > files as necessary. > > -2) Boot the system kernel with the boot parameter "crashkernel=Y@X", > +2) Boot the system kernel with the boot parameter "crashkernel=Y[@X | > ,high]", > where Y specifies how much memory to reserve for the dump-capture kernel > - and X specifies the beginning of this reserved memory. For example, > - "crashkernel=64M@16M" tells the system kernel to reserve 64 MB of memory > - starting at physical address 0x0100 (16MB) for the dump-capture > kernel. > + and X specifies the beginning of this reserved memory or ',high' to load > in > + high memory. For example, "crashkernel=64M@16M" tells the system > + kernel to reserve 64 MB of memory starting at physical address > + 0x0100 (16MB) for the dump-capture kernel. > + > + Specifying "crashkernel=1G,high" tells the system kernel to reserve 1 GB > + of memory using high memory for the dump-capture kernel, there may also > + be some low memory allocated as well. If you need more than ~800M for > + the crash kernel to operate (volumes on FC/iSCSI, large volumes, systemd > + added to the previous, etc), you need to specify ',high' since without > + it crashkerenel has to try and fit under 896M along with some other > + items and will fail to allocate memory. High memory may only be relevant > + on x86 and x86_64. > > On x86 and x86_64, use "crashkernel=64M@16M". > > -- > 2.10.2 > > > ___ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add +~800M crashkernel explaination
On Fri, Dec 9, 2016 at 7:49 PM, Baoquan He wrote: > On 12/09/16 at 05:22pm, Robert LeBlanc wrote: >> When trying to configure crashkernel greater than about 800 MB, the >> kernel fails to allocate memory on x86 and x86_64. This is due to an >> undocumented limit that the crashkernel and other low memory items must >> be allocated below 896 MB unless the ",high" option is given. This >> updates the documentation to explain this and what I understand the >> limitations to be on the option. > > This is true, but not very accurate. You found it's about 800M, it's > becasue usually the current kernel need about 40M space to run, and some > extra reservation before reserve_crashkernel invocation, another ~10M. > However it's normal case, people may build modules into or have some > special code to bloat kernel. This patch makes sense to address the > low|high issue, it might be not good so determined to say ~800M. My testing showed that I could go anywhere from about 830M to 880M, depending on distro, kernel version, and stuff that you mentioned. I just thought some rule of thumb of when to consider using high would be good. People may not think that 800 MB is 'large' when you have 512 GB of RAM for instance. I thought about making 512 MB be the rule of thumb, but you can do a lot with ~300 MB. I'm happy to adjust the wording, what would you recommend? Also, I'm not 100% sure that I got the cases covered correctly. I was surprised that I could not get it to work with the "new" format with the multiple ranges, and that specifying an offset would't work either, although the offset kind of makes sense. Do you know for sure that it doesn't work with ranges? I tried, crashkernel=256M-1G:128M,high,1G-4G:256M,high,4G-:512M,high and crashkernel=256M-1G:128M,1G-4G:256M,4G-:512M,high and neither worked. It seems that a better separator would be ';' instead of ',' for ranges, then you could specify options better. Kind of hard to change now. > >> >> Signed-off-by: Robert LeBlanc >> --- >> Documentation/kdump/kdump.txt | 22 +- >> 1 file changed, 17 insertions(+), 5 deletions(-) >> >> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt >> index b0eb27b..aa3efa8 100644 >> --- a/Documentation/kdump/kdump.txt >> +++ b/Documentation/kdump/kdump.txt >> @@ -256,7 +256,9 @@ While the "crashkernel=size[@offset]" syntax is >> sufficient for most >> configurations, sometimes it's handy to have the reserved memory dependent >> on the value of System RAM -- that's mostly for distributors that pre-setup >> the kernel command line to avoid a unbootable system after some memory has >> -been removed from the machine. >> +been removed from the machine. If you need to allocate more than ~800M >> +for x86 or x86_64 then you must use the simple format as the format >> +',high' conflicts with the separators of ranges. >> >> The syntax is: >> >> @@ -282,11 +284,21 @@ Boot into System Kernel >> 1) Update the boot loader (such as grub, yaboot, or lilo) configuration >> files as necessary. >> >> -2) Boot the system kernel with the boot parameter "crashkernel=Y@X", >> +2) Boot the system kernel with the boot parameter "crashkernel=Y[@X | >> ,high]", >> where Y specifies how much memory to reserve for the dump-capture kernel >> - and X specifies the beginning of this reserved memory. For example, >> - "crashkernel=64M@16M" tells the system kernel to reserve 64 MB of memory >> - starting at physical address 0x0100 (16MB) for the dump-capture >> kernel. >> + and X specifies the beginning of this reserved memory or ',high' to load >> in >> + high memory. For example, "crashkernel=64M@16M" tells the system >> + kernel to reserve 64 MB of memory starting at physical address >> + 0x0100 (16MB) for the dump-capture kernel. >> + >> + Specifying "crashkernel=1G,high" tells the system kernel to reserve 1 GB >> + of memory using high memory for the dump-capture kernel, there may also >> + be some low memory allocated as well. If you need more than ~800M for >> + the crash kernel to operate (volumes on FC/iSCSI, large volumes, systemd >> + added to the previous, etc), you need to specify ',high' since without >> + it crashkerenel has to try and fit under 896M along with some other >> + items and will fail to allocate memory. High memory may only be relevant >> + on x86 and x86_64. >> >> On x86 and x86_64, use "crashkernel=64M@16M". >> >> -- >> 2.10.2 >> >> >> ___ >> kexec mailing list >> ke...@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/kexec Robert LeBlanc PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
