[Question]many kernel error "neighbour: ndisc_cache: neighbor table overflow!"

nce! Best regards! Jack Wang

Re: [PATCH 4.19 00/57] 4.19.72-stable review

1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.19.y > and the diffstat can be found below. > > thanks, > > greg k-h Merged, boot and tested on my testing machine, no regression found. Thanks, Jack Wang

Re: [PATCH AUTOSEL 4.4 04/14] perf header: Fix divide by zero error if f_header.attr_size==0

is unexpected.\n" "Was the 'perf record' command properly terminated?\n", - data->file.path); + file->path); return -EINVAL; Regards, Jack Wang > diff --git a/tools/perf/util/header.c b/tools/

Re: [PATCH 4.14 00/53] 4.14.137-stable review

1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h > Merge, and regression tested on my test machines, all looks good! Thanks, Jack Wang

Re: [PATCH stable-4.19 1/2] KVM: nVMX: do not use dangling shadow VMCS after guest reset

Paolo Bonzini 于2019年7月29日周一 上午11:10写道： > > On 29/07/19 10:58, Jack Wang wrote: > > Vitaly Kuznetsov 于2019年7月25日周四 下午3:29写道： > >> > >> From: Paolo Bonzini > >> > >> [ Upstream commit 88dddc11a8d6b09201b4db9d255b3394d9bc9e57 ] > >>

Re: [PATCH stable-4.19 1/2] KVM: nVMX: do not use dangling shadow VMCS after guest reset

> Reported-by: Jan Kiszka > Cc: Liran Alon > Cc: sta...@vger.kernel.org > Signed-off-by: Paolo Bonzini Hi all, Do we need to backport the fix also to stable 4.14? It applies cleanly and compiles fine. Regards, Jack Wang

Re: [PATCH 4.14 00/56] 4.14.133-stable review

gt; git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h Merged and tested with my x86_64 systems, no regression found. Regards, Jack Wang @ 1 & 1 IONOS Cloud GmbH

Re: BUG: aio/direct-io data corruption in 4.7

ion: Thanks for the info, Gregory. I noticed guys from Amazon pushing the fix to upstream: https://lore.kernel.org/patchwork/patch/1008443/ I hope it will be in upstream soon. Regards, Jack Wang

Re: BUG: aio/direct-io data corruption in 4.7

ion: Thanks for the info, Gregory. I noticed guys from Amazon pushing the fix to upstream: https://lore.kernel.org/patchwork/patch/1008443/ I hope it will be in upstream soon. Regards, Jack Wang

Re: [PATCH AUTOSEL 4.19 118/146] MD: fix invalid stored role for a disk

i Sasha, This patch breaks linear hotadd please also include commit 9e753ba9b9b405e3902d9f08aec5f2ea58a0c317 MD: fix invalid stored role for a disk - try2 Regards, Jack Wang > --- > drivers/md/md.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/md/md.c b/drive

Re: [PATCH AUTOSEL 4.19 118/146] MD: fix invalid stored role for a disk

i Sasha, This patch breaks linear hotadd please also include commit 9e753ba9b9b405e3902d9f08aec5f2ea58a0c317 MD: fix invalid stored role for a disk - try2 Regards, Jack Wang > --- > drivers/md/md.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/md/md.c b/drive

Re: BUG: aio/direct-io data corruption in 4.7

can I expect it to be applied? > Thanks, > Gregory Hi Gregory, Thanks for your info. Have you tried with latest kernel other than 4.7, is the problem still there? Could you share your test case? Regards, Jack Wang

Re: BUG: aio/direct-io data corruption in 4.7

can I expect it to be applied? > Thanks, > Gregory Hi Gregory, Thanks for your info. Have you tried with latest kernel other than 4.7, is the problem still there? Could you share your test case? Regards, Jack Wang

[PATCH] md: fix memleak for mempool

