Re: [PATCH v2] x86/build: fix compiler support check for CONFIG_RETPOLINE

On Wed, Dec 5, 2018 at 8:11 AM Zhenzhong Duan wrote: > > > On 2018/12/5 14:27, Masahiro Yamada wrote: > > It is troublesome to add a diagnostic like this to the Makefile > > parse stage because the top-level Makefile could be parsed with > > a stale include/config/auto.conf. > > > > Once you are

Re: [PATCH] md: bitmap: use mddev_suspend/resume instead of ->quiesce()

On Thu, Sep 13, 2018 at 5:35 PM, Jack Wang wrote: > From: Jack Wang > > After 9e1cc0a54556 ("md: use mddev_suspend/resume instead of ->quiesce()") > We still have similar left in bitmap functions. > > Replace quiesce() with mddev_suspend/resume. > > Also move md_bitmap_create out of

Re: [PATCH] md: bitmap: use mddev_suspend/resume instead of ->quiesce()

On Thu, Sep 13, 2018 at 5:35 PM, Jack Wang wrote: > From: Jack Wang > > After 9e1cc0a54556 ("md: use mddev_suspend/resume instead of ->quiesce()") > We still have similar left in bitmap functions. > > Replace quiesce() with mddev_suspend/resume. > > Also move md_bitmap_create out of

Re: [PATCH V6 00/30] block: support multipage bvec

On Thu, Jun 21, 2018 at 3:17 AM, Ming Lei wrote: > On Fri, Jun 15, 2018 at 02:59:19PM +0200, Gi-Oh Kim wrote: >> > >> > - bio size can be increased and it should improve some high-bandwidth IO >> > case in theory[4]. >> > >> >> Hi, >>

Re: [PATCH V6 00/30] block: support multipage bvec

On Thu, Jun 21, 2018 at 3:17 AM, Ming Lei wrote: > On Fri, Jun 15, 2018 at 02:59:19PM +0200, Gi-Oh Kim wrote: >> > >> > - bio size can be increased and it should improve some high-bandwidth IO >> > case in theory[4]. >> > >> >> Hi, >>

Re: [PATCH] infiniband: fix a possible use-after-free bug

On Mon, Jun 4, 2018 at 6:46 PM, Jason Gunthorpe wrote: > On Mon, Jun 04, 2018 at 06:23:20PM +0200, Gi-Oh Kim wrote: >> On Fri, Jun 1, 2018 at 8:31 PM, Cong Wang wrote: >> > ucma_process_join() will free the new allocated "mc" struct, >> > if ther

Re: [PATCH] infiniband: fix a possible use-after-free bug

On Mon, Jun 4, 2018 at 6:46 PM, Jason Gunthorpe wrote: > On Mon, Jun 04, 2018 at 06:23:20PM +0200, Gi-Oh Kim wrote: >> On Fri, Jun 1, 2018 at 8:31 PM, Cong Wang wrote: >> > ucma_process_join() will free the new allocated "mc" struct, >> > if ther

Re: [PATCH] infiniband: fix a possible use-after-free bug

On Fri, Jun 1, 2018 at 8:31 PM, Cong Wang wrote: > ucma_process_join() will free the new allocated "mc" struct, > if there is any error after that, especially the copy_to_user(). > > But in parallel, ucma_leave_multicast() could find this "mc" > through idr_find() before ucma_process_join() frees

Re: [PATCH] infiniband: fix a possible use-after-free bug

On Fri, Jun 1, 2018 at 8:31 PM, Cong Wang wrote: > ucma_process_join() will free the new allocated "mc" struct, > if there is any error after that, especially the copy_to_user(). > > But in parallel, ucma_leave_multicast() could find this "mc" > through idr_find() before ucma_process_join() frees

Re: [PATCH V4] mlx4_core: allocate ICM memory in page size chunks

On Thu, May 24, 2018 at 1:22 AM, Qing Huang wrote: > When a system is under memory presure (high usage with fragments), > the original 256KB ICM chunk allocations will likely trigger kernel > memory management to enter slow path doing memory compact/migration > ops in order

Re: [PATCH V4] mlx4_core: allocate ICM memory in page size chunks

