On Wed, 23 Dec 2020 15:32:55 +0100
"Jason A. Donenfeld" wrote:
> On Wed, Dec 23, 2020 at 3:17 PM Petr Tesarik wrote:
> > Upfront, let me admit that SUSE has a vested interest in a FIPS-certifiable
> > Linux kernel.
>
> Sorry, but just because you have a &q
tree
implementation that aims at becoming upstream eventually.
The only option ATM is a fork (similar to what the Xen folks did with XenLinux
many years ago). IOW the current situation demotivates contributors from being
good citizens. I hope we can find a better solution together.
Petr Tesarik
SUSE
Hi Hari,
is there any good reason to add two more functions with a very similar
name to an existing function? AFAICS all you need is a way to call a
PPC64-specific function from within kexec_add_buffer (PATCH 4/11), so
you could add something like this:
int __weak arch_kexec_locate_mem_hole(struc
ri, 22 May 2020 20:39:22 +0200
Petr Tesarik wrote:
> After disabling a function, the original handle is logged instead of
> the disabled handle.
>
> Fixes: 17cdec960cf77 (s390/pci: Recover handle in clp_set_pci_fn())
> Signed-off-by: Petr Tesarik
> ---
> arch/s390/pci/pci_clp
After disabling a function, the original handle is logged instead of
the disabled handle.
Fixes: 17cdec960cf77 (s390/pci: Recover handle in clp_set_pci_fn())
Signed-off-by: Petr Tesarik
---
arch/s390/pci/pci_clp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/s390
On Tue, 16 Jul 2019 15:11:38 +0200
Vasily Gorbik wrote:
> On Tue, Jul 16, 2019 at 10:30:14AM +0000, Petr Tesarik wrote:
> > On Tue, 16 Jul 2019 00:12:19 +0200
> > Vasily Gorbik wrote:
> >
> > > Extend "parmarea" to include an offset of the version str
On Tue, 16 Jul 2019 00:12:19 +0200
Vasily Gorbik wrote:
> Extend "parmarea" to include an offset of the version string, which is
> stored as 8-byte big endian value.
>
> To retrieve version string from bzImage reliably, one should check the
> presence of "S390EP" ascii string at 0x10008 (availab
On Sun, 14 Jul 2019 16:35:33 +0200
Vasily Gorbik wrote:
> On Fri, Jul 12, 2019 at 07:21:01PM +0200, Petr Tesarik wrote:
> > Various tools determine the kernel version from a given binary by
> > scanning for the Linux banner string. This does not work if the
> > banner stri
Various tools determine the kernel version from a given binary by
scanning for the Linux banner string. This does not work if the
banner string is compressed, but we can link it once more into the
uncompressed portion of bzImage.
Signed-off-by: Petr Tesarik
---
arch/s390/boot/compressed
The Linux banner is self-contained, so it could be theoretically
added to separately linked binaries (e.g. the kernel decompressor).
Unfortunately, it lives in the same object file as init_uts_ns,
which needs additional symbols from other object files.
Let's divorce the two.
Signed-off-by:
These patches make it easy to determine the kernel version from a
compressed binary by scanning for the Linux banner string in the
uncompressed portion of bzImage.
Petr Tesarik (2):
init: Separate banner from init_uts_ns
s390: add Linux banner to the compressed image
arch/s390/boot
On Tue, 21 May 2019 13:39:31 +0200
Nicolas Saenz Julienne wrote:
> Hi Oliver, thanks for the review.
>
> On Mon, 2019-05-20 at 14:43 +0200, Oliver Neukum wrote:
> > On Mo, 2019-05-20 at 12:47 +0200, Nicolas Saenz Julienne wrote:
> > > + * For more information on the firmware interface check:
>
On Fri, 16 Nov 2018 13:20:33 +0100
Halil Pasic wrote:
> On Fri, 16 Nov 2018 11:47:48 +0100
> Petr Tesarik wrote:
>
> > The driver uses test_facility(), but does not include the
> > corresponding include file explicitly. The driver currently builds
> > only thanks to
includes.
Signed-off-by: Petr Tesarik
---
drivers/s390/crypto/vfio_ap_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/s390/crypto/vfio_ap_drv.c
b/drivers/s390/crypto/vfio_ap_drv.c
index 7667b38728f0..31c6c847eaca 100644
--- a/drivers/s390/crypto/vfio_ap_drv.c
+++ b/drivers/s390
On Fri, 25 May 2018 15:00:13 -0500
ebied...@xmission.com (Eric W. Biederman) wrote:
>[...]
> The ultimate point is that the absolute best we can do is to run a
> kernel in memory that we never use for anything else and then we have a
> fighting chance of getting the system working and getting a re
V Thu, 24 May 2018 11:34:05 -0500
ebied...@xmission.com (Eric W. Biederman) napsáno:
> Petr Tesarik writes:
>
> 2> On Thu, 24 May 2018 09:49:05 +0800
> > Dave Young wrote:
> >
> >> Hi Petr,
> >>
> >> On 05/23/18 at 10:22pm, Petr Tesarik w
On Thu, 24 May 2018 15:26:27 +0800
Dave Young wrote:
> On 05/24/18 at 08:57am, Petr Tesarik wrote:
>[...]
> > What is "a very minimal initrd"? Last time I had to make a significant
> > adjustment to the estimation for openSUSE, this was caused by growing
> > u
On Thu, 24 May 2018 09:49:05 +0800
Dave Young wrote:
> Hi Petr,
>
> On 05/23/18 at 10:22pm, Petr Tesarik wrote:
>[...]
> > In short, if one size fits none, what good is it to hardcode that "one
> > size" into the kernel image?
>
> I agreed with all t
On Wed, 23 May 2018 10:53:55 -0500
ebied...@xmission.com (Eric W. Biederman) wrote:
> Dave Young writes:
>
> > [snip]
> >
> >> >
> >> > +config CRASHKERNEL_DEFAULT_THRESHOLD_MB
> >> > +int "System memory size threshold for kdump memory default
> >> > reserving"
> >> > +depen
Commit-ID: 3db3eb285259ac129f7aec6b814b3e9f6c1b372b
Gitweb: https://git.kernel.org/tip/3db3eb285259ac129f7aec6b814b3e9f6c1b372b
Author: Petr Tesarik
AuthorDate: Wed, 25 Apr 2018 12:08:35 +0200
Committer: Thomas Gleixner
CommitDate: Fri, 27 Apr 2018 17:06:28 +0200
x86/setup: Do not
may also confuse users of kexec_load(2) and/or kexec_file_load(2).
When flags include KEXEC_ON_CRASH or KEXEC_FILE_ON_CRASH,
respectively, these syscalls return success, which is technically
correct, but the crash kexec image will never be actually used.
Signed-off-by: Petr Tesarik
---
arch/x86
Since commit 6326fec1122cde256bd2a8c63f2606e08e44ce1d PG_swapcache
is an alias for PG_owner_priv_1, which may be also used for other
purposes. To know whether the bit indeed has the PG_swapcache
meaning, it is necessary to check PG_swapbacked, hence this bit must
be exported.
Signed-off-by: Petr
ce at runtime that all expected bits are indeed
available.
I have also added a BUILD_BUG_ON to check that PFN_SECTION_SHIFT is
sufficient, because this part of the calculation can be easily
checked at build time.
Signed-off-by: Petr Tesarik
---
include/linux/mmzone.h | 12 ++--
mm/spa
On Wed, 24 Jan 2018 13:43:53 +0100
Michal Hocko wrote:
> On Fri 19-01-18 14:21:33, Petr Tesarik wrote:
> > On Fri, 19 Jan 2018 13:39:56 +0100
> > Michal Hocko wrote:
> >
> > > On Fri 19-01-18 08:09:08, Petr Tesarik wrote:
> > > [...]
> > >
On Fri, 19 Jan 2018 13:39:56 +0100
Michal Hocko wrote:
> On Fri 19-01-18 08:09:08, Petr Tesarik wrote:
> [...]
> > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> > index 67f2e3c38939..7522a6987595 100644
> > --- a/include/linux/mmzone.h
> >
broken, because there is a stronger alignment guarantee,
just less obvious. Let's fix the comment to make it clear how many
bits are available and why.
Signed-off-by: Petr Tesarik
---
include/linux/mmzone.h | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/include/
On Sat, 15 Apr 2017 00:26:05 +0200
Daniel Kiper wrote:
> On Fri, Apr 14, 2017 at 06:53:36PM +0200, Petr Tesarik wrote:
>[...]
> > shifted towards libkdumpfile (https://github.com/ptesarik/libkdumpfile),
> > and this library can open PV guest dump files without any issues.
&g
On Tue, 11 Apr 2017 19:20:08 +0200
Daniel Kiper wrote:
> On Tue, Apr 11, 2017 at 04:59:16PM +0200, Petr Tesarik wrote:
>[...]
> > Tested-by: Petr Tesarik
> >
> > I copied the complete /proc/vmcore to a directory on disk. Exactly
> > as expected, crash works both
> > hypervisor analysis work without any issue (at least basic commands
> > > like dmesg, bt, ps, etc.)? If yes for both you can add:
> > >
> > > Reviewed-by: Daniel Kiper
> >
> > So can I add your R-b: now?
>
> My R-b is still valid. Though, let'
On Mon, 10 Apr 2017 22:49:33 +0200
Daniel Kiper wrote:
> On Fri, Apr 07, 2017 at 11:16:22AM +0200, Petr Tesarik wrote:
> > On Wed, 5 Apr 2017 13:13:00 +0200
> > Petr Tesarik wrote:
> >
> > > On Tue, 4 Apr 2017 12:42:53 -0700 (PDT)
> > > Daniel Kiper wrot
On Wed, 5 Apr 2017 13:13:00 +0200
Petr Tesarik wrote:
> On Tue, 4 Apr 2017 12:42:53 -0700 (PDT)
> Daniel Kiper wrote:
>
>[...]
> > So, if Petr did relevant tests that is nice. However, then, IMO, this
> > patch begs Petr Tested-by.
>
> Actually, I tested wit
On Tue, 4 Apr 2017 12:42:53 -0700 (PDT)
Daniel Kiper wrote:
> > On 03/04/17 14:42, Daniel Kiper wrote:
> > > On Fri, Mar 31, 2017 at 12:14:38PM +0200, Juergen Gross wrote:
> > >> For kdump to work correctly it needs the physical address of
> > >> vmcoreinfo_note. When running as dom0 this means t
On Mon, 20 Mar 2017 13:50:31 +0800
Xunlei Pang wrote:
> As Eric said,
> "what we need to do is move the variable vmcoreinfo_note out
> of the kernel's .bss section. And modify the code to regenerate
> and keep this information in something like the control page.
>
> Definitely something like th
On Mon, 20 Mar 2017 10:17:42 +0800
Xunlei Pang wrote:
> On 03/19/2017 at 02:23 AM, Petr Tesarik wrote:
> > On Thu, 16 Mar 2017 21:40:58 +0800
> > Xunlei Pang wrote:
> >
> >> On 03/16/2017 at 09:18 PM, Baoquan He wrote:
> >>> On 03/16/17 at 08:36pm, Xun
On Thu, 16 Mar 2017 21:40:58 +0800
Xunlei Pang wrote:
> On 03/16/2017 at 09:18 PM, Baoquan He wrote:
> > On 03/16/17 at 08:36pm, Xunlei Pang wrote:
> >> On 03/16/2017 at 08:27 PM, Baoquan He wrote:
> >>> Hi Xunlei,
> >>>
> >>> Did you really see this ever happened? Because the vmcore size estimat
On Wed, 13 Jul 2016 05:52:33 -0700
Josh Triplett wrote:
> On Wed, Jul 13, 2016 at 02:19:55PM +0200, Petr Tesarik wrote:
> > --- a/kernel/kexec_core.c
> > +++ b/kernel/kexec_core.c
> > @@ -95,6 +95,12 @@ int kexec_should_crash(struct task_struct *p)
> > retu
On Wed, 13 Jul 2016 14:19:50 +0200
Petr Tesarik wrote:
> Hello all,
>
> this patch series makes it possible to save a kernel crash dump when the
> kernel command line includes "crash_kexec_post_notifiers".
Oh ... I forgot to add: This only applies to running Linux under X
rs are run
or not: If you load a crash kernel with kexec, it will be used, otherwise
the hypervisor facility is used (using a hypercall).
Feedback welcome!
Petr T
---
Petr Tesarik (2):
Add a kexec_crash_loaded() function
Allow kdump with crash_kexec_post_notifiers
arch/x86/xen/e
dules separately to enable the use of PV
drivers with unmodified bare-metal kernels.
Signed-off-by: Petr Tesarik
---
include/linux/kexec.h |2 ++
kernel/kexec_core.c |6 ++
kernel/ksysfs.c |2 +-
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/include/
If a crash kernel is loaded, do not crash the running domain. This is
needed if the kernel is loaded with crash_kexec_post_notifiers, because
panic notifiers are run before __crash_kexec() in that case, and this
Xen hook prevents its being called later.
Signed-off-by: Petr Tesarik
---
arch/x86
Linux writes:
> > >> > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote:
> > >> >> I'm not an expert on DTB, so I can't provide an example of code
> > >> >> execution, but you have already mentioned the
> > >>
On Tue, 12 Jul 2016 16:22:07 -0500
ebied...@xmission.com (Eric W. Biederman) wrote:
> Petr Tesarik writes:
>
> > On Tue, 12 Jul 2016 13:25:11 -0300
> > Thiago Jung Bauermann wrote:
>[...]
> >> I also don't understand what you mean by code execution. How doe
On Tue, 12 Jul 2016 13:25:11 -0300
Thiago Jung Bauermann wrote:
> Hi Eric,
>
> I'm trying to understand your concerns leading to your nack. I hope you
> don't mind expanding your thoughts on them a bit.
>
> Am Dienstag, 12 Juli 2016, 08:25:48 schrieb Eric W. Biederman:
> > AKASHI Takahiro wri
On Thu, 24 Mar 2016 16:03:07 +0100
David Sterba wrote:
> On Sun, Mar 20, 2016 at 03:11:11PM +0800, Flex Liu wrote:
>[...]
> > --- a/fs/btrfs/volumes.c
> > +++ b/fs/btrfs/volumes.c
> > @@ -2325,7 +2325,10 @@ int btrfs_init_new_device(struct btrfs_root *root,
> > char *device_path)
> > if (see
V Tue, 24 Nov 2015 10:35:03 +
Andrew Cooper napsáno:
> On 24/11/15 10:17, Petr Tesarik wrote:
> > On Tue, 24 Nov 2015 10:09:01 +
> > David Vrabel wrote:
> >
> >> On 24/11/15 09:55, Malcolm Crossley wrote:
> >>> On 24/11/15 08:59, Jan Beulich wro
On Tue, 24 Nov 2015 10:09:01 +
David Vrabel wrote:
> On 24/11/15 09:55, Malcolm Crossley wrote:
> > On 24/11/15 08:59, Jan Beulich wrote:
> > On 24.11.15 at 07:55, wrote:
> >>> What about:
> >>>
> >>> 4) Instead of relying on the kernel maintained p2m list for m2p
> >>>conversion use
On Sun, 26 Jul 2015 15:32:54 +0200
Oliver Neukum wrote:
> On Fri, 2015-07-24 at 08:48 +0200, Petr Tesarik wrote:
> > @@ -872,6 +886,12 @@ static int cp210x_startup(struct usb_serial
> > *serial)
> >
> > usb_set_serial_data(serial, spriv);
> >
> >
On Fri, 24 Jul 2015 14:33:23 -0700
Greg Kroah-Hartman wrote:
> On Fri, Jul 24, 2015 at 11:00:38PM +0200, Petr Tesarik wrote:
> > On Fri, 24 Jul 2015 11:17:55 -0700
> > Greg Kroah-Hartman wrote:
> >
> > > On Fri, Jul 24, 2015 at 08:48:11AM +0200, Petr Tesarik wro
On Fri, 24 Jul 2015 11:17:55 -0700
Greg Kroah-Hartman wrote:
> On Fri, Jul 24, 2015 at 08:48:11AM +0200, Petr Tesarik wrote:
> > From: Petr Tesarik
> >
> > Make it possible to read the cp210x part number from userspace by making
> > it a sysfs attribute.
> >
From: Petr Tesarik
There is a lot of overlap between the two functions (e.g. calculation
of the buffer size), so this removes a bit of code duplication, but
most importantly, a more generic function can be easily reused for
other message types.
Signed-off-by: Petr Tesarik
---
drivers/usb
From: Petr Tesarik
The request type is in fact made of three fields that already have
symbolic constants.
While I was rewriting those lines, I also converted the pre-processor
defines into an enum, so they are seen by debuggers.
Signed-off-by: Petr Tesarik
---
drivers/usb/serial/cp210x.c
From: Petr Tesarik
Query and store the CP210x part number.
Signed-off-by: Petr Tesarik
---
drivers/usb/serial/cp210x.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index 69f03b6..dbfc722 100644
--- a
set if that's preferred.
Petr Tesarik (4):
cp210x: Replace USB magic numbers with symbolic names
cp210x: Unify code for set/get config control messages
cp210x: Store part number
cp210x: Expose the part number in sysfs
drivers/usb/serial/cp210x.c
From: Petr Tesarik
Make it possible to read the cp210x part number from userspace by making
it a sysfs attribute.
Signed-off-by: Petr Tesarik
---
drivers/usb/serial/cp210x.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/cp210x.c b
> In QEMU, the *master* end is the source/sink for the guest VM, while the
> *slave* pty is sink/source for the host. Like this:
Yes, you're totally right. This patch implements break handling on the
"wrong" side of the pty pair. I think you have already pointed this
ou
On Mon, 16 Feb 2015 11:24:16 -0500
Peter Hurley wrote:
> Hi Petr,
>
> On 02/16/2015 08:22 AM, Petr Tesarik wrote:
> > On Mon, 16 Feb 2015 08:04:02 -0500
> > Peter Hurley wrote:
> >
> >> On 02/05/2015 02:11 PM, Nan Li wrote:
> >>> This will great
plements the latter, adding at least one valid use case
to explain why it is better than the former.
Regards,
Petr Tesarik
> > Signed-off-by: Nan Li
> > ---
> > drivers/tty/pty.c | 19 +++
> > 1 file changed, 19 insertions(+)
> >
> > diff --git a
On Fri, 14 Nov 2014 18:54:23 +0900 (JST)
HATAYAMA Daisuke wrote:
> From: Petr Tesarik
> Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in
> VMCOREINFO
> Date: Fri, 14 Nov 2014 09:31:45 +0100
>
> > On Fri, 14 Nov 2014 10:42:35 +0900 (JST)
> &
On Fri, 14 Nov 2014 10:42:35 +0900 (JST)
HATAYAMA Daisuke wrote:
> From: Petr Tesarik
> Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in
> VMCOREINFO
> Date: Thu, 13 Nov 2014 15:48:10 +0100
>
> > On Thu, 13 Nov 2014 09:25:48 -0500
> > Vivek Goy
On Thu, 13 Nov 2014 09:25:48 -0500
Vivek Goyal wrote:
> On Thu, Nov 13, 2014 at 05:30:21PM +0900, HATAYAMA, Daisuke wrote:
> >
> > (2014/11/13 17:06), Petr Tesarik wrote:
> > >On Thu, 13 Nov 2014 09:17:09 +0900 (JST)
> > >HATAYAMA Daisuke wrote:
> > >
On Thu, 13 Nov 2014 09:17:09 +0900 (JST)
HATAYAMA Daisuke wrote:
> From: Vivek Goyal
> Subject: Re: [PATCH] kdump, x86: report actual value of phys_base in
> VMCOREINFO
> Date: Wed, 12 Nov 2014 17:12:05 -0500
>
> > On Wed, Nov 12, 2014 at 03:40:42PM +0900, HATAYAMA Daisuke wrote:
> >> Currentl
On Wed, 12 Nov 2014 15:40:42 +0900 (JST)
HATAYAMA Daisuke wrote:
> Currently, VMCOREINFO note information reports the virtual address of
> phys_base that is assigned to symbol phys_base. But this doesn't make
> sense because to refer to value of the phys_base, it's necessary to
> get the value of
On Thu, 11 Sep 2014 17:16:37 -0400
Vivek Goyal wrote:
> On Thu, Sep 11, 2014 at 10:43:30PM +0200, Petr Tesarik wrote:
> > On Thu, 11 Sep 2014 16:01:10 -0400
> > Vivek Goyal wrote:
> >
> > > On Fri, Sep 05, 2014 at 06:33:14PM +0200, Petr Tesarik wrote:
> >
On Thu, 11 Sep 2014 16:01:10 -0400
Vivek Goyal wrote:
> On Fri, Sep 05, 2014 at 06:33:14PM +0200, Petr Tesarik wrote:
> > On architectures that use percpu-vm, the percpu region is not guaranteed
> > to be contiguous in physical space.
>
> Petr,
>
> Which are thos
Hi all,
is anything wrong with the patch below? Are there questions? I thought
this would be an easy one-line bugfix...
Regards,
Petr Tesarik
On Fri, 5 Sep 2014 18:33:14 +0200
Petr Tesarik wrote:
> On architectures that use percpu-vm, the percpu region is not guaranteed
> to be contigu
page boundary,
effectively ensuring that the whole buffer is contiguous in physical
space.
Signed-off-by: Petr Tesarik
---
kernel/kexec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 2bee072..cdab59d 100644
--- a/kernel/kexec.c
On Tue, 29 Apr 2014 06:29:04 -0700
"H. Peter Anvin" wrote:
> On 04/29/2014 06:05 AM, Jiri Kosina wrote:
> >
> > We were not able to come up with any other fix than avoiding using IST
> > completely on x86_64, and instead going back to stack switching in
> > software -- the same way 32bit x86 d
On Fri, 11 Apr 2014 17:50:39 +0200
Petr Tesarik wrote:
> To allow filtering of huge pages, makedumpfile must be able to
> identify them in the dump. This can be done by checking the
> appropriate page flag, so communicate its value to makedumpfile
> through the VMCOREINFO interface.
n.
Signed-off-by: Petr Tesarik
---
include/linux/page-flags.h | 3 +++
kernel/kexec.c | 1 +
2 files changed, 4 insertions(+)
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index d1fe1a7..bc2007e 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/pa
On Thu, 30 Jan 2014 07:04:07 -0800
Greg Kroah-Hartman wrote:
> On Thu, Jan 30, 2014 at 03:03:32PM +0100, Petr Tesarik wrote:
> > On Thu, 30 Jan 2014 05:28:27 -0800
> > Greg Kroah-Hartman wrote:
> >
> > > On Thu, Jan 30, 2014 at 09:48:02AM +0100, Petr Tesarik wrot
On Thu, 22 Nov 2012 14:26:10 -0800
"H. Peter Anvin" wrote:
> Bullshit. This should be a separate domain.
Thanks for top-posting, hpa...
> Andrew Cooper wrote:
>
> >On 22/11/12 17:47, H. Peter Anvin wrote:
> >> The other thing that should be considered here is how utterly
> >> preposterous t
On Mon, 24 Feb 2014 11:41:31 -0500
Vivek Goyal wrote:
> On Fri, Feb 21, 2014 at 03:59:10PM +0100, Borislav Petkov wrote:
>
>[...]
> >
> > ...
> >
> > > diff --git a/include/uapi/linux/kexec.h b/include/uapi/linux/kexec.h
> > > index d6629d4..5fddb1b 100644
> > > --- a/include/uapi/linux/kexec.
On Mon, 17 Feb 2014 16:07:04 -0300
Henrique de Moraes Holschuh wrote:
> On Mon, 17 Feb 2014, Petr Tesarik wrote:
> > This results in:
> >
> > total_cpus = 1008 /* this is purely informative, it is *NOT* used
> > to size anyt
On Mon, 17 Feb 2014 10:40:07 -0300
Henrique de Moraes Holschuh wrote:
> On Mon, 17 Feb 2014, Petr Tesarik wrote:
> > Well, if the user passes both nr_cpus and maxcpus parameters to the
> > kernel, I think it's fair to issue two warnings. But if everyone agrees
> > tha
Hi Jan,
On Mon, 17 Feb 2014 08:34:34 +
"Jan Beulich" wrote:
> >>> On 15.02.14 at 15:02, Petr Tesarik wrote:
> > --- a/arch/x86/kernel/smpboot.c
> > +++ b/arch/x86/kernel/smpboot.c
> > @@ -1226,9 +1226,6 @@ __init void prefill_possible_
if "possible_cpus" was also specified on the command line.
I strongly believe that such limitation was unintentional.
I also changed the message slightly -- the kernel parameter name is
maxcpus, not max_cpus.
Signed-off-by: Petr Tesarik
---
arch/x86/kernel/smpboot.c | 5 +
1 file
INIT IPI to boot cpu too and not need disable_cpu_apicid.
Yes, that was my thinking. We really only need all this, because
current BIOS implementations do not offer a way to override the default
initialization routine on a BSP. In fact, I disassembled the INIT
vector of a few BIOSes to see if the old 286 way of leaving protected
mode (via a CMOS location) is still supported and might be used at
least on some hardware. It is not, but that doesn't mean future BIOSes
may not re-implement something like that.
Sorry for coming late to the party...
Petr Tesarik
--
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/
Commit-ID: 85fc73a2cdf10cf42bc36fb3bca3896b2095a1c2
Gitweb: http://git.kernel.org/tip/85fc73a2cdf10cf42bc36fb3bca3896b2095a1c2
Author: Petr Tesarik
AuthorDate: Sat, 1 Feb 2014 13:30:19 +0100
Committer: H. Peter Anvin
CommitDate: Sat, 1 Feb 2014 22:15:51 -0800
x86: Fix the
Commit-ID: 170750c108bb9382f32a2a99d097aa07d551a89e
Gitweb: http://git.kernel.org/tip/170750c108bb9382f32a2a99d097aa07d551a89e
Author: Petr Tesarik
AuthorDate: Sat, 1 Feb 2014 13:30:19 +0100
Committer: H. Peter Anvin
CommitDate: Sat, 1 Feb 2014 21:57:48 -0800
x86: Fix the
unaligned.
2. Large reservations are more likely to span across a 64M boundary.
Signed-off-by: Petr Tesarik
---
arch/x86/mm/numa_32.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/mm/numa_32.c b/arch/x86/mm/numa_32.c
index 0342d27..8c62ec6 100644
--- a/arch/x86/mm/numa_32.c
+++ b/arch
On Fri, 31 Jan 2014 13:14:29 -0800
Dave Hansen wrote:
> On 01/31/2014 02:05 AM, Petr Tesarik wrote:
> > With DISCONTIGMEM, the mapping between a pfn and its owning node is
> > initialized using data provided by the BIOS or from the command line.
> > However, the initializ
more likely to be unaligned.
2. Large reservations are more likely to span across a 64M boundary.
Signed-off-by: Petr Tesarik
---
arch/x86/mm/numa_32.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/mm/numa_32.c b/arch/x86/mm/numa_32.c
index 0342d27
On Thu, 30 Jan 2014 05:28:27 -0800
Greg Kroah-Hartman wrote:
> On Thu, Jan 30, 2014 at 09:48:02AM +0100, Petr Tesarik wrote:
> > The loff_t type may be wider than phys_addr_t (e.g. on 32-bit systems).
> > Consequently, the file offset may be truncated in the assignment.
> >
here and return 0 when reading from
and -EFBIG when writing to an offset that cannot be represented by a
phys_addr_t.
Note that the conditional is optimized out by the compiler if loff_t
has the same size as phys_addr_t.
Signed-off-by: Petr Tesarik
---
drivers/char/mem.c | 6 ++
1 file ch
On Fri, 08 Nov 2013 13:27:05 +0800
Jingbai Ma wrote:
> On 11/08/2013 01:21 PM, HATAYAMA Daisuke wrote:
> > (2013/11/08 14:12), Atsushi Kumagai wrote:
> >> Hello Jingbai,
> >>
> >> (2013/11/07 17:58), Jingbai Ma wrote:
> >>> On 11/06/2013 10:23 PM, Vivek Goyal wrote:
> On Wed, Nov 06, 2013 at
On Wed, 9 Oct 2013 16:20:12 -0400
Vivek Goyal wrote:
> On Fri, Aug 30, 2013 at 08:43:56AM -0700, H. Peter Anvin wrote:
> > On 08/29/2013 04:51 PM, HATAYAMA Daisuke wrote:
> > >
> > > This is not a regression just as Eric explains.
> > >
> > > There is also my explanation in the description of t
, and
yes, that works even if the secondary kernel is booted from an AP. OTOH
I suspect that not having any BSP in the system may be the cause of some
mysterious random reboots and/or hangs experienced by some customers.
I'll try setting the BSP flag on the boot CPU unconditionally and see
if
On Mon, 16 Apr 2012 11:21:28 +0900
HATAYAMA Daisuke wrote:
> Currently, booting up 2nd kernel with multiple CPUs fails in most
> cases since it enters 2nd kernel with AP if the crash happens on the
> AP. The problem is to signal startup IPI from AP to BSP. Typical
> result of the operation I saw
V Tue, 27 Nov 2012 15:25:35 -0600
ebied...@xmission.com (Eric W. Biederman) napsáno:
> Petr Tesarik writes:
>
> > To allow filtering of huge pages, makedumpfile must be able to
> > identify them in the dump. This can be done by checking for the
> > appropriate page
To allow filtering of huge pages, makedumpfile must be able to identify
them in the dump. This can be done by checking for the appropriate
page flag, so communicate its value to makedumpfile through the VMCOREINFO
interface.
Signed-off-by: Petr Tesarik
---
kernel/kexec.c |5 +
1 file
process(__vm_enough_memory()).
>
> [root@localhost ~]# dmesg
> -bash: fork: Cannot allocate memory
>
> I think bug described in http://marc.info/?l=linux-mm&m=134502182714186&w=2
> is also caused by wrong zone present pages.
And yes, I can confirm that the bug I reported
Oleg Nesterov wrote:
> On 01/10, Petr Tesarik wrote:
>> I can actually see a bug which may be related:
>>
>> 1. a process creates a thread (or more threads)
>> 2. I attach/detach to that thread with strace several times
>> (each time pressing CTRL-C
thread is
running, i.e. not waiting in ptrace_stop. Then PTRACE_DETACH returns
- -ESRCH because it requires the tracee to be stopped -- just like all
PTRACE_* requests except TRACEME and ATTACH. So, strace has no other
option than to send an explicit SIGSTOP to the thread to stop it and
dis
SE, because they make it possible to get rid of
find_thread_for_addr(). I already sent a mail about it to linux-ia64
some time ago, and Roland suggested we might even change everything to
the generic sys_ptrace(), which is the correct solution (TM), and I'm
planning to do it so as soon as th
Petr Tesarik wrote:
> Hi,
>
> I experienced troubles when tracing a process with strace. Sometimes,
> when I killed the strace process (SIGKILL), the traced process was also
> killed. I found out that it was getting SIGTRAP and, indeed, when the
> traced process set up a
;
The exit_code is set in ptrace_stop(), but the tracing process may go
away while the traced process waits for it, and in that case exit_code
is left as-is. I think we must set it to zero in ptrace_untrace().
Signed-off-by: Petr Tesarik <[EMAIL PROTECTED]>
ptrace.c |1 +
1 file changed,
On Mon, 2007-11-19 at 06:42 -0500, Jeff Layton wrote:
> On Mon, 19 Nov 2007 10:30:45 +0100
> Petr Tesarik <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > while merging commits f01d5e14e764b14b6bf5512678523d009254b209 and
> > 638b250766272fcaaa0f7ed2776
g for length < pdu_length, not for length <
4, because if we read 2 bytes in the first run and 2 bytes in the second
un, CIFS will still treat the second run as incomplete (and possibly run
in an infinite loop). Am I missing something obvious?
Kind regards,
Petr Tesarik
-
To unsubscribe fr
ith this one sentence, please also read
the rest of the chapter; it is not long and you'll understand the
author's intention better.)
Kind regards,
Petr Tesarik
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
On Thu, 2007-08-16 at 11:54 +0530, Anand Jahagirdar wrote:
> Hello All
>I have searched for Maintainers List to get the correct
> Maintainer for my patch. But i am not getting exact maintainer to
> which i should forward my patch. Will any body please tell me,to which
> maintainer i sho
1 - 100 of 101 matches
Mail list logo
