On Mon, Mar 3, 2014 at 5:40 PM, Liu ShuoX <shuox....@intel.com> wrote: > On Mon 3.Mar'14 at 11:45:59 -0800, Kees Cook wrote: >> >> On Thu, Feb 27, 2014 at 10:37 PM, <shuox....@intel.com> wrote: >>> >>> From: Liu ShuoX <shuox....@intel.com> >>> >>> ftrace_read_cnt need to be reset in open to support mutli times >>> getting the records. >>> >>> Signed-off-by: Liu ShuoX <shuox....@intel.com> >>> --- >>> fs/pstore/ram.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c >>> index fa8cef2..a5d0cab 100644 >>> --- a/fs/pstore/ram.c >>> +++ b/fs/pstore/ram.c >>> @@ -101,6 +101,7 @@ static int ramoops_pstore_open(struct pstore_info >>> *psi) >>> >>> cxt->dump_read_cnt = 0; >>> cxt->console_read_cnt = 0; >>> + cxt->ftrace_read_cnt = 0; >>> return 0; >>> } >> >> >> I think we need a separate function for "clear" for the >> ramoops_context struct. IIUC, we're missing a similar initialization >> in ramoops_probe, which lacks both console_read_cnt=0 and >> ftrace_read_cnt=0. Then both places could call this? > > Hi Kees, > Currently, we have only one static ramoops_context named oops_cxt. > *_read_cnt should be initialized to 0 as default. Need we still add > such function for 'clear'?
We have the pstore-global "oops_cxt" context. It is "initialized" only once in ramoops_probe (and seems to needlessly set dump_read_cnt to 0). Otherwise, the context is initialized via ramoops_register_dummy from module parameters (and initialized to zero with kzalloc). So, I think my initial comment about "clear" is probably not right, but that ramoops_pstore_open should be doing that (i.e. your original patch is close). However, I think I'd like to see the needless zeroing in ramoops_probe removed, and the "variables that need clearing on open" documented in comments in "struct ramoops_context". That should make this code more clear to read next time. :) Thanks! -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
