'mem=" option is an easy way to put high pressure on memory during some
test. Hence in stead of total mem, the effective usable memory size should
be considered when reserving mem for crashkernel. Otherwise the boot up may
experience oom issue.
E.g passing
On 2019-09-07, Jeff Layton wrote:
> On Thu, 2019-09-05 at 06:19 +1000, Aleksa Sarai wrote:
> > + * @flags: O_* flags.
> > + * @mode: O_CREAT/O_TMPFILE file mode.
> > + * @upgrade_mask: UPGRADE_* flags (to restrict O_PATH re-opening).
> > + * @resolve: RESOLVE_* flags.
> > + */
> > +struct
https://bugzilla.kernel.org/show_bug.cgi?id=204125
Daniel Kolesa (li...@octaforge.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
Nicholas Piggin's on August 28, 2019 7:06 pm:
> This is a work in progress that goes on top of the syscalls in C patch.
> It's not quite complete, 64e low level exit is not taken care of, and
> the new return is hacked into the existing interrupt handlers pretty
> quickly (e.g., full gprs handling
Naveen N. Rao's on September 6, 2019 4:20 am:
> Enable HAVE_FUNCTION_GRAPH_RET_ADDR_PTR for more robust stack unwinding
> when function graph tracer is in use. Convert powerpc show_stack() to
> use ftrace_graph_ret_addr() for better stack unwinding.
This series improved my case of a WARN_ON
* Qian Cai wrote:
> I thought about making it a bool in the first place, but since all
> other similar helpers (arch_is_kernel_initmem_freed(),
> arch_is_kernel_text(), arch_is_kernel_data() etc) could be bool too but
> are not, I kept arch_is_bss_hole() just to be “int” for consistent.
>