From: Jack Wang I noticed kmemleak report memory leak when run create/stop md in a loop, backtrace: [<1ca975e7>] mempool_create_node+0x86/0xd0 [<95576bcd>] md_run+0x1057/0x1410 [md_mod] [<7b45c5fc>] do_md_run+0x15/0x130 [md_mod] [<1ede9ec0>

[PATCH] md: fix memleak for mempool

From: Jack Wang I noticed kmemleak report memory leak when run create/stop md in a loop, backtrace: [<1ca975e7>] mempool_create_node+0x86/0xd0 [<95576bcd>] md_run+0x1057/0x1410 [md_mod] [<7b45c5fc>] do_md_run+0x15/0x130 [md_mod] [<1ede9ec0>

[PATCH] lib: memcmp optimization

red that ~50% of the time was spend in memcmp() called from process_checks(). With this patch applied, it drops to 4% - 10%. Signed-off-by: Florian-Ewald Mueller [jwang: reformat the commit message] Signed-off-by: Jack Wang --- lib/string.c | 16 +++- 1 file changed, 15 insertions(+)

[PATCH] lib: memcmp optimization

red that ~50% of the time was spend in memcmp() called from process_checks(). With this patch applied, it drops to 4% - 10%. Signed-off-by: Florian-Ewald Mueller [jwang: reformat the commit message] Signed-off-by: Jack Wang --- lib/string.c | 16 +++- 1 file changed, 15 insertions(+)

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

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 mddev_suspend. and move mddev_resume after md_bitmap_destr

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

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 mddev_suspend. and move mddev_resume after md_bitmap_destr

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

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 mddev_suspend. and move mddev_resume after md_bitmap_destr

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

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 mddev_suspend. and move mddev_resume after md_bitmap_destr

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

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 mddev_suspend. and move mddev_resume after md_bitmap_destr

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

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 mddev_suspend. and move mddev_resume after md_bitmap_destr

Re: [PATCH] KVM: VMX: fixes for vmentry_l1d_flush module parameter

e just store the value and let > @@ -324,6 +327,9 @@ static int vmentry_l1d_flush_set(const char *s, const > struct kernel_param *kp) > > static int vmentry_l1d_flush_get(char *s, const struct kernel_param *kp) > { > + if (WARN_ON_ONCE(l1tf_vmx_mitigation >= > ARRAY_SIZE(vmentry_l1d_param))) > + return sprintf(s, "???\n"); > + > return sprintf(s, "%s\n", > vmentry_l1d_param[l1tf_vmx_mitigation].option); > } > > -- > 1.8.3.1 > Tested-by: Jack Wang Thanks, Jack

Re: [PATCH] KVM: VMX: fixes for vmentry_l1d_flush module parameter

e just store the value and let > @@ -324,6 +327,9 @@ static int vmentry_l1d_flush_set(const char *s, const > struct kernel_param *kp) > > static int vmentry_l1d_flush_get(char *s, const struct kernel_param *kp) > { > + if (WARN_ON_ONCE(l1tf_vmx_mitigation >= > ARRAY_SIZE(vmentry_l1d_param))) > + return sprintf(s, "???\n"); > + > return sprintf(s, "%s\n", > vmentry_l1d_param[l1tf_vmx_mitigation].option); > } > > -- > 1.8.3.1 > Tested-by: Jack Wang Thanks, Jack

[PATCH v2] block: ratelimite pr_err on IO path

From: Jack Wang <jinpu.w...@profitbricks.com> This avoid soft lockup below: [ 2328.328429] Call Trace: [ 2328.328433] vprintk_emit+0x229/0x2e0 [ 2328.328436] ? t10_pi_type3_verify_ip+0x20/0x20 [ 2328.328437] printk+0x52/0x6e [ 2328.328439] t10_pi_verify+0x9e/0xf0 [ 2328.

[PATCH v2] block: ratelimite pr_err on IO path

From: Jack Wang This avoid soft lockup below: [ 2328.328429] Call Trace: [ 2328.328433] vprintk_emit+0x229/0x2e0 [ 2328.328436] ? t10_pi_type3_verify_ip+0x20/0x20 [ 2328.328437] printk+0x52/0x6e [ 2328.328439] t10_pi_verify+0x9e/0xf0 [ 2328.328441] bio_integrity_process+0x12e/0x220

[PATCH] block: ratelimite pr_err on IO path

From: Jack Wang <jinpu.w...@profitbricks.com> This avoid soft lockup below: [ 2328.328429] Call Trace: [ 2328.328433] vprintk_emit+0x229/0x2e0 [ 2328.328436] ? t10_pi_type3_verify_ip+0x20/0x20 [ 2328.328437] printk+0x52/0x6e [ 2328.328439] t10_pi_verify+0x9e/0xf0 [ 2328.

[PATCH] block: ratelimite pr_err on IO path

From: Jack Wang This avoid soft lockup below: [ 2328.328429] Call Trace: [ 2328.328433] vprintk_emit+0x229/0x2e0 [ 2328.328436] ? t10_pi_type3_verify_ip+0x20/0x20 [ 2328.328437] printk+0x52/0x6e [ 2328.328439] t10_pi_verify+0x9e/0xf0 [ 2328.328441] bio_integrity_process+0x12e/0x220

Re: [PATCH v4 05/11] libsas: Use dynamic alloced work to avoid sas event lost

nregister_ports(struct sas_ha_struct *sas_ha) > sas_deform_port(sas_ha->sas_phy[i], 0); > > } > + > +const work_func_t sas_port_event_fns[PORT_NUM_EVENTS] = { > + [PORTE_BYTES_DMAED] = sas_porte_bytes_dmaed, > + [PORTE_BROADCAST_RCVD] = sas_porte_broadcast_rcvd, > + [PORTE_LINK_RESET_ERR] = sas_porte_link_reset_err, > + [PORTE_TIMER_EVENT] = sas_porte_timer_event, > + [PORTE_HARD_RESET] = sas_porte_hard_reset, > +}; > diff --git a/include/scsi/libsas.h b/include/scsi/libsas.h > index 99f32b5..c80321b 100644 > --- a/include/scsi/libsas.h > +++ b/include/scsi/libsas.h > @@ -292,6 +292,7 @@ struct asd_sas_port { > struct asd_sas_event { > struct sas_work work; > struct asd_sas_phy *phy; > + int event; > }; > > static inline struct asd_sas_event *to_asd_sas_event(struct work_struct > *work) > @@ -301,17 +302,20 @@ static inline struct asd_sas_event > *to_asd_sas_event(struct work_struct *work) > return ev; > } > > +static inline void INIT_SAS_EVENT(struct asd_sas_event *ev, void > (*fn)(struct work_struct *), > + struct asd_sas_phy *phy, int event) > +{ > + INIT_SAS_WORK(>work, fn); > + ev->phy = phy; > + ev->event = event; > +} > + > + > /* The phy pretty much is controlled by the LLDD. > * The class only reads those fields. > */ > struct asd_sas_phy { > /* private: */ > - struct asd_sas_event port_events[PORT_NUM_EVENTS]; > - struct asd_sas_event phy_events[PHY_NUM_EVENTS]; > - > - unsigned long port_events_pending; > - unsigned long phy_events_pending; > - > int error; > int suspended; > > -- > 2.5.0 > Looks good, thanks! Reviewed-by: Jack Wang <jinpu.w...@profitbricks.com>

Re: [PATCH v4 05/11] libsas: Use dynamic alloced work to avoid sas event lost

t; @@ -353,3 +343,11 @@ void sas_unregister_ports(struct sas_ha_struct *sas_ha) > sas_deform_port(sas_ha->sas_phy[i], 0); > > } > + > +const work_func_t sas_port_event_fns[PORT_NUM_EVENTS] = { > + [PORTE_BYTES_DMAED] = sas_porte_bytes_dmaed, > + [PORTE_BROADCAST_RCVD] = sas_porte_broadcast_rcvd, > + [PORTE_LINK_RESET_ERR] = sas_porte_link_reset_err, > + [PORTE_TIMER_EVENT] = sas_porte_timer_event, > + [PORTE_HARD_RESET] = sas_porte_hard_reset, > +}; > diff --git a/include/scsi/libsas.h b/include/scsi/libsas.h > index 99f32b5..c80321b 100644 > --- a/include/scsi/libsas.h > +++ b/include/scsi/libsas.h > @@ -292,6 +292,7 @@ struct asd_sas_port { > struct asd_sas_event { > struct sas_work work; > struct asd_sas_phy *phy; > + int event; > }; > > static inline struct asd_sas_event *to_asd_sas_event(struct work_struct > *work) > @@ -301,17 +302,20 @@ static inline struct asd_sas_event > *to_asd_sas_event(struct work_struct *work) > return ev; > } > > +static inline void INIT_SAS_EVENT(struct asd_sas_event *ev, void > (*fn)(struct work_struct *), > + struct asd_sas_phy *phy, int event) > +{ > + INIT_SAS_WORK(>work, fn); > + ev->phy = phy; > + ev->event = event; > +} > + > + > /* The phy pretty much is controlled by the LLDD. > * The class only reads those fields. > */ > struct asd_sas_phy { > /* private: */ > - struct asd_sas_event port_events[PORT_NUM_EVENTS]; > - struct asd_sas_event phy_events[PHY_NUM_EVENTS]; > - > - unsigned long port_events_pending; > - unsigned long phy_events_pending; > - > int error; > int suspended; > > -- > 2.5.0 > Looks good, thanks! Reviewed-by: Jack Wang

Re: [PATCH v4 07/11] libsas: make the event threshold configurable

0644 > --- a/include/scsi/libsas.h > +++ b/include/scsi/libsas.h > @@ -679,6 +679,7 @@ extern int sas_bios_param(struct scsi_device *, > sector_t capacity, int *hsc); > extern struct scsi_transport_template * > sas_domain_attach_transport(struct sas_domain_function_template *); > +extern struct device_attribute dev_attr_phy_event_threshold; > > int sas_discover_root_expander(struct domain_device *); > > -- > 2.5.0 > Looks good, thanks! Reviewed-by: Jack Wang <jinpu.w...@profitbricks.com>

Re: [PATCH v4 07/11] libsas: make the event threshold configurable

csi/libsas.h b/include/scsi/libsas.h > index 2fa0b13..08c1c32 100644 > --- a/include/scsi/libsas.h > +++ b/include/scsi/libsas.h > @@ -679,6 +679,7 @@ extern int sas_bios_param(struct scsi_device *, > sector_t capacity, int *hsc); > extern struct scsi_transport_template * > sas_domain_attach_transport(struct sas_domain_function_template *); > +extern struct device_attribute dev_attr_phy_event_threshold; > > int sas_discover_root_expander(struct domain_device *); > > -- > 2.5.0 > Looks good, thanks! Reviewed-by: Jack Wang

Re: Getting "Wrong diagnostic page; asked for 7 got 0" error message on HBA's virtual SES device

below > wrong error message even though vSES device has failed the command > with illegal request error message and it has not returned any wrong > diagnostic page. > > sdev_printk(KERN_ERR, sdev, > "Wrong diagnostic page; asked for %d got %u\n", > page_code, recv_page_code); > > Thanks, > Sreekanth Hi Sreekanth, To me, we should fix ses module to check 00h List of Supported Diagnostic Pages first before ask for 07h. Add James in CC. Cheers, Jack Wang

Re: Getting "Wrong diagnostic page; asked for 7 got 0" error message on HBA's virtual SES device

failed the command > with illegal request error message and it has not returned any wrong > diagnostic page. > > sdev_printk(KERN_ERR, sdev, > "Wrong diagnostic page; asked for %d got %u\n", > page_code, recv_page_code); > > Thanks, > Sreekanth Hi Sreekanth, To me, we should fix ses module to check 00h List of Supported Diagnostic Pages first before ask for 07h. Add James in CC. Cheers, Jack Wang

Re: [PATCH v2] blk: improve order of bio handling in generic_make_request()

On 10.03.2017 15:55, Mikulas Patocka wrote: > > > On Fri, 10 Mar 2017, Mike Snitzer wrote: > >> On Fri, Mar 10 2017 at 7:34am -0500, >> Lars Ellenberg wrote: >> --- a/block/blk-core.c +++ b/block/blk-core.c @@ -1975,7 +1975,14 @@

Re: [PATCH v2] blk: improve order of bio handling in generic_make_request()

On 10.03.2017 15:55, Mikulas Patocka wrote: > > > On Fri, 10 Mar 2017, Mike Snitzer wrote: > >> On Fri, Mar 10 2017 at 7:34am -0500, >> Lars Ellenberg wrote: >> --- a/block/blk-core.c +++ b/block/blk-core.c @@ -1975,7 +1975,14 @@ generic_make_request_checks(struct bio *bio)

Re: [PATCH] blk: improve order of bio handling in generic_make_request()

On 07.03.2017 16:46, Pavel Machek wrote: > On Mon 2017-03-06 10:43:59, Jack Wang wrote: >> >> >> On 06.03.2017 05:40, NeilBrown wrote: >>> On Fri, Mar 03 2017, Jack Wang wrote: >>>> >>>> Thanks Neil for pushing the fix. >>>> >

Re: [PATCH] blk: improve order of bio handling in generic_make_request()

On 07.03.2017 16:46, Pavel Machek wrote: > On Mon 2017-03-06 10:43:59, Jack Wang wrote: >> >> >> On 06.03.2017 05:40, NeilBrown wrote: >>> On Fri, Mar 03 2017, Jack Wang wrote: >>>> >>>> Thanks Neil for pushing the fix. >>>> >

Re: [PATCH] blk: improve order of bio handling in generic_make_request()

On 06.03.2017 21:18, Jens Axboe wrote: > On 03/05/2017 09:40 PM, NeilBrown wrote: >> On Fri, Mar 03 2017, Jack Wang wrote: >>> >>> Thanks Neil for pushing the fix. >>> >>> We can optimize generic_make_request a little bit: >>> - assig

Re: [PATCH] blk: improve order of bio handling in generic_make_request()

On 06.03.2017 21:18, Jens Axboe wrote: > On 03/05/2017 09:40 PM, NeilBrown wrote: >> On Fri, Mar 03 2017, Jack Wang wrote: >>> >>> Thanks Neil for pushing the fix. >>> >>> We can optimize generic_make_request a little bit: >>> - assig

Re: [PATCH] blk: improve order of bio handling in generic_make_request()

On 06.03.2017 05:40, NeilBrown wrote: > On Fri, Mar 03 2017, Jack Wang wrote: >> >> Thanks Neil for pushing the fix. >> >> We can optimize generic_make_request a little bit: >> - assign bio_list struct hold directly instead init and merge >> - remove duplic

Re: [PATCH] blk: improve order of bio handling in generic_make_request()

On 06.03.2017 05:40, NeilBrown wrote: > On Fri, Mar 03 2017, Jack Wang wrote: >> >> Thanks Neil for pushing the fix. >> >> We can optimize generic_make_request a little bit: >> - assign bio_list struct hold directly instead init and merge >> - remove duplic

Re: [PATCH] blk: improve order of bio handling in generic_make_request()

On 03.03.2017 06:14, NeilBrown wrote: > > [ Hi Jens, > you might have seen assorted email threads recently about > deadlocks, particular in dm-snap or md/raid1/10. Also about > the excess of rescuer threads. > I think a big part of the problem is my ancient improvement > to

Re: [PATCH] blk: improve order of bio handling in generic_make_request()

On 03.03.2017 06:14, NeilBrown wrote: > > [ Hi Jens, > you might have seen assorted email threads recently about > deadlocks, particular in dm-snap or md/raid1/10. Also about > the excess of rescuer threads. > I think a big part of the problem is my ancient improvement > to

Re: [dm-devel] [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion

ly waits, so - internal READ bios will not be submitted, thus freeze_array will never completes. To fix this, modify generic_make_request to always sort bio_list_on_stack first with lowest level, then higher, until same level. Sent to linux-raid mail list: https://marc.info/?l=linux-raid=148

Re: [dm-devel] [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion

tted, thus freeze_array will never completes. To fix this, modify generic_make_request to always sort bio_list_on_stack first with lowest level, then higher, until same level. Sent to linux-raid mail list: https://marc.info/?l=linux-raid=148232453107685=2 Suggested-by: NeilBrown Signed-off-by: Jack

Re: [PATCH/RFC] add "failfast" support for raid1/raid10.

Hi Neil, 2016-11-24 5:47 GMT+01:00 NeilBrown <ne...@suse.com>: > On Sat, Nov 19 2016, Jack Wang wrote: > >> 2016-11-18 6:16 GMT+01:00 NeilBrown <ne...@suse.com>: >>> Hi, >>> >>> I've been sitting on these patches for a while because although the

Re: [PATCH/RFC] add "failfast" support for raid1/raid10.

Hi Neil, 2016-11-24 5:47 GMT+01:00 NeilBrown : > On Sat, Nov 19 2016, Jack Wang wrote: > >> 2016-11-18 6:16 GMT+01:00 NeilBrown : >>> Hi, >>> >>> I've been sitting on these patches for a while because although they >>> solve a real probl

Re: [PATCH/RFC] add "failfast" support for raid1/raid10.

sk 0, wo:0, o:1, dev:ibnbd46 I tried to port you patch from SLES[1], with the patchset, it reduce the time to ~30 seconds. I'm happy to see this feature upstream :) I will test again this new patchset. Cheers, Jack Wang

Re: [PATCH/RFC] add "failfast" support for raid1/raid10.

dev:ibnbd46 I tried to port you patch from SLES[1], with the patchset, it reduce the time to ~30 seconds. I'm happy to see this feature upstream :) I will test again this new patchset. Cheers, Jack Wang

Re: [PATCH v2 2/8] IB/core: Replace semaphore sm_sem with completion

Hi Binoy, 2016-10-25 17:08 GMT+02:00 Binoy Jayan <binoy.ja...@linaro.org>: > On 25 October 2016 at 18:13, Jack Wang <xjtu...@gmail.com> wrote: >> Hi Binoy, >> >> snip >>> >>> port->ib_dev = device; >>>

Re: [PATCH v2 2/8] IB/core: Replace semaphore sm_sem with completion

Hi Binoy, 2016-10-25 17:08 GMT+02:00 Binoy Jayan : > On 25 October 2016 at 18:13, Jack Wang wrote: >> Hi Binoy, >> >> snip >>> >>> port->ib_dev = device; >>> port->port_num = port_num; >>> - sema_init(>sm_se

Re: [PATCH v2 2/8] IB/core: Replace semaphore sm_sem with completion

Hi Binoy, snip > > port->ib_dev = device; > port->port_num = port_num; > - sema_init(>sm_sem, 1); > + init_completion(>sm_comp); > + complete(>sm_comp); Why complete here? > mutex_init(>file_mutex); > INIT_LIST_HEAD(>file_list); > > -- KR,

Re: [PATCH v2 2/8] IB/core: Replace semaphore sm_sem with completion

Hi Binoy, snip > > port->ib_dev = device; > port->port_num = port_num; > - sema_init(>sm_sem, 1); > + init_completion(>sm_comp); > + complete(>sm_comp); Why complete here? > mutex_init(>file_mutex); > INIT_LIST_HEAD(>file_list); > > -- KR,

Re: [PATCH] pm80xx: Don't override ts->stat on IO_OPEN_CNX_ERROR_HW_RESOURCE_BUSY

ing ts->stat > to SAS_DEV_NO_RESPONSE. > > Signed-off-by: Johannes Thumshirn Thanks, please feel free to add: Acked-by: Jack Wang > --- > drivers/scsi/pm8001/pm8001_hwi.c | 1 + > drivers/scsi/pm8001/pm80xx_hwi.c | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/drivers/

Re: [PATCH] pm80xx: Don't override ts-stat on IO_OPEN_CNX_ERROR_HW_RESOURCE_BUSY

to SAS_DEV_NO_RESPONSE. Signed-off-by: Johannes Thumshirn jthumsh...@suse.de Thanks, please feel free to add: Acked-by: Jack Wang jinpu.w...@profitbricks.com --- drivers/scsi/pm8001/pm8001_hwi.c | 1 + drivers/scsi/pm8001/pm80xx_hwi.c | 1 + 2 files changed, 2 insertions(+) diff --git

Re: [PATCH v2 RESEND 18/23] pm8001: Use pci_enable_msix_exact() instead of pci_enable_msix()

Hi Alex, Looks Ok for me. Please feel free to add my: Reviewed-by: Jack Wang Thanks, Jack 2014-07-26 10:33 GMT+02:00 Alexander Gordeev : > On Wed, Jul 16, 2014 at 08:05:22PM +0200, Alexander Gordeev wrote: >> As result of deprecation of MSI-X/MSI enablement functions >>

Re: [PATCH v2 RESEND 18/23] pm8001: Use pci_enable_msix_exact() instead of pci_enable_msix()

Hi Alex, Looks Ok for me. Please feel free to add my: Reviewed-by: Jack Wang xjtu...@gmail.com Thanks, Jack 2014-07-26 10:33 GMT+02:00 Alexander Gordeev agord...@redhat.com: On Wed, Jul 16, 2014 at 08:05:22PM +0200, Alexander Gordeev wrote: As result of deprecation of MSI-X/MSI enablement

Re: [PATCH] scsi: pm8001: pm80xx_hwi.c: Cleaning up variable is set more than once

Thanks Rickard, >From my point of view, looks good, but I'd like to get review from Anand (cc-ed). Anand, could you share your opinion? Regards, Jack On 06/25/2014 04:01 PM, Rickard Strandqvist wrote: > A struct member variable is set to different values without having used in > between. > >

Re: [PATCH] scsi: pm8001: pm80xx_hwi.c: Cleaning up uninitialized variables

Looks good, thanks Rickard. Acked-by: Jack Wang On 06/01/2014 03:13 PM, Rickard Strandqvist wrote: > There is a risk that the variable will be used without being initialized. > > This was largely found by using a static code analysis program called > cppcheck. > > Sign

Re: [PATCH] scsi: pm8001: pm80xx_hwi.c: Cleaning up uninitialized variables

Looks good, thanks Rickard. Acked-by: Jack Wang xjtu...@gmail.com On 06/01/2014 03:13 PM, Rickard Strandqvist wrote: There is a risk that the variable will be used without being initialized. This was largely found by using a static code analysis program called cppcheck. Signed-off

Re: [PATCH] scsi: pm8001: pm80xx_hwi.c: Cleaning up variable is set more than once

Thanks Rickard, From my point of view, looks good, but I'd like to get review from Anand (cc-ed). Anand, could you share your opinion? Regards, Jack On 06/25/2014 04:01 PM, Rickard Strandqvist wrote: A struct member variable is set to different values without having used in between. This

Re: [PATCH 17/22] pm8001: Use pci_enable_msix_range()

dler_msix, flag, > + intr_drvname[i], &(pm8001_ha->irq_vector[i])); > + if (rc) { > + for (j = 0; j < i; j++) { > + free_irq(pm8001_ha->msix_entries[j].vector, > &(pm8001_ha->irq_vec

Re: [PATCH 16/22] pm8001: Fix invalid success return when request_irq() failed

free_irq( > pm8001_ha->msix_entries[j].vector, > Thanks, looks fine. Acked-by: Jack Wang -- 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/

Re: [PATCH 16/22] pm8001: Fix invalid success return when request_irq() failed

-by: Jack Wang xjtu...@gmail.com -- 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/

Re: [PATCH 17/22] pm8001: Use pci_enable_msix_range()

; } + pci_disable_msix(pm8001_ha-pdev); + break; } } + return rc; } #endif Thanks, looks fine. Acked-by: Jack Wang xjtu...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body

Re: [STABLE] find missing bug fixes in a stable kernel

On 01/13/2014 08:28 AM, Li Zefan wrote: > We have several long-term and extended stable kernels, and it's possible > that a bug fix is in some stable versions but is missing in some other > versions, so I've written a script to find out those fixes. > > Take 3.4.xx and 3.2.xx for example. If a

Re: [STABLE] find missing bug fixes in a stable kernel

On 01/13/2014 08:28 AM, Li Zefan wrote: We have several long-term and extended stable kernels, and it's possible that a bug fix is in some stable versions but is missing in some other versions, so I've written a script to find out those fixes. Take 3.4.xx and 3.2.xx for example. If a bug fix

Re: [BUG]NULL pointer dereference at 0000000000000008 __blkdev_put+0x17f/0x1d0

On 01/04/2014 07:09 AM, Al Viro wrote: > On Thu, Jan 02, 2014 at 10:36:30AM +0100, Jack Wang wrote: > >>> Bug happened at line 1486, looks disk->fops is NULL here for some >>> reason, is it reasonable to add a check like: >>> >>> if

Re: [BUG]NULL pointer dereference at 0000000000000008 __blkdev_put+0x17f/0x1d0

On 01/04/2014 07:09 AM, Al Viro wrote: On Thu, Jan 02, 2014 at 10:36:30AM +0100, Jack Wang wrote: Bug happened at line 1486, looks disk-fops is NULL here for some reason, is it reasonable to add a check like: if (disk-fops) if (disk-fops-release) ret = disk-fops-release

Re: [BUG]NULL pointer dereference at 0000000000000008 __blkdev_put+0x17f/0x1d0

On 12/30/2013 04:55 PM, Jack Wang wrote: > Hi, > > We saw NULL pointer dereference below: > > Dec 28 16:24:26 server kernel: [979193.076399] BUG: unable to handle > kernel NULL pointer dereference at 0008 > Dec 28 16:24:26 server kernel: [979193.076401] IP: []

Re: [BUG]NULL pointer dereference at 0000000000000008 __blkdev_put+0x17f/0x1d0

On 12/30/2013 04:55 PM, Jack Wang wrote: Hi, We saw NULL pointer dereference below: Dec 28 16:24:26 server kernel: [979193.076399] BUG: unable to handle kernel NULL pointer dereference at 0008 Dec 28 16:24:26 server kernel: [979193.076401] IP: [8116952f] __blkdev_put

[BUG]NULL pointer dereference at 0000000000000008 __blkdev_put+0x17f/0x1d0

Hi, We saw NULL pointer dereference below: Dec 28 16:24:26 server kernel: [979193.076399] BUG: unable to handle kernel NULL pointer dereference at 0008 Dec 28 16:24:26 server kernel: [979193.076401] IP: [] __blkdev_put+0x17f/0x1d0 Dec 28 16:24:26 server kernel: [979193.076408] PGD

[BUG]NULL pointer dereference at 0000000000000008 __blkdev_put+0x17f/0x1d0

Hi, We saw NULL pointer dereference below: Dec 28 16:24:26 server kernel: [979193.076399] BUG: unable to handle kernel NULL pointer dereference at 0008 Dec 28 16:24:26 server kernel: [979193.076401] IP: [8116952f] __blkdev_put+0x17f/0x1d0 Dec 28 16:24:26 server kernel:

Re: [PATCH 092/104] mm: fix aio performance regression for database caused by THP

On 09/30/2013 12:11 PM, Luis Henriques wrote: > 3.5.7.22 -stable review patch. If anyone has any objections, please let me > know. > > -- > > From: Khalid Aziz > > commit 7cb2ef56e6a8b7b368b2e883a0a47d02fed66911 upstream. > > I am working with a tool that simulates oracle

Re: [PATCH 092/104] mm: fix aio performance regression for database caused by THP

On 09/30/2013 12:11 PM, Luis Henriques wrote: 3.5.7.22 -stable review patch. If anyone has any objections, please let me know. -- From: Khalid Aziz khalid.a...@oracle.com commit 7cb2ef56e6a8b7b368b2e883a0a47d02fed66911 upstream. I am working with a tool that

Re: Drivers: scsi: FLUSH timeout

On 09/21/2013 07:24 AM, KY Srinivasan wrote: > > >> -Original Message- >> From: Greg KH [mailto:gre...@linuxfoundation.org] >> Sent: Friday, September 20, 2013 1:32 PM >> To: KY Srinivasan >> Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; >> oher...@suse.com;

Re: Drivers: scsi: FLUSH timeout

On 09/21/2013 07:24 AM, KY Srinivasan wrote: -Original Message- From: Greg KH [mailto:gre...@linuxfoundation.org] Sent: Friday, September 20, 2013 1:32 PM To: KY Srinivasan Cc: linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; oher...@suse.com; jbottom...@parallels.com;

Re: [PATCH 8/9] scsi/pm8001: use pdev->pm_cap instead of pci_find_capability(..,PCI_CAP_ID_PM)

On 06/18/2013 10:23 AM, Yijing Wang wrote: > Pci core has been saved pm cap register offset by pdev->pm_cap in > pci_pm_init() > in init path. So we can use pdev->pm_cap instead of using > pci_find_capability(pdev, PCI_CAP_ID_PM) for better performance and > simplified code. > I think Lindar

Re: [PATCH 8/9] scsi/pm8001: use pdev-pm_cap instead of pci_find_capability(..,PCI_CAP_ID_PM)

On 06/18/2013 10:23 AM, Yijing Wang wrote: Pci core has been saved pm cap register offset by pdev-pm_cap in pci_pm_init() in init path. So we can use pdev-pm_cap instead of using pci_find_capability(pdev, PCI_CAP_ID_PM) for better performance and simplified code. I think Lindar already

kernel tried to execute NX-protected page - exploit attempt? (uid: 998)

Hi all, We saw below bug in our production. Kernel is linux 3.4.23, as I know it means control was transferred to a data page. This could happen because of a stack overflow (overwrite return address with bogus pointer into data pages), or by calling a function pointer which isn't pointing where

kernel tried to execute NX-protected page - exploit attempt? (uid: 998)

Hi all, We saw below bug in our production. Kernel is linux 3.4.23, as I know it means control was transferred to a data page. This could happen because of a stack overflow (overwrite return address with bogus pointer into data pages), or by calling a function pointer which isn't pointing where

RE: How to online remove an error scsi disk from the system?

On 02/01/2013 04:50 PM, Jack Wang wrote: > Hi All, > In our product system, we have several sata disks attached to one > machine. So when one of the disk fails, the jbd2(yes, we use ext4) > will hang forever and we will get something in /var/log/messages like below. >

RE: How to online remove an error scsi disk from the system?

he end_io can be called accordingly? Am I missing something here? Thanks, Tao [Jack Wang] Hi Tao, Have you tried: echo 1 > /sys/block/sdv/device/delete echo "- - -" > /sys/class/scsi_host/host another way is : find out which phy the disk attached to and: echo 1 > /sys/class/sa

RE: How to online remove an error scsi disk from the system?

accordingly? Am I missing something here? Thanks, Tao [Jack Wang] Hi Tao, Have you tried: echo 1 /sys/block/sdv/device/delete echo - - - /sys/class/scsi_host/host another way is : find out which phy the disk attached to and: echo 1 /sys/class/sas_phy/phy-x:x:x/link_reset Jack

RE: How to online remove an error scsi disk from the system?

On 02/01/2013 04:50 PM, Jack Wang wrote: Hi All, In our product system, we have several sata disks attached to one machine. So when one of the disk fails, the jbd2(yes, we use ext4) will hang forever and we will get something in /var/log/messages like below. It seems to me

RE: mvsas regression since 3.5

[Jack Wang] Do you see bug51881, which may relate to what you see https://bugzilla.kernel.org/show_bug.cgi?id=51881 btw: also correct Dan's mail address. I'm using Asus PIKE 6480 SAS card, whose chipset is "RAID bus controller: Marvell Technology Group Ltd. MV64460/64461/64462 S

RE: mvsas regression since 3.5

[Jack Wang] Do you see bug51881, which may relate to what you see https://bugzilla.kernel.org/show_bug.cgi?id=51881 btw: also correct Dan's mail address. I'm using Asus PIKE 6480 SAS card, whose chipset is RAID bus controller: Marvell Technology Group Ltd. MV64460/64461/64462 System

Re: [PATCH 00/26] AIO performance improvements/cleanups, v2

2012/12/14 Jens Axboe : > On Mon, Dec 03 2012, Kent Overstreet wrote: >> Last posting: http://thread.gmane.org/gmane.linux.kernel.aio.general/3169 >> >> Changes since the last posting should all be noted in the individual >> patch descriptions. >> >> * Zach pointed out the aio_read_evt() patch

Re: [PATCH 00/26] AIO performance improvements/cleanups, v2

2012/12/14 Jens Axboe jax...@fusionio.com: On Mon, Dec 03 2012, Kent Overstreet wrote: Last posting: http://thread.gmane.org/gmane.linux.kernel.aio.general/3169 Changes since the last posting should all be noted in the individual patch descriptions. * Zach pointed out the aio_read_evt()