RE: [RFC][PATCH 0/2] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions if existed

2017-06-15 Thread Izumi, Taku
Dear Baoquan, > > Our customer reported that Kernel text may be located on non-mirror > > region (movable zone) when both address range mirroring feature and > > KASLR are enabled. I know your customer :) > > The functions of address range mirroring feature are as follows. > > - The physical

RE: [RFC][PATCH 0/2] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions if existed

2017-06-15 Thread Izumi, Taku
Dear Baoquan, > > Our customer reported that Kernel text may be located on non-mirror > > region (movable zone) when both address range mirroring feature and > > KASLR are enabled. I know your customer :) > > The functions of address range mirroring feature are as follows. > > - The physical

RE: [bug discuss] fjes driver call trace warning, "PNP0C02" used in fjes seems like a bug,

2016-06-09 Thread Izumi, Taku
Dear Gao, > From a SW perspective it like an acpi driver that uses "PNP0C02" > as driver ids to perform the driver match in the ACPI table. > > From my understanding this is wrong in principle because that identifier > must be used to reserve motherboard resources (see par 4.1.2 of the PCI >

RE: [bug discuss] fjes driver call trace warning, "PNP0C02" used in fjes seems like a bug,

2016-06-09 Thread Izumi, Taku
Dear Gao, > From a SW perspective it like an acpi driver that uses "PNP0C02" > as driver ids to perform the driver match in the ACPI table. > > From my understanding this is wrong in principle because that identifier > must be used to reserve motherboard resources (see par 4.1.2 of the PCI >

RE: [PATCH] net: fjes: fjes_main: Remove create_workqueue

2016-06-02 Thread Izumi, Taku
Dear Bhaktipriya, Thanks. Looks good to me. Sincerely, Taku Izumi > -Original Message- > From: Bhaktipriya Shridhar [mailto:bhaktipriy...@gmail.com] > Sent: Thursday, June 02, 2016 6:31 PM > To: David S. Miller; Izumi, Taku/泉 拓; Florian Westphal; Bhaktipriya Shridhar >

RE: [PATCH] net: fjes: fjes_main: Remove create_workqueue

2016-06-02 Thread Izumi, Taku
Dear Bhaktipriya, Thanks. Looks good to me. Sincerely, Taku Izumi > -Original Message- > From: Bhaktipriya Shridhar [mailto:bhaktipriy...@gmail.com] > Sent: Thursday, June 02, 2016 6:31 PM > To: David S. Miller; Izumi, Taku/泉 拓; Florian Westphal; Bhaktipriya Shridhar >

RE: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option

2015-12-16 Thread Izumi, Taku
Dear Xishi, Sorry for late. > -Original Message- > From: Xishi Qiu [mailto:qiuxi...@huawei.com] > Sent: Friday, December 11, 2015 6:44 PM > To: Izumi, Taku/泉 拓 > Cc: Luck, Tony; linux-kernel@vger.kernel.org; linux...@kvack.org; > a...@linux-foundation.org; Kamezawa,

RE: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option

2015-12-16 Thread Izumi, Taku
Dear Xishi, Sorry for late. > -Original Message- > From: Xishi Qiu [mailto:qiuxi...@huawei.com] > Sent: Friday, December 11, 2015 6:44 PM > To: Izumi, Taku/泉 拓 > Cc: Luck, Tony; linux-kernel@vger.kernel.org; linux...@kvack.org; > a...@linux-foundation.org; Kamezawa,

RE: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option

2015-12-10 Thread Izumi, Taku
Dear Xishi, > Hi Taku, > > Whether it is possible that we rewrite the fallback function in buddy system > when zone_movable and mirrored_kernelcore are both enabled? What does "when zone_movable and mirrored_kernelcore are both enabled?" mean ? My patchset just provides a new way to

RE: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option

2015-12-10 Thread Izumi, Taku
Dear Xishi, > Hi Taku, > > Whether it is possible that we rewrite the fallback function in buddy system > when zone_movable and mirrored_kernelcore are both enabled? What does "when zone_movable and mirrored_kernelcore are both enabled?" mean ? My patchset just provides a new way to

RE: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option

2015-12-09 Thread Izumi, Taku
Dear Tony, Xishi, > >> How about add some comment, if mirrored memroy is too small, then the > >> normal zone is small, so it may be oom. > >> The mirrored memory is at least 1/64 of whole memory, because struct > >> pages usually take 64 bytes per page. > > > > 1/64th is the absolute lower bound

RE: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option

2015-12-09 Thread Izumi, Taku
Dear Tony, Xishi, > >> How about add some comment, if mirrored memroy is too small, then the > >> normal zone is small, so it may be oom. > >> The mirrored memory is at least 1/64 of whole memory, because struct > >> pages usually take 64 bytes per page. > > > > 1/64th is the absolute lower bound

RE: [PATCH v2 2/2] mm: Introduce kernelcore=reliable option

2015-12-08 Thread Izumi, Taku
Dear Xishi, Thanks for reviewing. > -Original Message- > From: Xishi Qiu [mailto:qiuxi...@huawei.com] > Sent: Wednesday, December 09, 2015 11:26 AM > To: Izumi, Taku/泉 拓 > Cc: linux-kernel@vger.kernel.org; linux...@kvack.org; tony.l...@intel.com; > Kamezawa,

RE: [PATCH v2 0/2] mm: Introduce kernelcore=reliable option

2015-12-08 Thread Izumi, Taku
Dear Tony, > > Which do you think is beter ? > >- change into kernelcore="mirrored" > >- keep kernelcore="reliable" and minmal printk fix > > UEFI came up with the "reliable" wording (as a more generic term ... > as Andrew said > it could cover differences in ECC modes, or some

RE: [PATCH v2 0/2] mm: Introduce kernelcore=reliable option

2015-12-08 Thread Izumi, Taku
Dear Tony, Thanks for testing! Dear Andrew, > > Xeon E7 v3 based systems supports Address Range Mirroring > > and UEFI BIOS complied with UEFI spec 2.5 can notify which > > ranges are reliable (mirrored) via EFI memory map. > > Now Linux kernel utilize its information and allocates > > boot

RE: [PATCH v2 0/2] mm: Introduce kernelcore=reliable option

2015-12-08 Thread Izumi, Taku
Dear Tony, Thanks for testing! Dear Andrew, > > Xeon E7 v3 based systems supports Address Range Mirroring > > and UEFI BIOS complied with UEFI spec 2.5 can notify which > > ranges are reliable (mirrored) via EFI memory map. > > Now Linux kernel utilize its information and allocates > > boot

RE: [PATCH v2 0/2] mm: Introduce kernelcore=reliable option

2015-12-08 Thread Izumi, Taku
Dear Tony, > > Which do you think is beter ? > >- change into kernelcore="mirrored" > >- keep kernelcore="reliable" and minmal printk fix > > UEFI came up with the "reliable" wording (as a more generic term ... > as Andrew said > it could cover differences in ECC modes, or some

RE: [PATCH v2 2/2] mm: Introduce kernelcore=reliable option

2015-12-08 Thread Izumi, Taku
Dear Xishi, Thanks for reviewing. > -Original Message- > From: Xishi Qiu [mailto:qiuxi...@huawei.com] > Sent: Wednesday, December 09, 2015 11:26 AM > To: Izumi, Taku/泉 拓 > Cc: linux-kernel@vger.kernel.org; linux...@kvack.org; tony.l...@intel.com; > Kamezawa,

RE: [PATCH] fjes: fix inconsistent indenting

2015-11-11 Thread Izumi, Taku
Thanks, Colin. Signed-off-by: Taku Izumi > -Original Message- > From: Colin King [mailto:colin.k...@canonical.com] > Sent: Thursday, November 12, 2015 12:23 AM > To: David S. Miller; Izumi, Taku/泉 拓; Markus Elfring; net...@vger.kernel.org > Cc: linux-kernel@vger.kerne

RE: [PATCH] fjes: fix inconsistent indenting

2015-11-11 Thread Izumi, Taku
Thanks, Colin. Signed-off-by: Taku Izumi <izumi.t...@jp.fujitsu.com> > -Original Message- > From: Colin King [mailto:colin.k...@canonical.com] > Sent: Thursday, November 12, 2015 12:23 AM > To: David S. Miller; Izumi, Taku/泉 拓; Markus Elfring; net...@vger.kernel.org

RE: [PATCH] mm: Introduce kernelcore=reliable option

2015-10-22 Thread Izumi, Taku
Dear Tony, > -Original Message- > From: Luck, Tony [mailto:tony.l...@intel.com] > Sent: Friday, October 23, 2015 8:27 AM > To: Kamezawa, Hiroyuki/亀澤 寛之; Izumi, Taku/泉 拓; linux-kernel@vger.kernel.org; > linux...@kvack.org > Cc: qiuxi...@huawei.com; m...@csn

RE: [PATCH] efi: Fix warning of int-to-pointer-cast on x86 32-bit builds

2015-10-22 Thread Izumi, Taku
Dear Ard, > > commit-0f96a99 introduces the following warning message: > > > > drivers/firmware/efi/fake_mem.c:186:20: warning: cast to pointer > > from integer of different size [-Wint-to-pointer-cast] > > > > new_memmap_phy was defined as a u64 value and casted to void*. > > This causes a

RE: [PATCH] efi: Fix warning of int-to-pointer-cast on x86 32-bit builds

2015-10-22 Thread Izumi, Taku
Dear Ard, > > commit-0f96a99 introduces the following warning message: > > > > drivers/firmware/efi/fake_mem.c:186:20: warning: cast to pointer > > from integer of different size [-Wint-to-pointer-cast] > > > > new_memmap_phy was defined as a u64 value and casted to void*. > > This causes a

RE: [PATCH] mm: Introduce kernelcore=reliable option

2015-10-22 Thread Izumi, Taku
Dear Tony, > -Original Message- > From: Luck, Tony [mailto:tony.l...@intel.com] > Sent: Friday, October 23, 2015 8:27 AM > To: Kamezawa, Hiroyuki/亀澤 寛之; Izumi, Taku/泉 拓; linux-kernel@vger.kernel.org; > linux...@kvack.org > Cc: qiuxi...@huawei.com; m...@csn

RE: [PATCH] mm: Introduce kernelcore=reliable option

2015-10-19 Thread Izumi, Taku
Hi Xishi, > On 2015/10/15 21:32, Taku Izumi wrote: > > > Xeon E7 v3 based systems supports Address Range Mirroring > > and UEFI BIOS complied with UEFI spec 2.5 can notify which > > ranges are reliable (mirrored) via EFI memory map. > > Now Linux kernel utilize its information and allocates > >

RE: [PATCH] mm: Introduce kernelcore=reliable option

2015-10-19 Thread Izumi, Taku
Hi Xishi, > On 2015/10/15 21:32, Taku Izumi wrote: > > > Xeon E7 v3 based systems supports Address Range Mirroring > > and UEFI BIOS complied with UEFI spec 2.5 can notify which > > ranges are reliable (mirrored) via EFI memory map. > > Now Linux kernel utilize its information and allocates > >

RE: [PATCH][RFC] mm: Introduce kernelcore=reliable option

2015-10-13 Thread Izumi, Taku
> > I remember Kame has already suggested this idea. In my opinion, > > I still think it's better to add a new migratetype or a new zone, > > so both user and kernel could use mirrored memory. > > A new zone would be more flexible ... and probably the right long > term solution. But this looks

RE: [PATCH][RFC] mm: Introduce kernelcore=reliable option

2015-10-13 Thread Izumi, Taku
> > I remember Kame has already suggested this idea. In my opinion, > > I still think it's better to add a new migratetype or a new zone, > > so both user and kernel could use mirrored memory. > > A new zone would be more flexible ... and probably the right long > term solution. But this looks

RE: [PATCH 2/2] x86, efi: Add "efi_fake_mem" boot option

2015-09-29 Thread Izumi, Taku
I've missed git-format-patch after rebasing. I'll resend right one.. > -Original Message- > From: kbuild test robot [mailto:l...@intel.com] > Sent: Wednesday, September 30, 2015 10:37 AM > To: Izumi, Taku/泉 拓 > Cc: kbuild-...@01.org; linux-kernel@vger.kerne

RE: [PATCH 2/2] x86, efi: Add "efi_fake_mem" boot option

2015-09-29 Thread Izumi, Taku
I've missed git-format-patch after rebasing. I'll resend right one.. > -Original Message- > From: kbuild test robot [mailto:l...@intel.com] > Sent: Wednesday, September 30, 2015 10:37 AM > To: Izumi, Taku/泉 拓 > Cc: kbuild-...@01.org; linux-kernel@vger.kerne

RE: [PATCH 2/2] x86, efi: Add "efi_fake_mem_mirror" boot option

2015-08-26 Thread Izumi, Taku
Dear Matt, Thank you for reviewing. I updated my patchset. I'm happy if you review new one. Sincerely, Taku Izumi > -Original Message- > From: Matt Fleming [mailto:m...@codeblueprint.co.uk] > Sent: Wednesday, August 26, 2015 8:46 AM > To: Izumi, Taku/泉 拓 > C

RE: [PATCH 2/2] x86, efi: Add efi_fake_mem_mirror boot option

2015-08-26 Thread Izumi, Taku
Dear Matt, Thank you for reviewing. I updated my patchset. I'm happy if you review new one. Sincerely, Taku Izumi -Original Message- From: Matt Fleming [mailto:m...@codeblueprint.co.uk] Sent: Wednesday, August 26, 2015 8:46 AM To: Izumi, Taku/泉 拓 Cc: linux-kernel@vger.kernel.org

RE: [RFC PATCH 0/2 shit_A shit_B] workqueue: fix wq_numa bug

2015-01-22 Thread Izumi, Taku
> This patches are un-changloged, un-compiled, un-booted, un-tested, > they are just shits, I even hope them un-sent or blocked. > > The patches include two -solutions-: > > Shit_A: > workqueue: reset pool->node and unhash the pool when the node is > offline > update wq_numa when

RE: [RFC PATCH 0/2 shit_A shit_B] workqueue: fix wq_numa bug

2015-01-22 Thread Izumi, Taku
This patches are un-changloged, un-compiled, un-booted, un-tested, they are just shits, I even hope them un-sent or blocked. The patches include two -solutions-: Shit_A: workqueue: reset pool-node and unhash the pool when the node is offline update wq_numa when cpu_present_mask