On Fri, May 24, 2013 at 11:18:56AM -0400, Vivek Goyal wrote:
> On Fri, May 24, 2013 at 01:29:41PM +0200, Michael Holzheu wrote:
> > Currently for s390 we create the ELF core header in the 2nd kernel
> > with a small trick. We relocate the addresses in the ELF header in
> > a w
On Fri, May 24, 2013 at 01:29:42PM +0200, Michael Holzheu wrote:
> This patch now exchanges the old relocate mechanism with the new
> arch function call override mechanism that allows to create the ELF
> core header in the 2nd kernel.
>
> Signed-off-by: Michael Holzheu
> ---
> arch/s390/kernel/c
On Wed, May 29, 2013 at 07:12:49PM +0200, Michael Holzheu wrote:
[..]
> > > > So are you saying that s390 is ready to switch to mechanism of
> > > > creating ELF headers in first kernel by kexec-tools and new kernel
> > > > does not have to preare ELF headers?
> > >
> > > No, I meant that current
On Wed, May 29, 2013 at 01:51:44PM +0200, Michael Holzheu wrote:
[..]
> >>> START QUOTE
>
> [PATCH v3 1/3] kdump: Introduce ELF header in new memory feature
>
> Currently for s390 we create the ELF core header in the 2nd kernel with
> a small trick. We relocate the addresses in the ELF header in
On Fri, May 31, 2013 at 04:21:27PM +0200, Michael Holzheu wrote:
> On Thu, 30 May 2013 16:38:47 -0400
> Vivek Goyal wrote:
>
> > On Wed, May 29, 2013 at 01:51:44PM +0200, Michael Holzheu wrote:
> >
> > [..]
> > > >>> START QUOTE
> > >
&
On Mon, Jun 03, 2013 at 03:27:18PM +0200, Michael Holzheu wrote:
[..]
> > If not, how would remap_pfn_range() work with HSA region when
> > /proc/vmcore is mmaped()?
>
> I am no memory management expert, so I discussed that with Martin
> Schwidefsky (s390 architecture maintainer). Perhaps somethi
On Fri, Jun 07, 2013 at 11:09:54AM +0800, sanbai wrote:
> On 2013年06月05日 21:30, Vivek Goyal wrote:
> >On Wed, Jun 05, 2013 at 10:09:31AM +0800, Robin Dong wrote:
> >>We want to use blkio.cgroup on high-speed device (like fusionio) for our
> >>mysql clusters.
>
On Fri, Jun 28, 2013 at 10:15:52AM +0200, Michael Holzheu wrote:
> On Thu, 27 Jun 2013 16:23:34 -0400
> Vivek Goyal wrote:
>
> > On Thu, Jun 27, 2013 at 03:32:02PM -0400, Vivek Goyal wrote:
> > > On Fri, Jun 21, 2013 at 04:17:03PM +0200, Michael Holzheu wrote:
> >
eader
> * elfcorehdr_read: Read from ELF header
> * elfcorehdr_read_notes: Read from ELF notes
>
> Signed-off-by: Michael Holzheu
Looks good to me.
Acked-by: Vivek Goyal
Vivek
> ---
> fs/proc/vmcore.c | 61
> ++
> includ
cache and using page uptodate
flag.
Hatayama, can you please review it.
Acked-by: Vivek Goyal
Thanks
Vivek
> ---
> fs/proc/vmcore.c | 84
> +-
> include/linux/crash_dump.h | 3 ++
> 2 files changed, 79 insertions(+), 8 delet
On Mon, Jul 01, 2013 at 09:32:36PM +0200, Michael Holzheu wrote:
[..]
> +ssize_t elfcorehdr_read(char *buf, size_t count, u64 *ppos)
> +{
> + void *src = (void *)(unsigned long)*ppos;
> +
> + src = elfcorehdr_newmem ? src : src - OLDMEM_BASE;
Seriously, we need to get rid of all this OLDM
On Wed, Jul 03, 2013 at 09:59:13AM +0200, Michael Holzheu wrote:
> On Tue, 2 Jul 2013 12:23:23 -0400
> Vivek Goyal wrote:
>
> > On Mon, Jul 01, 2013 at 09:32:36PM +0200, Michael Holzheu wrote:
> >
> > [..]
> > > +ssize_t elfcorehdr_read(char *buf, size_t cou
On Wed, Jul 03, 2013 at 03:59:33PM +0200, Michael Holzheu wrote:
> On Tue, 2 Jul 2013 11:42:14 -0400
> Vivek Goyal wrote:
>
> > On Mon, Jul 01, 2013 at 09:32:37PM +0200, Michael Holzheu wrote:
>
> [snip]
>
> > > This handler works as follows:
> > >
On Wed, Jul 03, 2013 at 04:39:44PM +0200, Michael Holzheu wrote:
> On Wed, 3 Jul 2013 10:15:29 -0400
> Vivek Goyal wrote:
>
> > On Wed, Jul 03, 2013 at 09:59:13AM +0200, Michael Holzheu wrote:
> > > On Tue, 2 Jul 2013 12:23:23 -0400
> > > Vivek Goyal wrote:
&g
On Fri, Jun 21, 2013 at 04:17:03PM +0200, Michael Holzheu wrote:
> On Fri, 14 Jun 2013 14:54:02 -0400
> Vivek Goyal wrote:
>
> > On Fri, Jun 07, 2013 at 06:55:57PM +0200, Michael Holzheu wrote:
> >
> > [..]
> > > @@ -935,10 +967,17 @@ static int __init vmcor
On Thu, Jun 27, 2013 at 03:32:02PM -0400, Vivek Goyal wrote:
> On Fri, Jun 21, 2013 at 04:17:03PM +0200, Michael Holzheu wrote:
> > On Fri, 14 Jun 2013 14:54:02 -0400
> > Vivek Goyal wrote:
> >
> > > On Fri, Jun 07, 2013 at 06:55:57P
On Fri, Jun 28, 2013 at 05:05:13PM +0200, Michal Hocko wrote:
> On Thu 27-06-13 22:01:38, Tejun Heo wrote:
> > Hello, Mike.
> >
> > On Fri, Jun 28, 2013 at 06:49:10AM +0200, Mike Galbraith wrote:
> > > I always thought that was a very cool feature, mkdir+echo, poof done.
> > > Now maybe that inter
On Thu, Mar 21, 2013 at 11:19:52AM -0500, Serge E. Hallyn wrote:
[..]
> > I am hoping I did not miss your point entirely.
>
> No, you didn't. If replay attacks are not a concern then that bit
> doesn't matter. But if^Wwhen there is a vulnerability in a signed kernel,
> and a user has a copy of
On Wed, Mar 20, 2013 at 09:57:57AM +0200, Kasatkin, Dmitry wrote:
> On Fri, Mar 15, 2013 at 5:41 PM, Vivek Goyal wrote:
> > On Thu, Mar 14, 2013 at 11:08:45PM +0200, Kasatkin, Dmitry wrote:
> >> On Thu, Mar 14, 2013 at 10:37 PM, Vivek Goyal wrote:
> >> > On Thu, Ma
On Wed, Mar 20, 2013 at 12:22:09PM -0700, Yinghai Lu wrote:
> We can extend kexec-tools to support multiple "Crash kernel" in /proc/iomem
> instead.
>
> So we can use "Crash kernel" instead of "Crash kernel low" in /proc/iomem.
>
> Suggested-b
On Mon, Mar 25, 2013 at 02:50:18PM -0700, Yinghai Lu wrote:
> On Mon, Mar 25, 2013 at 12:42 PM, Vivek Goyal wrote:
> > So it is a forgone conclusion that these new kernel changes to
> > crashkernel=X in 3.9 are incompatible with older kexec-tools and one
> > needs to upgrad
On Fri, Jul 12, 2013 at 08:05:31PM +0900, HATAYAMA Daisuke wrote:
[..]
> How about
>
> static int mmap_vmcore_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
> {
> ...
> char *buf;
> int rc;
>
> #ifndef CONFIG_S390
> return VM_FAULT_SIGBUS;
> #endif
> page
On Mon, Jul 15, 2013 at 03:44:51PM +0200, Michael Holzheu wrote:
> On Tue, 2 Jul 2013 11:42:14 -0400
> Vivek Goyal wrote:
>
> > On Mon, Jul 01, 2013 at 09:32:37PM +0200, Michael Holzheu wrote:
> > > For zfcpdump we can't map the HSA storage because it is only availab
On Sun, Jun 30, 2013 at 08:38:38PM +0200, Michal Hocko wrote:
> On Fri 28-06-13 14:01:55, Vivek Goyal wrote:
> > On Fri, Jun 28, 2013 at 05:05:13PM +0200, Michal Hocko wrote:
> [...]
> > > OK, so libcgroup's rules daemon will still work and place my tasks in
> > &g
On Tue, Jul 16, 2013 at 11:25:27AM +0200, Michael Holzheu wrote:
[..]
> > > Hello Vivek and Andrew,
> > >
> > > We just realized that Hatayama's mmap patches went into v3.11-rc1. This
> > > currently
> > > breaks s390 kdump because of the following two issues:
> > >
> > > 1) The copy_oldmem_pag
On Tue, Jul 16, 2013 at 05:37:09PM +0200, Michael Holzheu wrote:
[..]
> The problem is that with the mmap patches we now use copy_oldmem_page()
> to copy the notes from oldmem into the notes_buf which has been allocated
> with vmalloc. The s390 version of copy_oldmem_page() bypasses the page
> tab
On Tue, Jul 16, 2013 at 06:18:10PM +0200, Michael Holzheu wrote:
> Hello Andrew,
>
> Here a new kdump patch series that we have discussed with Vivek and
> Hatayama during the last months.
>
> Besides of the feature described below, this patch series also fixes a
> regression on s390 that was intr
On Wed, Jul 17, 2013 at 06:00:49PM +0200, Michael Holzheu wrote:
> > On Tue, Jul 16, 2013 at 06:18:10PM +0200, Michael Holzheu wrote:
> > > Hello Andrew,
> > >
> > > Here a new kdump patch series that we have discussed with Vivek and
> > > Hatayama during the last months.
> > >
> > > Besides of the
On Thu, Jul 25, 2013 at 11:00:46AM -0600, Bjorn Helgaas wrote:
> On Wed, Jul 24, 2013 at 12:29 AM, Takao Indoh
> wrote:
> > Sorry for letting this discussion slide, I was busy on other works:-(
> > Anyway, the summary of previous discussion is:
> > - My patch adds new initcall(fs_initcall) to rese
On Tue, Jul 30, 2013 at 09:59:16AM -0600, Bjorn Helgaas wrote:
> On Tue, Jul 30, 2013 at 12:09 AM, Takao Indoh
> wrote:
> > (2013/07/29 23:17), Bjorn Helgaas wrote:
> >> On Sun, Jul 28, 2013 at 6:37 PM, Takao Indoh
> >> wrote:
> >>> (2013/07/26 2:00), Bjorn Helgaas wrote:
>
> My point abou
On Thu, Aug 01, 2013 at 03:34:06PM +0900, Takao Indoh wrote:
> (2013/08/01 6:23), Rafael J. Wysocki wrote:
> > On Wednesday, July 31, 2013 03:08:03 PM Bjorn Helgaas wrote:
> >> [+cc Rafael, linux-acpi]
> >>
> >> On Tue, Jul 30, 2013 at 6:35 PM, Takao Indoh
> >> wrote:
> >>
> >>> On x86, currently
nel/cgroup.c::offline_css(), unnecessary open coded css
> dereference is replaced with local variable access.
>
> This patch shouldn't cause any behavior differences.
>
> Signed-off-by: Tejun Heo
> Cc: Li Zefan
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Johannes Wei
t; subsystem for other cftype handling functions. @ss argument dropped
> from various cftype handling functions.
>
> This patch shouldn't introduce any behavior differences.
>
> Signed-off-by: Tejun Heo
> Cc: Vivek Goyal
> Cc: Jens Axboe
> ---
> block/blk-cgroup.c
. Removed.
>
> * devices: cgroup_to_devcgroup() is no longer used. Removed.
>
> Signed-off-by: Tejun Heo
> Cc: Li Zefan
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Balbir Singh
> Cc: Aristeu Rozanski
> Cc: Matt Helsley
> Cc: Vivek Goyal
> Cc: Jens Axboe
c: Ingo Molnar
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Balbir Singh
> Cc: Aristeu Rozanski
> Cc: Matt Helsley
> Cc: Daniel Wagner
> Cc: Vivek Goyal
> Cc: Jens Axboe
> Cc: Steven Rostedt
> ---
> block/blk-cgroup.c | 6 +-
> block/blk-throttle
; had explicit origin handling before or after, it's moved inside the
> iteration. If not, if (pos == origin) continue; is added. Some
> conversions add extra reference get/put around origin handling by
> consolidating origin handling and the rest. While the extra ref
> operations
On Thu, Jul 18, 2013 at 12:40:04PM +0200, Michael Holzheu wrote:
> On Wed, 17 Jul 2013 17:42:07 -0400
> Vivek Goyal wrote:
> > On Wed, Jul 17, 2013 at 06:00:49PM +0200, Michael Holzheu wrote:
>
> [snip]
>
> > > But this is all additional effort now an
On Thu, Jul 18, 2013 at 12:47:54PM +0200, Martin Schwidefsky wrote:
> On Thu, 18 Jul 2013 12:40:04 +0200
> Michael Holzheu wrote:
>
> > On Wed, 17 Jul 2013 17:42:07 -0400
> > Vivek Goyal wrote:
> > > On Wed, Jul 17, 2013 at 06:00:49PM +0200, Michael
On Thu, Jul 18, 2013 at 04:31:21PM +0200, Michael Holzheu wrote:
[..]
> > Hi Michael,
> >
> > Once this patch series gets merged for 3.12, can we first do some cleanup
> > of s390 code before we do further development there. Basically there is
> > no reason that s390 kdump should be any different
On Fri, Jul 19, 2013 at 08:50:20AM +0200, Martin Schwidefsky wrote:
> On Thu, 18 Jul 2013 09:35:41 -0400
> Vivek Goyal wrote:
>
> > On Thu, Jul 18, 2013 at 12:47:54PM +0200, Martin Schwidefsky wrote:
> > > On Thu, 18 Jul 2013 12:40:04 +0200
> > > Michael Holzheu
On Wed, Jul 24, 2013 at 03:29:58PM +0900, Takao Indoh wrote:
> Sorry for letting this discussion slide, I was busy on other works:-(
> Anyway, the summary of previous discussion is:
> - My patch adds new initcall(fs_initcall) to reset all PCIe endpoints on
> boot. This expects PCI enumeration is
On Fri, Jul 26, 2013 at 07:42:39PM +0800, Jingbai Ma wrote:
> Hi,
>
> I have run some tests with makedumpfile 1.5.4 and upstream kernel
> 3.11-rc2+ on a machine with 4TB memory, here is testing results:
>
> Test environment:
> Machine: HP ProLiant DL980 G7 with 4TB RAM.
> CPU: Intel(R) Xeon(R) CP
On Fri, Aug 09, 2013 at 03:36:37AM -0400, Matthew Garrett wrote:
> kexec permits the loading and execution of arbitrary code in ring 0, which
> is something that module signing enforcement is meant to prevent. It makes
> sense to disable kexec in this situation.
>
But in the process we wipe out r
On Fri, Aug 09, 2013 at 03:07:13PM +, Matthew Garrett wrote:
> On Fri, 2013-08-09 at 07:02 -0400, Vivek Goyal wrote:
> > On Fri, Aug 09, 2013 at 03:36:37AM -0400, Matthew Garrett wrote:
> > > kexec permits the loading and execution of arbitrary code in ring 0, which
>
On Fri, Aug 09, 2013 at 03:07:13PM +, Matthew Garrett wrote:
> On Fri, 2013-08-09 at 07:02 -0400, Vivek Goyal wrote:
> > On Fri, Aug 09, 2013 at 03:36:37AM -0400, Matthew Garrett wrote:
> > > kexec permits the loading and execution of arbitrary code in ring 0, which
>
On Fri, Aug 09, 2013 at 03:07:13PM +, Matthew Garrett wrote:
> On Fri, 2013-08-09 at 07:02 -0400, Vivek Goyal wrote:
> > On Fri, Aug 09, 2013 at 03:36:37AM -0400, Matthew Garrett wrote:
> > > kexec permits the loading and execution of arbitrary code in ring 0, which
>
On Fri, Mar 01, 2013 at 07:15:07AM -0500, Mimi Zohar wrote:
> On Thu, 2013-02-28 at 20:49 -0500, Mimi Zohar wrote:
> > On Thu, 2013-02-28 at 17:20 -0500, Eric Paris wrote:
>
> > > The ima_tcb policy was meant to be larger than needed to determine a
> > > trusted computing base, but it is clearly n
On Fri, Mar 01, 2013 at 10:28:40AM -0500, Vivek Goyal wrote:
> On Fri, Mar 01, 2013 at 07:15:07AM -0500, Mimi Zohar wrote:
> > On Thu, 2013-02-28 at 20:49 -0500, Mimi Zohar wrote:
> > > On Thu, 2013-02-28 at 17:20 -0500, Eric Paris wrote:
> >
> > > > The ima_tc
On Fri, Mar 01, 2013 at 02:39:13PM -0500, Mimi Zohar wrote:
[..]
> I was suggesting that a builtin appraise rule chain and everything else
> on the other chain. Userspace could replace the other chain with
> whatever they wanted, including additional appraisal rules.
>
> > > Given the fact that
On Sun, Mar 03, 2013 at 04:42:24PM -0500, Mimi Zohar wrote:
[..]
> > > We've already spoken about needing an additional hook or moving the
> > > existing bprm hook. Can we defer the memory caching requirements for
> > > now?
> >
> > Sure, additional hook is not a concern.
> >
> > I can defer cac
On Mon, Mar 04, 2013 at 08:48:36AM -0500, Mimi Zohar wrote:
> On Thu, 2013-02-14 at 14:55 -0500, Vivek Goyal wrote:
> > Digital signature verification happens using integrity_digsig_verify().
> > Curently we set integrity to FAIL for all error codes except -EOPNOTSUPP.
> > Th
On Mon, Mar 04, 2013 at 10:29:19AM -0500, Vivek Goyal wrote:
[..]
> This reduces our options but trying to make multiple policies co-exist
> together is just making it complicated. We can take it up again when
> somebody has a strong use case of using secureboot policy along with
> ot
On Mon, Mar 04, 2013 at 01:59:41PM -0500, Mimi Zohar wrote:
> On Mon, 2013-03-04 at 10:29 -0500, Vivek Goyal wrote:
> [...]
>
> > Hi Mimi,
> >
> > If we decide to merge flags, then practically we modified the
> > ima_appraise_tcb policy. ima_appraise_tcb policy
On Sun, Mar 03, 2013 at 04:42:24PM -0500, Mimi Zohar wrote:
[..]
> I was thinking more in terms of merging flags. Merging the flags in
> your example would work.
>
> appraise func=bprm_check appraise_type=optional cache_status=no
> appraise fowner=root
> example 2: merging the flags results in
On Mon, Mar 04, 2013 at 08:21:31PM -0500, Mimi Zohar wrote:
> On Mon, 2013-03-04 at 14:15 -0500, Vivek Goyal wrote:
>
> > I am just brain storming and throwing some ideas and see if soemthing
> > makes sense. I agree that allowing one policy only makes it very
> > restri
On Tue, Mar 05, 2013 at 08:30:53AM -0500, Mimi Zohar wrote:
> On Mon, 2013-03-04 at 11:20 -0500, Vivek Goyal wrote:
> > On Mon, Mar 04, 2013 at 08:48:36AM -0500, Mimi Zohar wrote:
> > > On Thu, 2013-02-14 at 14:55 -0500, Vivek Goyal wrote:
> > > > Digital signat
On Thu, Feb 14, 2013 at 02:55:44PM -0500, Vivek Goyal wrote:
> Currently ima appraises all the files as specified by the rule. So
> if one wants to create a system where only few executables are
> signed, that system will not work with IMA.
>
> With secureboot, one needs to disabl
On Tue, Mar 05, 2013 at 03:40:18PM -0500, Mimi Zohar wrote:
> On Tue, 2013-03-05 at 10:18 -0500, Vivek Goyal wrote:
>
> > Can we do following. (Just modifying your proposal little bit).
> >
> > - Implement a new policy say ima_mem_exec. This policy can vary based on
&g
that
> the offset includes the holes towards the page boundary.
>
> Signed-off-by: HATAYAMA Daisuke
Looks good to me.
Acked-by: Vivek Goyal
Vivek
> ---
>
> fs/proc/vmcore.c | 80
> ++
> 1 files changed, 45 insert
ooks good to me.
Acked-by: Vivek Goyal
Vivek
> ---
>
> fs/proc/vmcore.c | 68
> --
> 1 files changed, 20 insertions(+), 48 deletions(-)
>
> diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
> index 69e1198..48886e6 100
On Tue, May 14, 2013 at 10:57:23AM +0900, HATAYAMA Daisuke wrote:
> Currently, __find_vmap_area searches for the kernel VM area starting
> at a given address. This patch changes this behavior so that it
> searches for the kernel VM area to which the address belongs. This
> change is needed by remap
On Tue, May 14, 2013 at 10:57:29AM +0900, HATAYAMA Daisuke wrote:
> We want to allocate ELF note segment buffer on the 2nd kernel in
> vmalloc space and remap it to user-space in order to reduce the risk
> that memory allocation fails on system with huge number of CPUs and so
> with huge ELF note s
On Tue, May 14, 2013 at 10:57:35AM +0900, HATAYAMA Daisuke wrote:
> The reasons why we don't allocate ELF note segment in the 1st kernel
> (old memory) on page boundary is to keep backward compatibility for
> old kernels, and that if doing so, we waste not a little memory due to
> round-up operatio
On Tue, May 14, 2013 at 10:57:35AM +0900, HATAYAMA Daisuke wrote:
[..]
> +/* Merges all the PT_NOTE headers into one. */
> +static int __init merge_note_headers_elf32(char *elfptr, size_t *elfsz,
> +char **notesegptr, size_t *notesegsz,
> +
+---+
>| hole |
> m->offset + m->size +---+
>
> where m->offset and m->offset + m->size are always page-size aligned.
>
> Signed-off-by: HATAYAMA Daisuke
Looks good to me. I think this
, 2) seems better in
> that it reflects internal object structure of /proc/vmcore. Thus, this
> patch changes get_vmcore_size_elf{64, 32} so that it calculates size
> in the way of 2).
>
> Signed-off-by: HATAYAMA Daisuke
> ---
Looks good to me.
Ack
On Fri, Apr 05, 2013 at 06:21:59PM -0700, Tejun Heo wrote:
[..]
> Userland efforts
>
>
> There are currently a few userland efforts trying to make interfacing
> with cgroup less painful.
>
> * libcg: Make cgroup interface accessible from programming languages
> with support
On Mon, Apr 08, 2013 at 05:46:09PM +0400, Glauber Costa wrote:
[..]
> The cpu cgroup needs a real-time timeslice to accept real time tasks. It
> defaults to 0, meaning that a newly created cpu cgroup cannot accept
> tasks (rt tasks) without the user having to manually configure it.
> As far as I k
On Mon, Apr 08, 2013 at 11:16:07AM -0700, Tejun Heo wrote:
> Hey, Vivek.
>
> On Mon, Apr 08, 2013 at 01:59:26PM -0400, Vivek Goyal wrote:
> > But using the library admin application should be able to query the
> > full "paritition" hierarchy and their weigths and c
On Mon, Apr 08, 2013 at 12:20:24PM -0700, Tejun Heo wrote:
[..]
> > For example, one might want to say that maximum IO bandwidth for
> > virtual machine virt1 on disk sda should be 10MB/s. Now libvirt
> > should be able to save it in virtual machine specific configuration
> > easily and whenever
On Mon, Apr 08, 2013 at 03:43:49PM -0400, Mimi Zohar wrote:
> On Fri, 2013-04-05 at 09:50 -0400, Vivek Goyal wrote:
> > On Tue, Feb 05, 2013 at 11:55:09PM +0200, Kasatkin, Dmitry wrote:
> >
> > [..]
> > > > Also I am assuming that from signed initramfs, keys will
On Thu, Apr 04, 2013 at 03:17:01PM -0700, Yinghai Lu wrote:
[..]
> @@ -1360,37 +1369,80 @@ static int __init parse_crashkernel_simp
>
> if (*cur == '@')
> *crash_base = memparse(cur+1, &cur);
> - else if (*cur != ' ' && *cur != '\0') {
> - pr_warning("crashker
On Mon, Apr 08, 2013 at 04:17:56PM -0400, Josh Boyer wrote:
[..]
> >> > I was thinking about this point that keys can be loaded from signed
> >> > initramfs. But how is it better than embedding the keys in kernel the
> >> > way we do for module signing and lock down ima keyring before control
> >>
l look as follows?
crashkernel=suboption[,suboption[,]][@offset]
A suboption can be.
- A memory value (128[KMG])
- A range with value (range:size)
- Or a property influencing memory allocation behavior (e.g high or low)
If yes, sounds good.
Thanks
Vivek
>
> Vivek Goyal wrote:
>
On Tue, Apr 09, 2013 at 09:49:28AM -0700, H. Peter Anvin wrote:
> On 04/09/2013 09:47 AM, Vivek Goyal wrote:
> > On Tue, Apr 09, 2013 at 08:00:57AM -0700, H. Peter Anvin wrote:
> >> Please, no semicolons. We already have established syntax for suboptions
> >> (option=s
On Tue, Apr 09, 2013 at 09:49:28AM -0700, H. Peter Anvin wrote:
> On 04/09/2013 09:47 AM, Vivek Goyal wrote:
> > On Tue, Apr 09, 2013 at 08:00:57AM -0700, H. Peter Anvin wrote:
> >> Please, no semicolons. We already have established syntax for suboptions
> >> (option=s
On Tue, Apr 09, 2013 at 01:51:43PM -0400, Mikulas Patocka wrote:
> Hi
>
> I placed the dm-crypt parallization patches at:
> http://people.redhat.com/~mpatocka/patches/kernel/dm-crypt-paralelizace/current/
>
> The patches paralellize dm-crypt and make it possible to use all processor
> cores.
>
On Tue, Apr 09, 2013 at 11:10:31AM -0700, Tejun Heo wrote:
> Hey,
>
> On Tue, Apr 09, 2013 at 02:08:06PM -0400, Mikulas Patocka wrote:
> > > Hmmm? Why not just keep the issuing order along with plugging
> > > boundaries?
> >
> > What do you mean?
> >
> > I used to have a patch that keeps order o
On Tue, Apr 09, 2013 at 11:57:21AM -0700, Tejun Heo wrote:
[..]
> And destroy all per-ioc and cgroup logics in block layer in the
> process.
Oh, I am in no-way suggesting don't use bio_associate_current(). I am
just trying to analyze the performance issue right now and saying that
as far as perf
On Tue, Apr 09, 2013 at 01:24:46PM -0700, H. Peter Anvin wrote:
> On 04/09/2013 01:05 PM, Yinghai Lu wrote:
> >>
> >> So crashkernel=X@Y;high is a valid syntax? Looks like we will reserve
> >> X amount of RAM at base Y and ignore "high" or "low".
> >
> > yes, we should reject them.
> >
>
> What
On Tue, Apr 09, 2013 at 04:32:28PM -0400, Mikulas Patocka wrote:
[..]
> Generally, we shouldn't associate bios with "current" task in device
> mapper targets. For example suppose that we have two stacked dm-crypt
> targets:
>
> In the "current" process pointer in lower dm-crypt target's request
On Tue, Apr 09, 2013 at 01:01:50PM -0700, Yinghai Lu wrote:
> Per hpa, use crashkernel=X,high crashkernel=Y,low instead of
> crashkernel_hign=X crashkernel_low=Y. As that could be extensible.
>
> -v2: according to Vivek, change delimiter to ;
> -v3: let hign and low only handle simple form and it
On Tue, Apr 09, 2013 at 05:18:25PM -0400, Mikulas Patocka wrote:
[..]
> > bio_associate_current() return -EBUSY if bio has already been associated
> > with an io context.
> >
> > So in a stack if every driver calls bio_associate_current(), upon bio
> > submission, it will automatically amke sure
On Tue, Apr 09, 2013 at 11:07:10PM -0400, Mimi Zohar wrote:
[..]
> The module keyring is a special case. Loading these keys from the
> kernel and, presumably, locking the keyring is probably fine. In the
> case of IMA, however, files will be signed by any number of package
> owners. If the _ima
also not abuse parse_crashkernel_simple
>
This series looks good to me.
Acked-by: Vivek Goyal
Vivek
--
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/
On Wed, May 01, 2013 at 05:39:25PM -0700, Tejun Heo wrote:
[..]
> @@ -1023,9 +975,27 @@ static int tg_set_conf(struct cgroup *cgrp, struct
> cftype *cft, const char *buf,
> else
> *(unsigned int *)((void *)tg + cft->private) = ctx.v;
>
> - /* XXX: we don't need the follo
On Wed, May 01, 2013 at 05:39:33PM -0700, Tejun Heo wrote:
> throtl_service_queue will be the building block of hierarchy support
> and will form a tree. This patch updates its usages as arguments to
> reduce confusion.
>
> * When a service queue is used as the parent role - the host of the
> r
On Wed, May 01, 2013 at 05:39:18PM -0700, Tejun Heo wrote:
[..]
> While this patchset contains many patches, the implementation is
> pretty straight-forward. throtl_grp's form a tree anchored at
> throtl_data and bios climb the tree as they get dispatched at each
> level. The bios which reach th
On Thu, May 02, 2013 at 01:34:28PM -0400, Vivek Goyal wrote:
> On Wed, May 01, 2013 at 05:39:18PM -0700, Tejun Heo wrote:
>
> [..]
> > While this patchset contains many patches, the implementation is
> > pretty straight-forward. throtl_grp's form a tree anchored at
>
On Thu, May 02, 2013 at 10:57:01AM -0700, Tejun Heo wrote:
> Hey, Vivek.
>
> On Thu, May 02, 2013 at 01:34:28PM -0400, Vivek Goyal wrote:
> > On Wed, May 01, 2013 at 05:39:18PM -0700, Tejun Heo wrote:
> >
> > [..]
> > > While this patchset contains
On Thu, May 02, 2013 at 11:29:33AM -0700, Tejun Heo wrote:
> Hello, Vivek.
>
> On Thu, May 02, 2013 at 02:17:48PM -0400, Vivek Goyal wrote:
> > Sorry, did not understand how did you arrive at 15% penalty. I think
> > in worst case it will be 50%. Assume size of bio is 1M
On Thu, May 02, 2013 at 11:44:26AM -0700, Tejun Heo wrote:
[..]
> Also, if you're actually thinking about reimplementing blk-throttle,
> please do consider the followings.
>
> * Currently, blk-throttle doesn't throttle the number of bios being
> queued. Note that this breaks the basic back-pre
On Thu, May 02, 2013 at 11:49:53AM -0700, Tejun Heo wrote:
> Hello,
>
> On Thu, May 02, 2013 at 02:45:14PM -0400, Vivek Goyal wrote:
> > I did not understand this point. In flat model, application issuing
> > at configured page will not get penalized.
> >
> > Thi
On Thu, May 02, 2013 at 12:11:30PM -0700, Tejun Heo wrote:
> Hey,
>
>
> On Thu, May 2, 2013 at 12:07 PM, Vivek Goyal wrote:
> > It should not. Why do you think in flat model an application which
> > throttles itself will be penalized.
> >
> > So application
On Thu, May 02, 2013 at 04:13:07PM -0700, Tejun Heo wrote:
> Hello, Vivek.
>
> On Thu, May 02, 2013 at 03:31:39PM -0400, Vivek Goyal wrote:
> > I think my example was little flawed previously. I think you are right.
> > Penalty is not probably as bad as I have been thinking
On Fri, May 03, 2013 at 11:57:51AM -0700, Tejun Heo wrote:
[..]
> > # set limit to 100 bytes/second both in parent and child cgroup
> > # dd if=/dev/vdb of=/dev/null iflag=direct
> >
> > I will capture blktrace and analyze it though to understand better
> > what's happening.
>
> Try using la
On Fri, May 03, 2013 at 12:14:18PM -0700, Tejun Heo wrote:
> On Fri, May 03, 2013 at 03:08:23PM -0400, Vivek Goyal wrote:
> > T1 T2 T3 T4 T5 T6 T7
> > parent: b1 b2 b3 b4 b5
> > child:
On Fri, May 03, 2013 at 12:14:18PM -0700, Tejun Heo wrote:
> On Fri, May 03, 2013 at 03:08:23PM -0400, Vivek Goyal wrote:
> > T1 T2 T3 T4 T5 T6 T7
> > parent: b1 b2 b3 b4 b5
> > child:
On Fri, May 03, 2013 at 05:50:44PM -0700, Tejun Heo wrote:
[..]
> + * qnode_on_self is used when bios are directly queued to this
> + * throtl_grp so that local bios compete fairly with bios
> + * dispatched from children. qnode_on_parent is used when bios are
> + * dispatched
On Fri, May 03, 2013 at 04:54:55PM -0700, Tejun Heo wrote:
> Hey,
>
> On Fri, May 03, 2013 at 05:05:13PM -0400, Vivek Goyal wrote:
> > Following inline patch implements transferring child's start time to
> > parent, if parent slice had expired at the time of bio migra
301 - 400 of 2045 matches
Mail list logo