On Thu, May 24, 2018 at 1:22 AM, Qing Huang wrote: > When a system is under memory presure (high usage with fragments), > the original 256KB ICM chunk allocations will likely trigger kernel > memory management to enter slow path doing memory compact/migration > ops in order to complete high order

Re: [PATCH V2] mlx4_core: allocate ICM memory in page size chunks

On Wed, May 16, 2018 at 9:04 AM, Tariq Toukan wrote: > > > On 15/05/2018 9:53 PM, Qing Huang wrote: >> >> >> >> On 5/15/2018 2:19 AM, Tariq Toukan wrote: >>> >>> >>> >>> On 14/05/2018 7:41 PM, Qing Huang wrote: On 5/13/2018 2:00 AM, Tariq Toukan wrote:

Re: [PATCH V2] mlx4_core: allocate ICM memory in page size chunks

On Wed, May 16, 2018 at 9:04 AM, Tariq Toukan wrote: > > > On 15/05/2018 9:53 PM, Qing Huang wrote: >> >> >> >> On 5/15/2018 2:19 AM, Tariq Toukan wrote: >>> >>> >>> >>> On 14/05/2018 7:41 PM, Qing Huang wrote: On 5/13/2018 2:00 AM, Tariq Toukan wrote: > > > >

Re: [PATCH] md/raid1: add error handling of read error from FailFast device

On Wed, May 2, 2018 at 2:11 PM, Gi-Oh Kim <gi-oh@profitbricks.com> wrote: > On Wed, May 2, 2018 at 1:08 PM, Gioh Kim <gi-oh@profitbricks.com> wrote: >> Current handle_read_error() function calls fix_read_error() >> only if md device is RW and rdev does not includ

Re: [PATCH] md/raid1: add error handling of read error from FailFast device

On Wed, May 2, 2018 at 2:11 PM, Gi-Oh Kim wrote: > On Wed, May 2, 2018 at 1:08 PM, Gioh Kim wrote: >> Current handle_read_error() function calls fix_read_error() >> only if md device is RW and rdev does not include FailFast flag. >> It does not handle a read error from

Re: [PATCH] md/raid1: add error handling of read error from FailFast device

On Wed, May 2, 2018 at 1:08 PM, Gioh Kim wrote: > Current handle_read_error() function calls fix_read_error() > only if md device is RW and rdev does not include FailFast flag. > It does not handle a read error from a RW device including > FailFast flag. > > I am not

Re: [PATCH] md/raid1: add error handling of read error from FailFast device

On Wed, May 2, 2018 at 1:08 PM, Gioh Kim wrote: > Current handle_read_error() function calls fix_read_error() > only if md device is RW and rdev does not include FailFast flag. > It does not handle a read error from a RW device including > FailFast flag. > > I am not sure it is intended. But I

Re: [PATCH] mm/memblock.c: make the index explicit argument of for_each_memblock_type

