[PATCH] staging:xgifb:remove unused code

[dingxiang]

The variable data is assigned but never used in rest code.

Signed-off-by: Ding Xiang 
---
 drivers/staging/xgifb/vb_setmode.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/xgifb/vb_setmode.c 
b/drivers/staging/xgifb/vb_setmode.c
index 50c8ea4..71bb9ca 100644
--- a/drivers/staging/xgifb/vb_setmode.c
+++ b/drivers/staging/xgifb/vb_setmode.c
@@ -727,7 +727,6 @@ static void XGI_SetCRT1DE(unsigned short ModeIdIndex,
tempax |= 0x40;
 
 	xgifb_reg_and_or(pVBInfo->P3d4, 0x07, ~0x42, tempax);

-   data = xgifb_reg_get(pVBInfo->P3d4, 0x07);
tempax = 0;
 
 	if (tempbx & 0x04)

--
2.5.0


.

[PATCH] staging:xgifb:remove unused code

[dingxiang]

The variable data is assigned but never used in rest code.

Signed-off-by: Ding Xiang 
---
 drivers/staging/xgifb/vb_setmode.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/xgifb/vb_setmode.c 
b/drivers/staging/xgifb/vb_setmode.c
index 50c8ea4..71bb9ca 100644
--- a/drivers/staging/xgifb/vb_setmode.c
+++ b/drivers/staging/xgifb/vb_setmode.c
@@ -727,7 +727,6 @@ static void XGI_SetCRT1DE(unsigned short ModeIdIndex,
tempax |= 0x40;
 
 	xgifb_reg_and_or(pVBInfo->P3d4, 0x07, ~0x42, tempax);

-   data = xgifb_reg_get(pVBInfo->P3d4, 0x07);
tempax = 0;
 
 	if (tempbx & 0x04)

--
2.5.0


.

Re: [PATCH V2 resend] libata:fix kernel panic when hotplug

[dingxiang]

Hi,All

Hello,

On Mon, Jun 20, 2016 at 06:46:55PM -0700, Dan Williams wrote:

On Mon, Jun 20, 2016 at 6:22 PM, Martin K. Petersen
 wrote:

"Tejun" == Tejun Heo  writes:

In fact,we don't need libata to deal with hotplug in sas environment.
So we can't run ata hotplug task when ata port is sas host.

Tejun> Martin, can you please confirm whether the above is true.  If so,
Tejun> I'll route the patch through libata w/ stable cc'd.

Not exactly a libsas expert. James? Dan?

While it is true that libsas itself handles adding / removing devices
we have historically avoided this conflict because
ATA_PFLAG_SCSI_HOTPLUG is never set for libsas ata_ports.  So the bug
/ behavior change is that  ATA_PFLAG_SCSI_HOTPLUG gets set in the
first place.  Ignoring it is a band-aid / not the real fix afaics.

I see.  I'll hold off for now then.  Ding Xiang, can you find out
where that flag is getting set?

Thanks!

There are two places will set flag ATA_PFLAG_SCSI_HOTPLUG in libata-eh.c.
I think both places should  be protected. Here is the suggestion.
Thanks~

diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 61dc7a9..2bee041 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -1385,7 +1385,8 @@ void ata_eh_detach_dev(struct ata_device *dev)

if (ata_scsi_offline_dev(dev)) {
dev->flags |= ATA_DFLAG_DETACHED;
-   ap->pflags |= ATA_PFLAG_SCSI_HOTPLUG;
+   if (!(ap->pflags & ATA_FLAG_SAS_HOST))
+   ap->pflags |= ATA_PFLAG_SCSI_HOTPLUG;
}

/* clear per-dev EH info */
@@ -3299,7 +3300,8 @@ static int ata_eh_revalidate_and_attach(struct 
ata_link *link,

}

spin_lock_irqsave(ap->lock, flags);
-   ap->pflags |= ATA_PFLAG_SCSI_HOTPLUG;
+   if (!(ap->pflags & ATA_FLAG_SAS_HOST))
+   ap->pflags |= ATA_PFLAG_SCSI_HOTPLUG;
spin_unlock_irqrestore(ap->lock, flags);

/* new device discovered, configure xfermode */

Re: [PATCH V2 resend] libata:fix kernel panic when hotplug

[dingxiang]

Hi,All

Hello,

On Mon, Jun 20, 2016 at 06:46:55PM -0700, Dan Williams wrote:

On Mon, Jun 20, 2016 at 6:22 PM, Martin K. Petersen
 wrote:

"Tejun" == Tejun Heo  writes:

In fact,we don't need libata to deal with hotplug in sas environment.
So we can't run ata hotplug task when ata port is sas host.

Tejun> Martin, can you please confirm whether the above is true.  If so,
Tejun> I'll route the patch through libata w/ stable cc'd.

Not exactly a libsas expert. James? Dan?

While it is true that libsas itself handles adding / removing devices
we have historically avoided this conflict because
ATA_PFLAG_SCSI_HOTPLUG is never set for libsas ata_ports.  So the bug
/ behavior change is that  ATA_PFLAG_SCSI_HOTPLUG gets set in the
first place.  Ignoring it is a band-aid / not the real fix afaics.

I see.  I'll hold off for now then.  Ding Xiang, can you find out
where that flag is getting set?

Thanks!

There are two places will set flag ATA_PFLAG_SCSI_HOTPLUG in libata-eh.c.
I think both places should  be protected. Here is the suggestion.
Thanks~

diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 61dc7a9..2bee041 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -1385,7 +1385,8 @@ void ata_eh_detach_dev(struct ata_device *dev)

if (ata_scsi_offline_dev(dev)) {
dev->flags |= ATA_DFLAG_DETACHED;
-   ap->pflags |= ATA_PFLAG_SCSI_HOTPLUG;
+   if (!(ap->pflags & ATA_FLAG_SAS_HOST))
+   ap->pflags |= ATA_PFLAG_SCSI_HOTPLUG;
}

/* clear per-dev EH info */
@@ -3299,7 +3300,8 @@ static int ata_eh_revalidate_and_attach(struct 
ata_link *link,

}

spin_lock_irqsave(ap->lock, flags);
-   ap->pflags |= ATA_PFLAG_SCSI_HOTPLUG;
+   if (!(ap->pflags & ATA_FLAG_SAS_HOST))
+   ap->pflags |= ATA_PFLAG_SCSI_HOTPLUG;
spin_unlock_irqrestore(ap->lock, flags);

/* new device discovered, configure xfermode */

[PATCH V2 resend] libata:fix kernel panic when hotplug

[DingXiang]

In normal condition,if we use sas protocol and hotplug a
sata disk on a port,the sas driver will send event
"PORTE_BYTES_DMAED" and call function "sas_porte_bytes_dmaed".
But if a sata disk is run io and unplug it,then plug a new
sata disk,this operation may cause a kernel panic like this:

[ 2366.923208] Unable to handle kernel NULL pointer dereference
at virtual address 07b8
...
[ 2368.766334] Call trace:
[ 2368.781712] [] sas_find_dev_by_rphy+0x48/0x118
[ 2368.800394] [] sas_target_alloc+0x28/0x98
[ 2368.817975] [] scsi_alloc_target+0x248/0x308
[ 2368.835570] [] __scsi_add_device+0xb8/0x160
[ 2368.853034] [] ata_scsi_scan_host+0x190/0x230
[ 2368.871614] [] ata_scsi_hotplug+0xc8/0xe8
[ 2368.889152] [] process_one_work+0x164/0x438
[ 2368.908003] [] worker_thread+0x144/0x4b0
[ 2368.924613] [] kthread+0xfc/0x110

This because "dev_to_shost" in "sas_find_dev_by_rphy" return
a NULL point,and SHOST_TO_SAS_HA used it,so kernel panic happened.

why did dev_to_shost return a NULL point?
Because in "__scsi_add_device" ,
struct device *parent = >shost_gendev,
and in "scsi_alloc_target", "*parent" is assigned to
"starget->dev.parent",then "sas_target_alloc" will get
"struct sas_rphy" according "starget->dev.parent", and in
"sas_find_dev_by_rphy" , we will get "struct Scsi_Host *shost"
according "rphy->dev.parent",we will find that
rphy->dev.parent = shost->shost_gendev.parent, and shost_gendev.parent
is "ap->tdev",there is no parent any more,so "dev_to_shost"
return a NULL point.

when the panic will happen?
When libata is handling error,and add hotplug_task to workqueue,
if a new sata disk pluged at this moment,the libata hotplug task
will run and panic will happen.

In fact,we don't need libata to deal with hotplug in sas environment.
So we can't run ata hotplug task when ata port is sas host.

Signed-off-by: Ding Xiang 
---
 drivers/ata/libata-eh.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 61dc7a9..4428a7c 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -816,7 +816,8 @@ void ata_scsi_port_error_handler(struct Scsi_Host *host, 
struct ata_port *ap)
 
if (ap->pflags & ATA_PFLAG_LOADING)
ap->pflags &= ~ATA_PFLAG_LOADING;
-   else if (ap->pflags & ATA_PFLAG_SCSI_HOTPLUG)
+   else if ((ap->pflags & ATA_PFLAG_SCSI_HOTPLUG) &&
+!(ap->pflags & ATA_FLAG_SAS_HOST))
schedule_delayed_work(>hotplug_task, 0);
 
if (ap->pflags & ATA_PFLAG_RECOVERED)
-- 
2.5.0

[PATCH V2 resend] libata:fix kernel panic when hotplug

[DingXiang]

In normal condition,if we use sas protocol and hotplug a
sata disk on a port,the sas driver will send event
"PORTE_BYTES_DMAED" and call function "sas_porte_bytes_dmaed".
But if a sata disk is run io and unplug it,then plug a new
sata disk,this operation may cause a kernel panic like this:

[ 2366.923208] Unable to handle kernel NULL pointer dereference
at virtual address 07b8
...
[ 2368.766334] Call trace:
[ 2368.781712] [] sas_find_dev_by_rphy+0x48/0x118
[ 2368.800394] [] sas_target_alloc+0x28/0x98
[ 2368.817975] [] scsi_alloc_target+0x248/0x308
[ 2368.835570] [] __scsi_add_device+0xb8/0x160
[ 2368.853034] [] ata_scsi_scan_host+0x190/0x230
[ 2368.871614] [] ata_scsi_hotplug+0xc8/0xe8
[ 2368.889152] [] process_one_work+0x164/0x438
[ 2368.908003] [] worker_thread+0x144/0x4b0
[ 2368.924613] [] kthread+0xfc/0x110

This because "dev_to_shost" in "sas_find_dev_by_rphy" return
a NULL point,and SHOST_TO_SAS_HA used it,so kernel panic happened.

why did dev_to_shost return a NULL point?
Because in "__scsi_add_device" ,
struct device *parent = >shost_gendev,
and in "scsi_alloc_target", "*parent" is assigned to
"starget->dev.parent",then "sas_target_alloc" will get
"struct sas_rphy" according "starget->dev.parent", and in
"sas_find_dev_by_rphy" , we will get "struct Scsi_Host *shost"
according "rphy->dev.parent",we will find that
rphy->dev.parent = shost->shost_gendev.parent, and shost_gendev.parent
is "ap->tdev",there is no parent any more,so "dev_to_shost"
return a NULL point.

when the panic will happen?
When libata is handling error,and add hotplug_task to workqueue,
if a new sata disk pluged at this moment,the libata hotplug task
will run and panic will happen.

In fact,we don't need libata to deal with hotplug in sas environment.
So we can't run ata hotplug task when ata port is sas host.

Signed-off-by: Ding Xiang 
---
 drivers/ata/libata-eh.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 61dc7a9..4428a7c 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -816,7 +816,8 @@ void ata_scsi_port_error_handler(struct Scsi_Host *host, 
struct ata_port *ap)
 
if (ap->pflags & ATA_PFLAG_LOADING)
ap->pflags &= ~ATA_PFLAG_LOADING;
-   else if (ap->pflags & ATA_PFLAG_SCSI_HOTPLUG)
+   else if ((ap->pflags & ATA_PFLAG_SCSI_HOTPLUG) &&
+!(ap->pflags & ATA_FLAG_SAS_HOST))
schedule_delayed_work(>hotplug_task, 0);
 
if (ap->pflags & ATA_PFLAG_RECOVERED)
-- 
2.5.0

[PATCH V2] libata:fix kernel panic when hotplug

[DingXiang]

From: Ding Xiang 

In normal condition,if we use sas protocol and hotplug a
sata disk on a port,the sas driver will send event
"PORTE_BYTES_DMAED" and call function "sas_porte_bytes_dmaed".
But if a sata disk is run io and unplug it,then plug a new
sata disk,this operation may cause a kernel panic like this:

[ 2366.923208] Unable to handle kernel NULL pointer dereference
at virtual address 07b8
[ 2366.949253] pgd = ffc00121d000
[ 2366.971164] [07b8] *pgd=0027df893003, *pud=0027df893003,
*pmd=0027df894003, *pte=00606d000707
[ 2367.022822] Internal error: Oops: 9605 [#1] SMP
[ 2367.048490] Modules linked in: dm_mirror(E) dm_region_hash(E) dm_log(E)
dm_mod(E) crc32_arm64(E) aes_ce_blk(E) ablk_helper(E) cry ptd(E)
aes_ce_cipher(E) ghash_ce(E) sha2_ce(E) sha1_ce(E) ses(E) enclosure(E)
shpchp(E) marvell(E)
[ 2367.144808] CPU: 16 PID: 710 Comm: kworker/16:1 Tainted: GE
4.1.23-next.aarch64 #1
[ 2367.180161] Hardware name: Huawei Taishan 2280 /BC11SPCC,
BIOS 1.28 05/14/2016
[ 2367.213305] Workqueue: events ata_scsi_hotplug
[ 2367.244296] task: ffe7db9b5e00 ti: ffe7db1a
task.ti: ffe7db1a
[ 2367.279949] PC is at sas_find_dev_by_rphy+0x48/0x118
[ 2367.312045] LR is at sas_find_dev_by_rphy+0x40/0x118
[ 2367.341970] pc : [] lr : []
pstate: 0145
...
[ 2368.766334] Call trace:
[ 2368.781712] [] sas_find_dev_by_rphy+0x48/0x118
[ 2368.800394] [] sas_target_alloc+0x28/0x98
[ 2368.817975] [] scsi_alloc_target+0x248/0x308
[ 2368.835570] [] __scsi_add_device+0xb8/0x160
[ 2368.853034] [] ata_scsi_scan_host+0x190/0x230
[ 2368.871614] [] ata_scsi_hotplug+0xc8/0xe8
[ 2368.889152] [] process_one_work+0x164/0x438
[ 2368.908003] [] worker_thread+0x144/0x4b0
[ 2368.924613] [] kthread+0xfc/0x110
[ 2368.940923] Code: aa1303e0 97ff5deb 3480 d1082273 (f943de76)

This because "dev_to_shost" in "sas_find_dev_by_rphy" return
a NULL point,and SHOST_TO_SAS_HA used it,so kernel panic happed.

why dev_to_shost return a NULL point?
Because in "__scsi_add_device" ,
struct device *parent = >shost_gendev,
and in "scsi_alloc_target", "*parent" is assigned to
"starget->dev.parent",then "sas_target_alloc" will get
"struct sas_rphy" according "starget->dev.parent", and in
"sas_find_dev_by_rphy" , we will get "struct Scsi_Host *shost"
according "rphy->dev.parent",we will find that
rphy->dev.parent = shost->shost_gendev.parent, and shost_gendev.parent
is "ap->tdev",there is no parent any more,so "dev_to_shost"
return a NULL point.

when the panic will happen?
When libata is handling error,and add hotplug_task to workqueue,
if a new sata disk pluged at this moment,the libata hotplug task
will run and panic will happen.

In fact,we don't need libata to deal with hotplug in sas environment.
So we can't run ata hotplug task when ata port is sas host.

Signed-off-by: Ding Xiang 
---
 drivers/ata/libata-eh.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 61dc7a9..4428a7c 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -816,7 +816,8 @@ void ata_scsi_port_error_handler(struct Scsi_Host *host, 
struct ata_port *ap)
 
if (ap->pflags & ATA_PFLAG_LOADING)
ap->pflags &= ~ATA_PFLAG_LOADING;
-   else if (ap->pflags & ATA_PFLAG_SCSI_HOTPLUG)
+   else if ((ap->pflags & ATA_PFLAG_SCSI_HOTPLUG) &&
+!(ap->pflags & ATA_PFLAG_SAS_HOST))
schedule_delayed_work(>hotplug_task, 0);
 
if (ap->pflags & ATA_PFLAG_RECOVERED)
-- 
2.5.0

[PATCH V2] libata:fix kernel panic when hotplug

[DingXiang]

From: Ding Xiang 

In normal condition,if we use sas protocol and hotplug a
sata disk on a port,the sas driver will send event
"PORTE_BYTES_DMAED" and call function "sas_porte_bytes_dmaed".
But if a sata disk is run io and unplug it,then plug a new
sata disk,this operation may cause a kernel panic like this:

[ 2366.923208] Unable to handle kernel NULL pointer dereference
at virtual address 07b8
[ 2366.949253] pgd = ffc00121d000
[ 2366.971164] [07b8] *pgd=0027df893003, *pud=0027df893003,
*pmd=0027df894003, *pte=00606d000707
[ 2367.022822] Internal error: Oops: 9605 [#1] SMP
[ 2367.048490] Modules linked in: dm_mirror(E) dm_region_hash(E) dm_log(E)
dm_mod(E) crc32_arm64(E) aes_ce_blk(E) ablk_helper(E) cry ptd(E)
aes_ce_cipher(E) ghash_ce(E) sha2_ce(E) sha1_ce(E) ses(E) enclosure(E)
shpchp(E) marvell(E)
[ 2367.144808] CPU: 16 PID: 710 Comm: kworker/16:1 Tainted: GE
4.1.23-next.aarch64 #1
[ 2367.180161] Hardware name: Huawei Taishan 2280 /BC11SPCC,
BIOS 1.28 05/14/2016
[ 2367.213305] Workqueue: events ata_scsi_hotplug
[ 2367.244296] task: ffe7db9b5e00 ti: ffe7db1a
task.ti: ffe7db1a
[ 2367.279949] PC is at sas_find_dev_by_rphy+0x48/0x118
[ 2367.312045] LR is at sas_find_dev_by_rphy+0x40/0x118
[ 2367.341970] pc : [] lr : []
pstate: 0145
...
[ 2368.766334] Call trace:
[ 2368.781712] [] sas_find_dev_by_rphy+0x48/0x118
[ 2368.800394] [] sas_target_alloc+0x28/0x98
[ 2368.817975] [] scsi_alloc_target+0x248/0x308
[ 2368.835570] [] __scsi_add_device+0xb8/0x160
[ 2368.853034] [] ata_scsi_scan_host+0x190/0x230
[ 2368.871614] [] ata_scsi_hotplug+0xc8/0xe8
[ 2368.889152] [] process_one_work+0x164/0x438
[ 2368.908003] [] worker_thread+0x144/0x4b0
[ 2368.924613] [] kthread+0xfc/0x110
[ 2368.940923] Code: aa1303e0 97ff5deb 3480 d1082273 (f943de76)

This because "dev_to_shost" in "sas_find_dev_by_rphy" return
a NULL point,and SHOST_TO_SAS_HA used it,so kernel panic happed.

why dev_to_shost return a NULL point?
Because in "__scsi_add_device" ,
struct device *parent = >shost_gendev,
and in "scsi_alloc_target", "*parent" is assigned to
"starget->dev.parent",then "sas_target_alloc" will get
"struct sas_rphy" according "starget->dev.parent", and in
"sas_find_dev_by_rphy" , we will get "struct Scsi_Host *shost"
according "rphy->dev.parent",we will find that
rphy->dev.parent = shost->shost_gendev.parent, and shost_gendev.parent
is "ap->tdev",there is no parent any more,so "dev_to_shost"
return a NULL point.

when the panic will happen?
When libata is handling error,and add hotplug_task to workqueue,
if a new sata disk pluged at this moment,the libata hotplug task
will run and panic will happen.

In fact,we don't need libata to deal with hotplug in sas environment.
So we can't run ata hotplug task when ata port is sas host.

Signed-off-by: Ding Xiang 
---
 drivers/ata/libata-eh.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 61dc7a9..4428a7c 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -816,7 +816,8 @@ void ata_scsi_port_error_handler(struct Scsi_Host *host, 
struct ata_port *ap)
 
if (ap->pflags & ATA_PFLAG_LOADING)
ap->pflags &= ~ATA_PFLAG_LOADING;
-   else if (ap->pflags & ATA_PFLAG_SCSI_HOTPLUG)
+   else if ((ap->pflags & ATA_PFLAG_SCSI_HOTPLUG) &&
+!(ap->pflags & ATA_PFLAG_SAS_HOST))
schedule_delayed_work(>hotplug_task, 0);
 
if (ap->pflags & ATA_PFLAG_RECOVERED)
-- 
2.5.0

[PATCH resend] libata:fix kernel panic when hotplug

[DingXiang]

From: Miao Xie 

In normal condition,if we use sas protocol and hotplug a sata disk on a port,
the sas driver will send event "PORTE_BYTES_DMAED" and call function 
"sas_porte_bytes_dmaed".
But if a sata disk is run io and unplug it,then plug a new sata disk,this 
operation may cause
a kernel panic like this:
[ 2366.923208] Unable to handle kernel NULL pointer dereference at virtual 
address 07b8
[ 2366.949253] pgd = ffc00121d000
[ 2366.971164] [07b8] *pgd=0027df893003, *pud=0027df893003, 
*pmd=0027df894003, *pte=00606d000707
[ 2367.022822] Internal error: Oops: 9605 [#1] SMP
[ 2367.048490] Modules linked in: dm_mirror(E) dm_region_hash(E) dm_log(E) 
dm_mod(E) crc32_arm64(E) aes_ce_blk(E) ablk_helper(E) cryptd(E) 
aes_ce_cipher(E) ghash_ce(E) sha2_ce(E) sha1_ce(E) ses(E) enclosure(E) 
shpchp(E) marvell(E)
[ 2367.144808] CPU: 16 PID: 710 Comm: kworker/16:1 Tainted: GE   
4.1.23-next.aarch64 #1
[ 2367.180161] Hardware name: Huawei Taishan 2280 /BC11SPCC, BIOS 1.28 
05/14/2016
[ 2367.213305] Workqueue: events ata_scsi_hotplug
[ 2367.244296] task: ffe7db9b5e00 ti: ffe7db1a task.ti: 
ffe7db1a
[ 2367.279949] PC is at sas_find_dev_by_rphy+0x48/0x118
[ 2367.312045] LR is at sas_find_dev_by_rphy+0x40/0x118
[ 2367.341970] pc : [] lr : [] pstate: 
0145
...
[ 2368.766334] Call trace:
[ 2368.781712] [] sas_find_dev_by_rphy+0x48/0x118
[ 2368.800394] [] sas_target_alloc+0x28/0x98
[ 2368.817975] [] scsi_alloc_target+0x248/0x308
[ 2368.835570] [] __scsi_add_device+0xb8/0x160
[ 2368.853034] [] ata_scsi_scan_host+0x190/0x230
[ 2368.871614] [] ata_scsi_hotplug+0xc8/0xe8
[ 2368.889152] [] process_one_work+0x164/0x438
[ 2368.908003] [] worker_thread+0x144/0x4b0
[ 2368.924613] [] kthread+0xfc/0x110
[ 2368.940923] Code: aa1303e0 97ff5deb 3480 d1082273 (f943de76)

This because "dev_to_shost" in "sas_find_dev_by_rphy" return a NULL point,and 
SHOST_TO_SAS_HA used it,so kernel panic happed.

why dev_to_shost return a NULL point?
  Because in "__scsi_add_device" ,struct device *parent = 
>shost_gendev,and in "scsi_alloc_target", "*parent" is
assigned to "starget->dev.parent",then "sas_target_alloc" will get "struct 
sas_rphy" according "starget->dev.parent",
and  in "sas_find_dev_by_rphy" , we will get "struct Scsi_Host *shost" acording 
"rphy->dev.parent",we will find that
rphy->dev.parent = shost->shost_gendev.parent, and shost_gendev.parent is 
"ap->tdev",there is no parent any more,so "dev_to_shost"
return a NULL point.

when the panic will happen?
  When libata is handling error,and add hotplug_task to workqueue,
if a new sata disk pluged at the same time,the libata hotplug task will run and 
panic will happen.

In fact,we don't need libata to deal with hotplug in sas enviroment.So we can't 
run ata hotplug task when ata port is sas host.

Signed-off-by:Dingxiang 
Signed-off-by:Chenqilin 
---
 drivers/ata/libata-eh.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 61dc7a9..ac5ec4d 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -816,8 +816,12 @@ void ata_scsi_port_error_handler(struct Scsi_Host *host, 
struct ata_port *ap)
 
if (ap->pflags & ATA_PFLAG_LOADING)
ap->pflags &= ~ATA_PFLAG_LOADING;
-   else if (ap->pflags & ATA_PFLAG_SCSI_HOTPLUG)
-   schedule_delayed_work(>hotplug_task, 0);
+   else if (ap->pflags & ATA_PFLAG_SCSI_HOTPLUG){
+   if(ap->flags & ATA_FLAG_SAS_HOST)
+   ap->pflags &= ~ATA_PFLAG_SCSI_HOTPLUG;
+   else
+   schedule_delayed_work(>hotplug_task, 0);
+   }
 
if (ap->pflags & ATA_PFLAG_RECOVERED)
ata_port_info(ap, "EH complete\n");
-- 
2.5.0

[PATCH resend] libata:fix kernel panic when hotplug

[DingXiang]

From: Miao Xie 

In normal condition,if we use sas protocol and hotplug a sata disk on a port,
the sas driver will send event "PORTE_BYTES_DMAED" and call function 
"sas_porte_bytes_dmaed".
But if a sata disk is run io and unplug it,then plug a new sata disk,this 
operation may cause
a kernel panic like this:
[ 2366.923208] Unable to handle kernel NULL pointer dereference at virtual 
address 07b8
[ 2366.949253] pgd = ffc00121d000
[ 2366.971164] [07b8] *pgd=0027df893003, *pud=0027df893003, 
*pmd=0027df894003, *pte=00606d000707
[ 2367.022822] Internal error: Oops: 9605 [#1] SMP
[ 2367.048490] Modules linked in: dm_mirror(E) dm_region_hash(E) dm_log(E) 
dm_mod(E) crc32_arm64(E) aes_ce_blk(E) ablk_helper(E) cryptd(E) 
aes_ce_cipher(E) ghash_ce(E) sha2_ce(E) sha1_ce(E) ses(E) enclosure(E) 
shpchp(E) marvell(E)
[ 2367.144808] CPU: 16 PID: 710 Comm: kworker/16:1 Tainted: GE   
4.1.23-next.aarch64 #1
[ 2367.180161] Hardware name: Huawei Taishan 2280 /BC11SPCC, BIOS 1.28 
05/14/2016
[ 2367.213305] Workqueue: events ata_scsi_hotplug
[ 2367.244296] task: ffe7db9b5e00 ti: ffe7db1a task.ti: 
ffe7db1a
[ 2367.279949] PC is at sas_find_dev_by_rphy+0x48/0x118
[ 2367.312045] LR is at sas_find_dev_by_rphy+0x40/0x118
[ 2367.341970] pc : [] lr : [] pstate: 
0145
...
[ 2368.766334] Call trace:
[ 2368.781712] [] sas_find_dev_by_rphy+0x48/0x118
[ 2368.800394] [] sas_target_alloc+0x28/0x98
[ 2368.817975] [] scsi_alloc_target+0x248/0x308
[ 2368.835570] [] __scsi_add_device+0xb8/0x160
[ 2368.853034] [] ata_scsi_scan_host+0x190/0x230
[ 2368.871614] [] ata_scsi_hotplug+0xc8/0xe8
[ 2368.889152] [] process_one_work+0x164/0x438
[ 2368.908003] [] worker_thread+0x144/0x4b0
[ 2368.924613] [] kthread+0xfc/0x110
[ 2368.940923] Code: aa1303e0 97ff5deb 3480 d1082273 (f943de76)

This because "dev_to_shost" in "sas_find_dev_by_rphy" return a NULL point,and 
SHOST_TO_SAS_HA used it,so kernel panic happed.

why dev_to_shost return a NULL point?
  Because in "__scsi_add_device" ,struct device *parent = 
>shost_gendev,and in "scsi_alloc_target", "*parent" is
assigned to "starget->dev.parent",then "sas_target_alloc" will get "struct 
sas_rphy" according "starget->dev.parent",
and  in "sas_find_dev_by_rphy" , we will get "struct Scsi_Host *shost" acording 
"rphy->dev.parent",we will find that
rphy->dev.parent = shost->shost_gendev.parent, and shost_gendev.parent is 
"ap->tdev",there is no parent any more,so "dev_to_shost"
return a NULL point.

when the panic will happen?
  When libata is handling error,and add hotplug_task to workqueue,
if a new sata disk pluged at the same time,the libata hotplug task will run and 
panic will happen.

In fact,we don't need libata to deal with hotplug in sas enviroment.So we can't 
run ata hotplug task when ata port is sas host.

Signed-off-by:Dingxiang 
Signed-off-by:Chenqilin 
---
 drivers/ata/libata-eh.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 61dc7a9..ac5ec4d 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -816,8 +816,12 @@ void ata_scsi_port_error_handler(struct Scsi_Host *host, 
struct ata_port *ap)
 
if (ap->pflags & ATA_PFLAG_LOADING)
ap->pflags &= ~ATA_PFLAG_LOADING;
-   else if (ap->pflags & ATA_PFLAG_SCSI_HOTPLUG)
-   schedule_delayed_work(>hotplug_task, 0);
+   else if (ap->pflags & ATA_PFLAG_SCSI_HOTPLUG){
+   if(ap->flags & ATA_FLAG_SAS_HOST)
+   ap->pflags &= ~ATA_PFLAG_SCSI_HOTPLUG;
+   else
+   schedule_delayed_work(>hotplug_task, 0);
+   }
 
if (ap->pflags & ATA_PFLAG_RECOVERED)
ata_port_info(ap, "EH complete\n");
-- 
2.5.0

[PATCH] libata:fix kernel panic when hotplug

[DingXiang]

In normal condition,if we use sas protocol and hotplug a sata disk on a port,
the sas driver will send event "PORTE_BYTES_DMAED" and call function 
"sas_porte_bytes_dmaed".
But if a sata disk is run io and unplug it,then plug a new sata disk,this 
operation may cause
a kernel panic like this:
[ 2366.923208] Unable to handle kernel NULL pointer dereference at virtual 
address 07b8
[ 2366.949253] pgd = ffc00121d000
[ 2366.971164] [07b8] *pgd=0027df893003, *pud=0027df893003, 
*pmd=0027df894003, *pte=00606d000707
[ 2367.022822] Internal error: Oops: 9605 [#1] SMP
[ 2367.048490] Modules linked in: dm_mirror(E) dm_region_hash(E) dm_log(E) 
dm_mod(E) crc32_arm64(E) aes_ce_blk(E) ablk_helper(E) cryptd(E) 
aes_ce_cipher(E) ghash_ce(E) sha2_ce(E) sha1_ce(E) ses(E) enclosure(E) 
shpchp(E) marvell(E)
[ 2367.144808] CPU: 16 PID: 710 Comm: kworker/16:1 Tainted: GE   
4.1.23-next.aarch64 #1
[ 2367.180161] Hardware name: Huawei Taishan 2280 /BC11SPCC, BIOS 1.28 
05/14/2016
[ 2367.213305] Workqueue: events ata_scsi_hotplug
[ 2367.244296] task: ffe7db9b5e00 ti: ffe7db1a task.ti: 
ffe7db1a
[ 2367.279949] PC is at sas_find_dev_by_rphy+0x48/0x118
[ 2367.312045] LR is at sas_find_dev_by_rphy+0x40/0x118
[ 2367.341970] pc : [] lr : [] pstate: 
0145
...
[ 2368.766334] Call trace:
[ 2368.781712] [] sas_find_dev_by_rphy+0x48/0x118
[ 2368.800394] [] sas_target_alloc+0x28/0x98
[ 2368.817975] [] scsi_alloc_target+0x248/0x308
[ 2368.835570] [] __scsi_add_device+0xb8/0x160
[ 2368.853034] [] ata_scsi_scan_host+0x190/0x230
[ 2368.871614] [] ata_scsi_hotplug+0xc8/0xe8
[ 2368.889152] [] process_one_work+0x164/0x438
[ 2368.908003] [] worker_thread+0x144/0x4b0
[ 2368.924613] [] kthread+0xfc/0x110
[ 2368.940923] Code: aa1303e0 97ff5deb 3480 d1082273 (f943de76)

This because "dev_to_shost" in "sas_find_dev_by_rphy" return a NULL point,and 
SHOST_TO_SAS_HA used it,so kernel panic happed.

why dev_to_shost return a NULL point?
  Because in "__scsi_add_device" ,struct device *parent = 
>shost_gendev,and in "scsi_alloc_target", "*parent" is
assigned to "starget->dev.parent",then "sas_target_alloc" will get "struct 
sas_rphy" according "starget->dev.parent",
and  in "sas_find_dev_by_rphy" , we will get "struct Scsi_Host *shost" acording 
"rphy->dev.parent",we will find that 
rphy->dev.parent = shost->shost_gendev.parent, and shost_gendev.parent is 
"ap->tdev",there is no parent any more,so "dev_to_shost"
return a NULL point.

when the panic will happen?
  When libata is handling error,and add hotplug_task to workqueue,
if a new sata disk pluged at the same time,the libata hotplug task will run and 
panic will happen.

In fact,we don't need libata to deal with hotplug in sas enviroment.So we can't 
run ata hotplug task when ata port is sas host.

Signed-off-by:Dingxiang 
Signed-off-by:Chenqilin 
---
 drivers/ata/libata-eh.c |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 961acc7..74c5ecf 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -816,8 +816,11 @@ void ata_scsi_port_error_handler(struct Scsi_Host *host, 
struct ata_port *ap)
 
if (ap->pflags & ATA_PFLAG_LOADING)
ap->pflags &= ~ATA_PFLAG_LOADING;
-   else if (ap->pflags & ATA_PFLAG_SCSI_HOTPLUG)
-   schedule_delayed_work(>hotplug_task, 0);
+   else if (ap->pflags & ATA_PFLAG_SCSI_HOTPLUG){
+   if(ap->flags & ATA_FLAG_SAS_HOST)
+   ap->pflags &= ~ATA_PFLAG_SCSI_HOTPLUG;
+   else
+   schedule_delayed_work(>hotplug_task, 0);
 
if (ap->pflags & ATA_PFLAG_RECOVERED)
ata_port_info(ap, "EH complete\n");
-- 
1.7.1

[PATCH] libata:fix kernel panic when hotplug

[DingXiang]

In normal condition,if we use sas protocol and hotplug a sata disk on a port,
the sas driver will send event "PORTE_BYTES_DMAED" and call function 
"sas_porte_bytes_dmaed".
But if a sata disk is run io and unplug it,then plug a new sata disk,this 
operation may cause
a kernel panic like this:
[ 2366.923208] Unable to handle kernel NULL pointer dereference at virtual 
address 07b8
[ 2366.949253] pgd = ffc00121d000
[ 2366.971164] [07b8] *pgd=0027df893003, *pud=0027df893003, 
*pmd=0027df894003, *pte=00606d000707
[ 2367.022822] Internal error: Oops: 9605 [#1] SMP
[ 2367.048490] Modules linked in: dm_mirror(E) dm_region_hash(E) dm_log(E) 
dm_mod(E) crc32_arm64(E) aes_ce_blk(E) ablk_helper(E) cryptd(E) 
aes_ce_cipher(E) ghash_ce(E) sha2_ce(E) sha1_ce(E) ses(E) enclosure(E) 
shpchp(E) marvell(E)
[ 2367.144808] CPU: 16 PID: 710 Comm: kworker/16:1 Tainted: GE   
4.1.23-next.aarch64 #1
[ 2367.180161] Hardware name: Huawei Taishan 2280 /BC11SPCC, BIOS 1.28 
05/14/2016
[ 2367.213305] Workqueue: events ata_scsi_hotplug
[ 2367.244296] task: ffe7db9b5e00 ti: ffe7db1a task.ti: 
ffe7db1a
[ 2367.279949] PC is at sas_find_dev_by_rphy+0x48/0x118
[ 2367.312045] LR is at sas_find_dev_by_rphy+0x40/0x118
[ 2367.341970] pc : [] lr : [] pstate: 
0145
...
[ 2368.766334] Call trace:
[ 2368.781712] [] sas_find_dev_by_rphy+0x48/0x118
[ 2368.800394] [] sas_target_alloc+0x28/0x98
[ 2368.817975] [] scsi_alloc_target+0x248/0x308
[ 2368.835570] [] __scsi_add_device+0xb8/0x160
[ 2368.853034] [] ata_scsi_scan_host+0x190/0x230
[ 2368.871614] [] ata_scsi_hotplug+0xc8/0xe8
[ 2368.889152] [] process_one_work+0x164/0x438
[ 2368.908003] [] worker_thread+0x144/0x4b0
[ 2368.924613] [] kthread+0xfc/0x110
[ 2368.940923] Code: aa1303e0 97ff5deb 3480 d1082273 (f943de76)

This because "dev_to_shost" in "sas_find_dev_by_rphy" return a NULL point,and 
SHOST_TO_SAS_HA used it,so kernel panic happed.

why dev_to_shost return a NULL point?
  Because in "__scsi_add_device" ,struct device *parent = 
>shost_gendev,and in "scsi_alloc_target", "*parent" is
assigned to "starget->dev.parent",then "sas_target_alloc" will get "struct 
sas_rphy" according "starget->dev.parent",
and  in "sas_find_dev_by_rphy" , we will get "struct Scsi_Host *shost" acording 
"rphy->dev.parent",we will find that 
rphy->dev.parent = shost->shost_gendev.parent, and shost_gendev.parent is 
"ap->tdev",there is no parent any more,so "dev_to_shost"
return a NULL point.

when the panic will happen?
  When libata is handling error,and add hotplug_task to workqueue,
if a new sata disk pluged at the same time,the libata hotplug task will run and 
panic will happen.

In fact,we don't need libata to deal with hotplug in sas enviroment.So we can't 
run ata hotplug task when ata port is sas host.

Signed-off-by:Dingxiang 
Signed-off-by:Chenqilin 
---
 drivers/ata/libata-eh.c |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 961acc7..74c5ecf 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -816,8 +816,11 @@ void ata_scsi_port_error_handler(struct Scsi_Host *host, 
struct ata_port *ap)
 
if (ap->pflags & ATA_PFLAG_LOADING)
ap->pflags &= ~ATA_PFLAG_LOADING;
-   else if (ap->pflags & ATA_PFLAG_SCSI_HOTPLUG)
-   schedule_delayed_work(>hotplug_task, 0);
+   else if (ap->pflags & ATA_PFLAG_SCSI_HOTPLUG){
+   if(ap->flags & ATA_FLAG_SAS_HOST)
+   ap->pflags &= ~ATA_PFLAG_SCSI_HOTPLUG;
+   else
+   schedule_delayed_work(>hotplug_task, 0);
 
if (ap->pflags & ATA_PFLAG_RECOVERED)
ata_port_info(ap, "EH complete\n");
-- 
1.7.1

Very Confidential Finance Letter:

[Dingxiang Wong]

Hello I am Dingxiang Wong, A staff Member of Maybank Malaysia investment 
committee and I'm contacting you for a business proposal to transfer 
$7.3 million to you for investment partnership in your country, this 
fund belongs to our business partner who has been presume dead in the 
Missing Malaysia Airlines flight MH370 which has been disappeared on 8th 
March 2014 without any trace.


Our Business Partner Mr. Li Yuan and Mrs Gu Naijun was the third 
Australian couple to travel on the missing Malaysian flight, Mr. Li Yuan 
has deposited the sum of $7.3 million into our bank for investment, but 
he left No beneficiary to inherit his fund before he went missing with 
Malaysian flight MH370. I am contacting you because i want you and me to 
establish New business partnership and invest the fund together in your 
country, i am ready to give you every details of the fund to transfer 
the fund to you for our new investment, please reply to me for more details.


Thank You
Dingxiang Wong


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Very Confidential Finance Letter:

[Dingxiang Wong]

Hello I am Dingxiang Wong, A staff Member of Maybank Malaysia investment 
committee and I'm contacting you for a business proposal to transfer 
$7.3 million to you for investment partnership in your country, this 
fund belongs to our business partner who has been presume dead in the 
Missing Malaysia Airlines flight MH370 which has been disappeared on 8th 
March 2014 without any trace.


Our Business Partner Mr. Li Yuan and Mrs Gu Naijun was the third 
Australian couple to travel on the missing Malaysian flight, Mr. Li Yuan 
has deposited the sum of $7.3 million into our bank for investment, but 
he left No beneficiary to inherit his fund before he went missing with 
Malaysian flight MH370. I am contacting you because i want you and me to 
establish New business partnership and invest the fund together in your 
country, i am ready to give you every details of the fund to transfer 
the fund to you for our new investment, please reply to me for more details.


Thank You
Dingxiang Wong


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[PATCH resend] [dm]fix NULL pointer when create dm device

[DingXiang]

In some conditions(such as umount fs failed),origin path or origin bdev or both 
of the two is same
as cow's.If this happens, origin dev will be freed when get cow dev in function 
"dm_get_device" ,
then "s->origin->dev" which used by "dm_exception_store_set_chunk_size" will be 
a NULL pointer.

Here is my call trace

dracut-initqueue[2614]: mount: unknown filesystem type 'squashfs'
dracut-initqueue[2614]: umount: /run/initramfs/squashfs: not mounted
Unable to handle kernel NULL pointer dereference at virtual address 0098
pgd = ffc038c3d000
[0098] *pgd=, *pud=
Internal error: Oops: 9605 [#1] SMP
Modules linked in:
CPU: 20 PID: 6389 Comm: dmsetup Not tainted 3.19.8+ #19
Hardware name: Huawei Taishan 2160 /BC11SPCA, BIOS 1.16 01/13/2016
task: ffdfb3e060c0 ti: ffc03860 task.ti: ffc03860
PC is at dm_exception_store_set_chunk_size+0x6c/0x124
LR is at dm_exception_store_set_chunk_size+0x68/0x124
pc : [] lr : [] pstate: 4145
sp : ffc038603a90
x29: ffc038603a90 x28: ffc03860
x27: ffefab3b7630 x26: 0001
x25: ffc000c9e030 x24: ffdfb2187740
x23: ffc038603b94 x22: ffefab3b7730
x21: ff80003dd088 x20: ffdfb2187740
x19: 0008 x18: 007fac97383c
x17: 007fac8b9cb0 x16: ffc0001ae79c
x15: 007fac9a00b0 x14: 007fac9a00b0
x13: 0001 x12: 0020
x11: 0008 x10: 
x9 : 000a x8 : 0008
x7 : ffefa95f4179 x6 : 0008
x5 : 0008 x4 : 0007
x3 : 0008 x2 : ff80003dd088
x1 : 0008 x0 : 

Process dmsetup (pid: 6389, stack limit = 0xffc038600058)
Stack: (0xffc038603a90 to 0xffc038604000)
3a80: 38603ac0 ffc0 0060b6fc ffc0
3aa0:   003dd040 ff80 ab3b7600 ffef 0008 
3ac0: 38603b20 ffc0 0060a944 ffc0 b2187700 ffdf 003dd040 ff80
3ae0: ab3b7600 ffef ab3b7730 ffef 0002  0081e000 ffc0
3b00: 00cc6000 ffc0 3860 ffc0 38603b20 ffc0 b2187b58 0008
3b20: 38603bb0 ffc0 005f6378 ffc0 003dd040 ff80 ab3b7800 ffef
3b40:   a95f4150 ffef   003dd040 ff80
3b60: a95f4000 ffef a95f4000 ffef 00c58000 ffc0 3860 ffc0
3b80:   a95f416b ffef a95f4000 ffef 005f62d4 ffc0
3ba0: 003dd040 ff80 005f5f68 0008 38603c10 ffc0 005f98cc ffc0
3bc0: a95f4138 ffef a95f8000 ffef   b41b2400 ffdf
3be0: ab3b7800 ffef   a95f4160 ffef 0010 
3c00: 38603c10 0004 b2187700 ffdf 38603c70 ffc0 005fa484 ffc0
3c20: c7e1d2d0 007f   4000  0009 
3c40: 0001  005f97bc ffc0    
3c60:   ab3b7800 ffef 38603e00 ffc0 005fa758 ffc0
3c80: b7e82c00 ffdf c7e1d2d0 007f b87e6e88 ffef 0003 
3ca0: c7e1d2d0 007f c138fd09  011a  001d 
3cc0: 0020  0004 001d  4000 0138 0001
3ce0:  0004     6576696c 0077722d
3d00:        
3d20:        
3d40:        
3d60:        
3d80:        
3da0:        
3dc0:        
3de0:        
3e00: 38603e10 ffc0 001ae54c ffc0 38603e90 ffc0 001ae820 ffc0
3e20:   b7e82c00 ffdf b7e82c00 ffdf 0003 
3e40: 00cbb000 ffc0 b3e060c0 ffdf 8000  0015 
3e60:     38603e80 ffc0 001b88e4 ffc0
3e80: 38603e90 ffc0 001ae7dc ffc0 c6e64c40 007f 00086430 ffc0
3ea0:   c7e1d2d0 007f   ac8b9cbc 007f
3ec0: 6000  0015  0003  c138fd09 
3ee0: c7e1d2d0 007f 0007  ac9a73e8 007f c6e64aa0 007f
3f00: 37770e00 3c220354 c7e1d300 007f 001d  ffe8 ff80
3f20: c6e64b90 007f c6e64b90 007f ac9a00b0 007f ac9a00b0 007f
3f40: ac9a00b0 007f ac9a00b0 007f ac9bec98 007f ac8b9cb0 007f
3f60: ac97383c 007f c7e1d200 007f c7e1d2d0 007f c7e1d300 007f
3f80: ac9a6000 007f c7e1d380 007f ac9a00b0 007f ac9a00b0 007f

[PATCH resend] [dm]fix NULL pointer when create dm device

[DingXiang]

In some conditions(such as umount fs failed),origin path or origin bdev or both 
of the two is same
as cow's.If this happens, origin dev will be freed when get cow dev in function 
"dm_get_device" ,
then "s->origin->dev" which used by "dm_exception_store_set_chunk_size" will be 
a NULL pointer.

Here is my call trace

dracut-initqueue[2614]: mount: unknown filesystem type 'squashfs'
dracut-initqueue[2614]: umount: /run/initramfs/squashfs: not mounted
Unable to handle kernel NULL pointer dereference at virtual address 0098
pgd = ffc038c3d000
[0098] *pgd=, *pud=
Internal error: Oops: 9605 [#1] SMP
Modules linked in:
CPU: 20 PID: 6389 Comm: dmsetup Not tainted 3.19.8+ #19
Hardware name: Huawei Taishan 2160 /BC11SPCA, BIOS 1.16 01/13/2016
task: ffdfb3e060c0 ti: ffc03860 task.ti: ffc03860
PC is at dm_exception_store_set_chunk_size+0x6c/0x124
LR is at dm_exception_store_set_chunk_size+0x68/0x124
pc : [] lr : [] pstate: 4145
sp : ffc038603a90
x29: ffc038603a90 x28: ffc03860
x27: ffefab3b7630 x26: 0001
x25: ffc000c9e030 x24: ffdfb2187740
x23: ffc038603b94 x22: ffefab3b7730
x21: ff80003dd088 x20: ffdfb2187740
x19: 0008 x18: 007fac97383c
x17: 007fac8b9cb0 x16: ffc0001ae79c
x15: 007fac9a00b0 x14: 007fac9a00b0
x13: 0001 x12: 0020
x11: 0008 x10: 
x9 : 000a x8 : 0008
x7 : ffefa95f4179 x6 : 0008
x5 : 0008 x4 : 0007
x3 : 0008 x2 : ff80003dd088
x1 : 0008 x0 : 

Process dmsetup (pid: 6389, stack limit = 0xffc038600058)
Stack: (0xffc038603a90 to 0xffc038604000)
3a80: 38603ac0 ffc0 0060b6fc ffc0
3aa0:   003dd040 ff80 ab3b7600 ffef 0008 
3ac0: 38603b20 ffc0 0060a944 ffc0 b2187700 ffdf 003dd040 ff80
3ae0: ab3b7600 ffef ab3b7730 ffef 0002  0081e000 ffc0
3b00: 00cc6000 ffc0 3860 ffc0 38603b20 ffc0 b2187b58 0008
3b20: 38603bb0 ffc0 005f6378 ffc0 003dd040 ff80 ab3b7800 ffef
3b40:   a95f4150 ffef   003dd040 ff80
3b60: a95f4000 ffef a95f4000 ffef 00c58000 ffc0 3860 ffc0
3b80:   a95f416b ffef a95f4000 ffef 005f62d4 ffc0
3ba0: 003dd040 ff80 005f5f68 0008 38603c10 ffc0 005f98cc ffc0
3bc0: a95f4138 ffef a95f8000 ffef   b41b2400 ffdf
3be0: ab3b7800 ffef   a95f4160 ffef 0010 
3c00: 38603c10 0004 b2187700 ffdf 38603c70 ffc0 005fa484 ffc0
3c20: c7e1d2d0 007f   4000  0009 
3c40: 0001  005f97bc ffc0    
3c60:   ab3b7800 ffef 38603e00 ffc0 005fa758 ffc0
3c80: b7e82c00 ffdf c7e1d2d0 007f b87e6e88 ffef 0003 
3ca0: c7e1d2d0 007f c138fd09  011a  001d 
3cc0: 0020  0004 001d  4000 0138 0001
3ce0:  0004     6576696c 0077722d
3d00:        
3d20:        
3d40:        
3d60:        
3d80:        
3da0:        
3dc0:        
3de0:        
3e00: 38603e10 ffc0 001ae54c ffc0 38603e90 ffc0 001ae820 ffc0
3e20:   b7e82c00 ffdf b7e82c00 ffdf 0003 
3e40: 00cbb000 ffc0 b3e060c0 ffdf 8000  0015 
3e60:     38603e80 ffc0 001b88e4 ffc0
3e80: 38603e90 ffc0 001ae7dc ffc0 c6e64c40 007f 00086430 ffc0
3ea0:   c7e1d2d0 007f   ac8b9cbc 007f
3ec0: 6000  0015  0003  c138fd09 
3ee0: c7e1d2d0 007f 0007  ac9a73e8 007f c6e64aa0 007f
3f00: 37770e00 3c220354 c7e1d300 007f 001d  ffe8 ff80
3f20: c6e64b90 007f c6e64b90 007f ac9a00b0 007f ac9a00b0 007f
3f40: ac9a00b0 007f ac9a00b0 007f ac9bec98 007f ac8b9cb0 007f
3f60: ac97383c 007f c7e1d200 007f c7e1d2d0 007f c7e1d300 007f
3f80: ac9a6000 007f c7e1d380 007f ac9a00b0 007f ac9a00b0 007f

[PATCH] [dm]fix NULL pointer in dm_exception_store_create() when create dm device

[DingXiang]

In some conditions(such as umount fs failed),origin path or origin bdev or both 
of the two is same
as cow's.If this happens, origin dev will be freed when get cow dev in function 
"dm_get_device" ,
then "s->origin->dev" which used by "dm_exception_store_create" will be a NULL 
pointer.

Signed-off-by:Ding Xiang 
---
 drivers/md/dm-snap.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/md/dm-snap.c b/drivers/md/dm-snap.c
index 3766386..ccf97d8 100644
--- a/drivers/md/dm-snap.c
+++ b/drivers/md/dm-snap.c
@@ -1102,6 +1102,7 @@ static void stop_merge(struct dm_snapshot *s)
 static int snapshot_ctr(struct dm_target *ti, unsigned int argc, char **argv)
 {
struct dm_snapshot *s;
+   struct block_device *origin_bdev, *cow_bdev;
int i;
int r = -EINVAL;
char *origin_path, *cow_path;
@@ -1136,10 +1137,19 @@ static int snapshot_ctr(struct dm_target *ti, unsigned 
int argc, char **argv)
goto bad_origin;
}
 
+   origin_bdev = s->origin->bdev;
cow_path = argv[0];
argv++;
argc--;
 
+   /*check cow dev is available*/
+   cow_bdev = lookup_bdev(cow_path);
+   if(cow_bdev->bd_dev == origin_bdev->bd_dev){
+   ti->error = "Invalid COW device";
+   r = -EINVAL;
+   goto bad_cow;
+   }
+
r = dm_get_device(ti, cow_path, dm_table_get_mode(ti->table), >cow);
if (r) {
ti->error = "Cannot get COW device";
-- 
1.7.1

[PATCH] [dm]fix NULL pointer in dm_exception_store_create() when create dm device

[DingXiang]

In some conditions(such as umount fs failed),origin path or origin bdev or both 
of the two is same
as cow's.If this happens, origin dev will be freed when get cow dev in function 
"dm_get_device" ,
then "s->origin->dev" which used by "dm_exception_store_create" will be a NULL 
pointer.

Signed-off-by:Ding Xiang 
---
 drivers/md/dm-snap.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/md/dm-snap.c b/drivers/md/dm-snap.c
index 3766386..ccf97d8 100644
--- a/drivers/md/dm-snap.c
+++ b/drivers/md/dm-snap.c
@@ -1102,6 +1102,7 @@ static void stop_merge(struct dm_snapshot *s)
 static int snapshot_ctr(struct dm_target *ti, unsigned int argc, char **argv)
 {
struct dm_snapshot *s;
+   struct block_device *origin_bdev, *cow_bdev;
int i;
int r = -EINVAL;
char *origin_path, *cow_path;
@@ -1136,10 +1137,19 @@ static int snapshot_ctr(struct dm_target *ti, unsigned 
int argc, char **argv)
goto bad_origin;
}
 
+   origin_bdev = s->origin->bdev;
cow_path = argv[0];
argv++;
argc--;
 
+   /*check cow dev is available*/
+   cow_bdev = lookup_bdev(cow_path);
+   if(cow_bdev->bd_dev == origin_bdev->bd_dev){
+   ti->error = "Invalid COW device";
+   r = -EINVAL;
+   goto bad_cow;
+   }
+
r = dm_get_device(ti, cow_path, dm_table_get_mode(ti->table), >cow);
if (r) {
ti->error = "Cannot get COW device";
-- 
1.7.1