On Thu, Mar 28, 2013 at 08:51:09AM -0700, Greg KH wrote: > On Thu, Mar 28, 2013 at 11:42:37AM -0400, Naoya Horiguchi wrote: > > Currently we fail to include any data on hugepages into coredump, > > because VM_DONTDUMP is set on hugetlbfs's vma. This behavior was recently > > introduced by commit 314e51b98 "mm: kill vma flag VM_RESERVED and > > mm->reserved_vm counter". This looks to me a serious regression, > > so let's fix it. > > > > Signed-off-by: Naoya Horiguchi <n-horiguchi@xxxxxxxxxxxxx> > > Cc: Konstantin Khlebnikov <khlebnikov@xxxxxxxxxx> > > --- > > fs/hugetlbfs/inode.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > <formletter> > > This is not the correct way to submit patches for inclusion in the > stable kernel tree. Please read Documentation/stable_kernel_rules.txt > for how to do this properly. > > </formletter> I guess you mean this patch violates one/both of these rules: - It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some "oh, that's not good" issue. In short, something critical. - It or an equivalent fix must already exist in Linus' tree (upstream). I'm not sure if the problem "we can't get any hugepage in coredump" is considered as 'some "oh, that's not good" issue'. But yes, it's not a critical one. If you mean I violated the second rule, sorry, I'll get it into upstream first. Thanks, Naoya -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html