e, rgn) { >> + for_each_memblock_type(idx, type, rgn) { >> char nid_buf[32] = ""; >> >> base = rgn->base; >> @@ -1739,7 +1739,7 @@ memblock_reserved_memory_within(phys_addr_t >> start_addr, phys_addr_t end_addr) >> unsigned long size = 0; >> int idx; >> >> - for_each_memblock_type((), rgn) { >> + for_each_memblock_type(idx, (), rgn) { >> phys_addr_t start, end; >> >> if (rgn->base + rgn->size < start_addr) >> -- >> 2.11.0 >> > > -- > Michal Hocko > SUSE Labs -- Best regards, Gi-Oh Kim TEL: 0176 2697 8962

Re: [PATCH] mm/memblock.c: make the index explicit argument of for_each_memblock_type

__init_memblock memblock_dump(struct >> memblock_type *type) >> >> pr_info(" %s.cnt = 0x%lx\n", type->name, type->cnt); >> >> - for_each_memblock_type(type, rgn) { >> + for_each_memblock_type(idx, type, rgn) { >>

Re: [RFC] KVM: SVM: ignore type when setting segment registers

6ab75d8 ("KVM: SVM: Fix cross vendor migration issue with >> unusable bit") also moved the assigment up to initialize it before use >> and I think that is enough. > > Was this perhaps intended to instead check for a zero selector, which is also > an unusable segment? I thi

Re: [RFC] KVM: SVM: ignore type when setting segment registers

M: Fix cross vendor migration issue with >> unusable bit") also moved the assigment up to initialize it before use >> and I think that is enough. > > Was this perhaps intended to instead check for a zero selector, which is also > an unusable segment? I think that is what prese

Re: [RFC] KVM: SVM: do not drop VMCB CPL to 0 if SS is not present

nel->userspace->kernel. > > You're right. So what do you think of the other suggestion (svm.c > doesn't clear attributes for unusable registers, QEMU only clears P for > unusable registers)? > > Thanks, > > Paolo -- Best regards, Gi-Oh Kim TEL: 0176 2697 8962

Re: [RFC] KVM: SVM: do not drop VMCB CPL to 0 if SS is not present

->kernel. > > You're right. So what do you think of the other suggestion (svm.c > doesn't clear attributes for unusable registers, QEMU only clears P for > unusable registers)? > > Thanks, > > Paolo -- Best regards, Gi-Oh Kim TEL: 0176 2697 8962

Re: [PATCH 1/4] block: fix module reference leak on put_disk() call for cgroups throttle

0 1048576" > /sys/fs/cgroup/blkio/blkio.throttle.read_bps_device # lsmod | grep loop loop 19171 0 # echo "7:0 1048576" > /sys/fs/cgroup/blkio/blkio.throttle.read_bps_device # lsmod | grep loop loop 19171 0 -- Best regards, Gi-Oh Kim

Re: [PATCH 1/4] block: fix module reference leak on put_disk() call for cgroups throttle

0 1048576" > /sys/fs/cgroup/blkio/blkio.throttle.read_bps_device # lsmod | grep loop loop 19171 0 # echo "7:0 1048576" > /sys/fs/cgroup/blkio/blkio.throttle.read_bps_device # lsmod | grep loop loop 19171 0 -- Best regards, Gi-Oh Kim

Re: [PATCH] hwmon: (fam15h_power) Add bit masking for tdp_limit

as with this patch you'll have two of those checks. Unified might be better readable but that is for another patch. Make sence, I will do that. :-) Thanks, Rui Agree. It'll be better. Thank you. -- Best regards, Gi-Oh Kim

Re: [PATCH] hwmon: (fam15h_power) Add bit masking for tdp_limit

... else ... as with this patch you'll have two of those checks. Unified might be better readable but that is for another patch. Make sence, I will do that. :-) Thanks, Rui Agree. It'll be better. Thank you. -- Best regards, Gi-Oh Kim

Re: [RFC] hwmon: (fam15h_power) Add bit masking for tdp_limit

On 27.01.2016 07:45, Huang Rui wrote: On Tue, Jan 26, 2016 at 11:57:35AM +0100, Gi-Oh Kim wrote: On 26.01.2016 03:25, Huang Rui wrote: On Mon, Jan 25, 2016 at 07:41:07PM +0800, Gioh Kim wrote: Thanks for your reply. I'm not completely sure that the reserved bits are always zero

Re: [RFC] hwmon: (fam15h_power) Add bit masking for tdp_limit

On 27.01.2016 07:45, Huang Rui wrote: On Tue, Jan 26, 2016 at 11:57:35AM +0100, Gi-Oh Kim wrote: On 26.01.2016 03:25, Huang Rui wrote: On Mon, Jan 25, 2016 at 07:41:07PM +0800, Gioh Kim wrote: Thanks for your reply. I'm not completely sure that the reserved bits are always zero

Re: [RFC] hwmon: (fam15h_power) Add bit masking for tdp_limit

On 26.01.2016 03:25, Huang Rui wrote: On Mon, Jan 25, 2016 at 07:41:07PM +0800, Gioh Kim wrote: The bits [31:29] of D18F5xE8 TDP Limit3 are reserved. I think it'd better to add masking to read ApmTdpLimit[28:16] precisely. Signed-off-by: Gioh Kim --- drivers/hwmon/fam15h_power.c | 2 +-

Re: [RFC] hwmon: (fam15h_power) Add bit masking for tdp_limit

On 26.01.2016 03:25, Huang Rui wrote: On Mon, Jan 25, 2016 at 07:41:07PM +0800, Gioh Kim wrote: The bits [31:29] of D18F5xE8 TDP Limit3 are reserved. I think it'd better to add masking to read ApmTdpLimit[28:16] precisely. Signed-off-by: Gioh Kim ---