* [PATCH v2 03/10] ps3disk: add error handling support for add_disk()
From: Luis Chamberlain @ 2021-09-27 22:01 UTC (permalink / raw)
To: axboe, bhelgaas, liushixin2, thunder.leizhen, lee.jones, geoff,
mpe, benh, paulus, jim, haris.iqbal, jinpu.wang, josh.h.morris,
pjk1939, tim, richard, miquel.raynal, vigneshr
Cc: linux-block, linuxppc-dev, Luis Chamberlain, linux-mtd,
linux-kernel
In-Reply-To: <20210927220157.1069658-1-mcgrof@kernel.org>
We never checked for errors on add_disk() as this function
returned void. Now that this is fixed, use the shiny new
error handling.
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
---
drivers/block/ps3disk.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/block/ps3disk.c b/drivers/block/ps3disk.c
index 8d51efbe045d..3054adf77460 100644
--- a/drivers/block/ps3disk.c
+++ b/drivers/block/ps3disk.c
@@ -467,9 +467,13 @@ static int ps3disk_probe(struct ps3_system_bus_device *_dev)
gendisk->disk_name, priv->model, priv->raw_capacity >> 11,
get_capacity(gendisk) >> 11);
- device_add_disk(&dev->sbd.core, gendisk, NULL);
- return 0;
+ error = device_add_disk(&dev->sbd.core, gendisk, NULL);
+ if (error)
+ goto fail_cleanup_disk;
+ return 0;
+fail_cleanup_disk:
+ blk_cleanup_disk(gendisk);
fail_free_tag_set:
blk_mq_free_tag_set(&priv->tag_set);
fail_teardown:
--
2.30.2
^ permalink raw reply related
* [PATCH v2 10/10] mtd/ubi/block: add error handling support for add_disk()
From: Luis Chamberlain @ 2021-09-27 22:01 UTC (permalink / raw)
To: axboe, bhelgaas, liushixin2, thunder.leizhen, lee.jones, geoff,
mpe, benh, paulus, jim, haris.iqbal, jinpu.wang, josh.h.morris,
pjk1939, tim, richard, miquel.raynal, vigneshr
Cc: linux-block, linuxppc-dev, Luis Chamberlain, linux-mtd,
linux-kernel
In-Reply-To: <20210927220157.1069658-1-mcgrof@kernel.org>
We never checked for errors on add_disk() as this function
returned void. Now that this is fixed, use the shiny new
error handling.
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
---
drivers/mtd/ubi/block.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/ubi/block.c b/drivers/mtd/ubi/block.c
index e003b4b44ffa..062e6c2c45f5 100644
--- a/drivers/mtd/ubi/block.c
+++ b/drivers/mtd/ubi/block.c
@@ -447,12 +447,18 @@ int ubiblock_create(struct ubi_volume_info *vi)
list_add_tail(&dev->list, &ubiblock_devices);
/* Must be the last step: anyone can call file ops from now on */
- add_disk(dev->gd);
+ ret = add_disk(dev->gd);
+ if (ret)
+ goto out_destroy_wq;
+
dev_info(disk_to_dev(dev->gd), "created from ubi%d:%d(%s)",
dev->ubi_num, dev->vol_id, vi->name);
mutex_unlock(&devices_mutex);
return 0;
+out_destroy_wq:
+ list_del(&dev->list);
+ destroy_workqueue(dev->wq);
out_remove_minor:
idr_remove(&ubiblock_minor_idr, gd->first_minor);
out_cleanup_disk:
--
2.30.2
^ permalink raw reply related
* [PATCH v2 05/10] rnbd: add error handling support for add_disk()
From: Luis Chamberlain @ 2021-09-27 22:01 UTC (permalink / raw)
To: axboe, bhelgaas, liushixin2, thunder.leizhen, lee.jones, geoff,
mpe, benh, paulus, jim, haris.iqbal, jinpu.wang, josh.h.morris,
pjk1939, tim, richard, miquel.raynal, vigneshr
Cc: linux-block, linuxppc-dev, Luis Chamberlain, linux-mtd,
linux-kernel
In-Reply-To: <20210927220157.1069658-1-mcgrof@kernel.org>
We never checked for errors on add_disk() as this function
returned void. Now that this is fixed, use the shiny new
error handling.
Acked-by: Jack Wang <jinpu.wang@ionos.com>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
---
drivers/block/rnbd/rnbd-clt.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/block/rnbd/rnbd-clt.c b/drivers/block/rnbd/rnbd-clt.c
index bd4a41afbbfc..1ba1c868535a 100644
--- a/drivers/block/rnbd/rnbd-clt.c
+++ b/drivers/block/rnbd/rnbd-clt.c
@@ -1384,8 +1384,10 @@ static void setup_request_queue(struct rnbd_clt_dev *dev)
blk_queue_write_cache(dev->queue, dev->wc, dev->fua);
}
-static void rnbd_clt_setup_gen_disk(struct rnbd_clt_dev *dev, int idx)
+static int rnbd_clt_setup_gen_disk(struct rnbd_clt_dev *dev, int idx)
{
+ int err;
+
dev->gd->major = rnbd_client_major;
dev->gd->first_minor = idx << RNBD_PART_BITS;
dev->gd->minors = 1 << RNBD_PART_BITS;
@@ -1410,7 +1412,11 @@ static void rnbd_clt_setup_gen_disk(struct rnbd_clt_dev *dev, int idx)
if (!dev->rotational)
blk_queue_flag_set(QUEUE_FLAG_NONROT, dev->queue);
- add_disk(dev->gd);
+ err = add_disk(dev->gd);
+ if (err)
+ blk_cleanup_disk(dev->gd);
+
+ return err;
}
static int rnbd_client_setup_device(struct rnbd_clt_dev *dev)
@@ -1426,8 +1432,7 @@ static int rnbd_client_setup_device(struct rnbd_clt_dev *dev)
rnbd_init_mq_hw_queues(dev);
setup_request_queue(dev);
- rnbd_clt_setup_gen_disk(dev, idx);
- return 0;
+ return rnbd_clt_setup_gen_disk(dev, idx);
}
static struct rnbd_clt_dev *init_dev(struct rnbd_clt_session *sess,
--
2.30.2
^ permalink raw reply related
* [PATCH v2 00/10] block: fourth batch of add_disk() error handling conversions
From: Luis Chamberlain @ 2021-09-27 22:01 UTC (permalink / raw)
To: axboe, bhelgaas, liushixin2, thunder.leizhen, lee.jones, geoff,
mpe, benh, paulus, jim, haris.iqbal, jinpu.wang, josh.h.morris,
pjk1939, tim, richard, miquel.raynal, vigneshr
Cc: linux-block, linuxppc-dev, Luis Chamberlain, linux-mtd,
linux-kernel
This is the fourth batch of add_disk() error handling driver
conversions. This set along with the entire 7 set of driver conversions
can be found on my 20210927-for-axboe-add-disk-error-handling branch
[0].
On this v2 series the following modifications have been made since the
last v1 series of this patch set:
- rebased onto linux-next tag 20210927
- added the only reviewed-by tag for this series for rnbd Jack Wang
[0] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=20210927-for-axboe-add-disk-error-handling
Luis Chamberlain (10):
mtip32xx: add error handling support for add_disk()
pktcdvd: add error handling support for add_disk()
ps3disk: add error handling support for add_disk()
ps3vram: add error handling support for add_disk()
rnbd: add error handling support for add_disk()
block/rsxx: add error handling support for add_disk()
block/sunvdc: add error handling support for add_disk()
block/sx8: add error handling support for add_disk()
pf: add error handling support for add_disk()
mtd/ubi/block: add error handling support for add_disk()
drivers/block/mtip32xx/mtip32xx.c | 4 +++-
drivers/block/paride/pf.c | 4 +++-
drivers/block/pktcdvd.c | 4 +++-
drivers/block/ps3disk.c | 8 ++++++--
drivers/block/ps3vram.c | 7 ++++++-
drivers/block/rnbd/rnbd-clt.c | 13 +++++++++----
drivers/block/rsxx/core.c | 4 +++-
drivers/block/rsxx/dev.c | 12 +++++++++---
drivers/block/sunvdc.c | 14 +++++++++++---
drivers/block/sx8.c | 13 +++++++++----
drivers/mtd/ubi/block.c | 8 +++++++-
11 files changed, 69 insertions(+), 22 deletions(-)
--
2.30.2
^ permalink raw reply
* [PATCH v2 06/10] block/rsxx: add error handling support for add_disk()
From: Luis Chamberlain @ 2021-09-27 22:01 UTC (permalink / raw)
To: axboe, bhelgaas, liushixin2, thunder.leizhen, lee.jones, geoff,
mpe, benh, paulus, jim, haris.iqbal, jinpu.wang, josh.h.morris,
pjk1939, tim, richard, miquel.raynal, vigneshr
Cc: linux-block, linuxppc-dev, Luis Chamberlain, linux-mtd,
linux-kernel
In-Reply-To: <20210927220157.1069658-1-mcgrof@kernel.org>
We never checked for errors on add_disk() as this function
returned void. Now that this is fixed, use the shiny new
error handling.
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
---
drivers/block/rsxx/core.c | 4 +++-
drivers/block/rsxx/dev.c | 12 +++++++++---
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/block/rsxx/core.c b/drivers/block/rsxx/core.c
index 83636714b8d7..8d9d69f5dfbc 100644
--- a/drivers/block/rsxx/core.c
+++ b/drivers/block/rsxx/core.c
@@ -935,7 +935,9 @@ static int rsxx_pci_probe(struct pci_dev *dev,
card->size8 = 0;
}
- rsxx_attach_dev(card);
+ st = rsxx_attach_dev(card);
+ if (st)
+ goto failed_create_dev;
/************* Setup Debugfs *************/
rsxx_debugfs_dev_new(card);
diff --git a/drivers/block/rsxx/dev.c b/drivers/block/rsxx/dev.c
index 1cc40b0ea761..b2d3ac3efce2 100644
--- a/drivers/block/rsxx/dev.c
+++ b/drivers/block/rsxx/dev.c
@@ -192,6 +192,8 @@ static bool rsxx_discard_supported(struct rsxx_cardinfo *card)
int rsxx_attach_dev(struct rsxx_cardinfo *card)
{
+ int err = 0;
+
mutex_lock(&card->dev_lock);
/* The block device requires the stripe size from the config. */
@@ -200,13 +202,17 @@ int rsxx_attach_dev(struct rsxx_cardinfo *card)
set_capacity(card->gendisk, card->size8 >> 9);
else
set_capacity(card->gendisk, 0);
- device_add_disk(CARD_TO_DEV(card), card->gendisk, NULL);
- card->bdev_attached = 1;
+ err = device_add_disk(CARD_TO_DEV(card), card->gendisk, NULL);
+ if (err == 0)
+ card->bdev_attached = 1;
}
mutex_unlock(&card->dev_lock);
- return 0;
+ if (err)
+ blk_cleanup_disk(card->gendisk);
+
+ return err;
}
void rsxx_detach_dev(struct rsxx_cardinfo *card)
--
2.30.2
^ permalink raw reply related
* [PATCH v2 09/10] pf: add error handling support for add_disk()
From: Luis Chamberlain @ 2021-09-27 22:01 UTC (permalink / raw)
To: axboe, bhelgaas, liushixin2, thunder.leizhen, lee.jones, geoff,
mpe, benh, paulus, jim, haris.iqbal, jinpu.wang, josh.h.morris,
pjk1939, tim, richard, miquel.raynal, vigneshr
Cc: linux-block, linuxppc-dev, Luis Chamberlain, linux-mtd,
linux-kernel
In-Reply-To: <20210927220157.1069658-1-mcgrof@kernel.org>
We never checked for errors on add_disk() as this function
returned void. Now that this is fixed, use the shiny new
error handling.
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
---
drivers/block/paride/pf.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/block/paride/pf.c b/drivers/block/paride/pf.c
index f471d48a87bc..380d80e507c7 100644
--- a/drivers/block/paride/pf.c
+++ b/drivers/block/paride/pf.c
@@ -962,7 +962,9 @@ static int __init pf_init_unit(struct pf_unit *pf, bool autoprobe, int port,
if (pf_probe(pf))
goto out_pi_release;
- add_disk(disk);
+ ret = add_disk(disk);
+ if (ret)
+ goto out_pi_release;
pf->present = 1;
return 0;
--
2.30.2
^ permalink raw reply related
* [PATCH v2 01/10] mtip32xx: add error handling support for add_disk()
From: Luis Chamberlain @ 2021-09-27 22:01 UTC (permalink / raw)
To: axboe, bhelgaas, liushixin2, thunder.leizhen, lee.jones, geoff,
mpe, benh, paulus, jim, haris.iqbal, jinpu.wang, josh.h.morris,
pjk1939, tim, richard, miquel.raynal, vigneshr
Cc: linux-block, linuxppc-dev, Luis Chamberlain, linux-mtd,
linux-kernel
In-Reply-To: <20210927220157.1069658-1-mcgrof@kernel.org>
We never checked for errors on add_disk() as this function
returned void. Now that this is fixed, use the shiny new
error handling.
The read_capacity_error error label already does what we need,
so just re-use that.
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
---
drivers/block/mtip32xx/mtip32xx.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/block/mtip32xx/mtip32xx.c b/drivers/block/mtip32xx/mtip32xx.c
index 901855717cb5..d0b40309f47e 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -3633,7 +3633,9 @@ static int mtip_block_initialize(struct driver_data *dd)
set_capacity(dd->disk, capacity);
/* Enable the block device and add it to /dev */
- device_add_disk(&dd->pdev->dev, dd->disk, mtip_disk_attr_groups);
+ rv = device_add_disk(&dd->pdev->dev, dd->disk, mtip_disk_attr_groups);
+ if (rv)
+ goto read_capacity_error;
if (dd->mtip_svc_handler) {
set_bit(MTIP_DDF_INIT_DONE_BIT, &dd->dd_flag);
--
2.30.2
^ permalink raw reply related
* [PATCH v2 04/10] ps3vram: add error handling support for add_disk()
From: Luis Chamberlain @ 2021-09-27 22:01 UTC (permalink / raw)
To: axboe, bhelgaas, liushixin2, thunder.leizhen, lee.jones, geoff,
mpe, benh, paulus, jim, haris.iqbal, jinpu.wang, josh.h.morris,
pjk1939, tim, richard, miquel.raynal, vigneshr
Cc: linux-block, linuxppc-dev, Luis Chamberlain, linux-mtd,
linux-kernel
In-Reply-To: <20210927220157.1069658-1-mcgrof@kernel.org>
We never checked for errors on add_disk() as this function
returned void. Now that this is fixed, use the shiny new
error handling.
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
---
drivers/block/ps3vram.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/block/ps3vram.c b/drivers/block/ps3vram.c
index c7b19e128b03..af2a0d09c598 100644
--- a/drivers/block/ps3vram.c
+++ b/drivers/block/ps3vram.c
@@ -755,9 +755,14 @@ static int ps3vram_probe(struct ps3_system_bus_device *dev)
dev_info(&dev->core, "%s: Using %llu MiB of GPU memory\n",
gendisk->disk_name, get_capacity(gendisk) >> 11);
- device_add_disk(&dev->core, gendisk, NULL);
+ error = device_add_disk(&dev->core, gendisk, NULL);
+ if (error)
+ goto out_cleanup_disk;
+
return 0;
+out_cleanup_disk:
+ blk_cleanup_disk(gendisk);
out_cache_cleanup:
remove_proc_entry(DEVICE_NAME, NULL);
ps3vram_cache_cleanup(dev);
--
2.30.2
^ permalink raw reply related
* [PATCH v2 07/10] block/sunvdc: add error handling support for add_disk()
From: Luis Chamberlain @ 2021-09-27 22:01 UTC (permalink / raw)
To: axboe, bhelgaas, liushixin2, thunder.leizhen, lee.jones, geoff,
mpe, benh, paulus, jim, haris.iqbal, jinpu.wang, josh.h.morris,
pjk1939, tim, richard, miquel.raynal, vigneshr
Cc: linux-block, linuxppc-dev, Luis Chamberlain, linux-mtd,
linux-kernel
In-Reply-To: <20210927220157.1069658-1-mcgrof@kernel.org>
We never checked for errors on add_disk() as this function
returned void. Now that this is fixed, use the shiny new
error handling.
We re-use the same free tag call, so we also add a label for
that as well.
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
---
drivers/block/sunvdc.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/block/sunvdc.c b/drivers/block/sunvdc.c
index 4d4bb810c2ae..6f45a53f7cbf 100644
--- a/drivers/block/sunvdc.c
+++ b/drivers/block/sunvdc.c
@@ -826,8 +826,8 @@ static int probe_disk(struct vdc_port *port)
if (IS_ERR(g)) {
printk(KERN_ERR PFX "%s: Could not allocate gendisk.\n",
port->vio.name);
- blk_mq_free_tag_set(&port->tag_set);
- return PTR_ERR(g);
+ err = PTR_ERR(g);
+ goto out_free_tag;
}
port->disk = g;
@@ -879,9 +879,17 @@ static int probe_disk(struct vdc_port *port)
port->vdisk_size, (port->vdisk_size >> (20 - 9)),
port->vio.ver.major, port->vio.ver.minor);
- device_add_disk(&port->vio.vdev->dev, g, NULL);
+ err = device_add_disk(&port->vio.vdev->dev, g, NULL);
+ if (err)
+ goto out_cleanup_disk;
return 0;
+
+out_cleanup_disk:
+ blk_cleanup_disk(g);
+out_free_tag:
+ blk_mq_free_tag_set(&port->tag_set);
+ return err;
}
static struct ldc_channel_config vdc_ldc_cfg = {
--
2.30.2
^ permalink raw reply related
* [PATCH v2 02/10] pktcdvd: add error handling support for add_disk()
From: Luis Chamberlain @ 2021-09-27 22:01 UTC (permalink / raw)
To: axboe, bhelgaas, liushixin2, thunder.leizhen, lee.jones, geoff,
mpe, benh, paulus, jim, haris.iqbal, jinpu.wang, josh.h.morris,
pjk1939, tim, richard, miquel.raynal, vigneshr
Cc: linux-block, linuxppc-dev, Luis Chamberlain, linux-mtd,
linux-kernel
In-Reply-To: <20210927220157.1069658-1-mcgrof@kernel.org>
We never checked for errors on add_disk() as this function
returned void. Now that this is fixed, use the shiny new
error handling.
The out_mem2 error label already does what we need so
re-use that.
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
---
drivers/block/pktcdvd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
index 0f26b2510a75..415248962e67 100644
--- a/drivers/block/pktcdvd.c
+++ b/drivers/block/pktcdvd.c
@@ -2729,7 +2729,9 @@ static int pkt_setup_dev(dev_t dev, dev_t* pkt_dev)
/* inherit events of the host device */
disk->events = pd->bdev->bd_disk->events;
- add_disk(disk);
+ ret = add_disk(disk);
+ if (ret)
+ goto out_mem2;
pkt_sysfs_dev_new(pd);
pkt_debugfs_dev_new(pd);
--
2.30.2
^ permalink raw reply related
* [PATCH v2 08/10] block/sx8: add error handling support for add_disk()
From: Luis Chamberlain @ 2021-09-27 22:01 UTC (permalink / raw)
To: axboe, bhelgaas, liushixin2, thunder.leizhen, lee.jones, geoff,
mpe, benh, paulus, jim, haris.iqbal, jinpu.wang, josh.h.morris,
pjk1939, tim, richard, miquel.raynal, vigneshr
Cc: linux-block, linuxppc-dev, Luis Chamberlain, linux-mtd,
linux-kernel
In-Reply-To: <20210927220157.1069658-1-mcgrof@kernel.org>
We never checked for errors on add_disk() as this function
returned void. Now that this is fixed, use the shiny new
error handling.
A completion is used to notify the initial probe what is
happening and so we must defer error handling on completion.
Do this by remembering the error and using the shared cleanup
function.
The tags are shared and so are hanlded later for the
driver already.
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
---
drivers/block/sx8.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/block/sx8.c b/drivers/block/sx8.c
index 420cd952ddc4..1c79248c4826 100644
--- a/drivers/block/sx8.c
+++ b/drivers/block/sx8.c
@@ -297,6 +297,7 @@ struct carm_host {
struct work_struct fsm_task;
+ int probe_err;
struct completion probe_comp;
};
@@ -1181,8 +1182,11 @@ static void carm_fsm_task (struct work_struct *work)
struct gendisk *disk = port->disk;
set_capacity(disk, port->capacity);
- add_disk(disk);
- activated++;
+ host->probe_err = add_disk(disk);
+ if (!host->probe_err)
+ activated++;
+ else
+ break;
}
printk(KERN_INFO DRV_NAME "(%s): %d ports activated\n",
@@ -1192,11 +1196,9 @@ static void carm_fsm_task (struct work_struct *work)
reschedule = 1;
break;
}
-
case HST_PROBE_FINISHED:
complete(&host->probe_comp);
break;
-
case HST_ERROR:
/* FIXME: TODO */
break;
@@ -1507,7 +1509,10 @@ static int carm_init_one (struct pci_dev *pdev, const struct pci_device_id *ent)
goto err_out_free_irq;
DPRINTK("waiting for probe_comp\n");
+ host->probe_err = -ENODEV;
wait_for_completion(&host->probe_comp);
+ if (host->probe_err)
+ goto err_out_free_irq;
printk(KERN_INFO "%s: pci %s, ports %d, io %llx, irq %u, major %d\n",
host->name, pci_name(pdev), (int) CARM_MAX_PORTS,
--
2.30.2
^ permalink raw reply related
* Re: [PATCH v2 00/10] block: fourth batch of add_disk() error handling conversions
From: Jens Axboe @ 2021-09-27 22:31 UTC (permalink / raw)
To: Luis Chamberlain, bhelgaas, liushixin2, thunder.leizhen,
lee.jones, geoff, mpe, benh, paulus, jim, haris.iqbal, jinpu.wang,
josh.h.morris, pjk1939, tim, richard, miquel.raynal, vigneshr
Cc: linux-block, linuxppc-dev, linux-mtd, linux-kernel
In-Reply-To: <20210927220157.1069658-1-mcgrof@kernel.org>
On 9/27/21 4:01 PM, Luis Chamberlain wrote:
> This is the fourth batch of add_disk() error handling driver
> conversions. This set along with the entire 7 set of driver conversions
> can be found on my 20210927-for-axboe-add-disk-error-handling branch
> [0].
Applied 1-2, 6, 8-9, thanks.
--
Jens Axboe
^ permalink raw reply
* Re: [RFC PATCH 4/8] powerpc: add CPU field to struct thread_info
From: Michael Ellerman @ 2021-09-27 23:13 UTC (permalink / raw)
To: Ard Biesheuvel, Linux Kernel Mailing List
Cc: Peter Zijlstra, Catalin Marinas, Paul Mackerras, linux-riscv,
Will Deacon, open list:S390, Arnd Bergmann, Russell King,
Christian Borntraeger, Ingo Molnar, Albert Ou, Kees Cook,
Vasily Gorbik, Heiko Carstens, Keith Packard, Borislav Petkov,
Andy Lutomirski, Paul Walmsley, Thomas Gleixner, Linux ARM,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), Palmer Dabbelt,
Linus Torvalds
In-Reply-To: <CAMj1kXEojbQbNzCP39KT4EzFAyW3J1Tfm_stCZ+fGo8_SO90PA@mail.gmail.com>
Ard Biesheuvel <ardb@kernel.org> writes:
> On Tue, 14 Sept 2021 at 14:11, Ard Biesheuvel <ardb@kernel.org> wrote:
>>
>> The CPU field will be moved back into thread_info even when
>> THREAD_INFO_IN_TASK is enabled, so add it back to powerpc's definition
>> of struct thread_info.
>>
>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>
> Michael,
>
> Do you have any objections or issues with this patch or the subsequent
> ones cleaning up the task CPU kludge for ppc32? Christophe indicated
> that he was happy with it.
No objections, it looks good to me, thanks for cleaning up that horror :)
It didn't apply cleanly to master so I haven't tested it at all, if you can point me at a
git tree with the dependencies I'd be happy to run some tests over it.
cheers
^ permalink raw reply
* Re: [PATCH v2 1/9] cxl: Convert "RBI" to enum
From: Dan Williams @ 2021-09-27 23:13 UTC (permalink / raw)
To: Ben Widawsky
Cc: Andrew Donnellan, Linux PCI, linuxppc-dev, linux-cxl,
open list:DMA MAPPING HELPERS, Bjorn Helgaas, David E. Box,
Frederic Barrat, Lu Baolu, David Woodhouse, Kan Liang
In-Reply-To: <20210923172647.72738-2-ben.widawsky@intel.com>
Please spell out "register block indicator" in the subject so that the
shortlog remains somewhat readable.
On Thu, Sep 23, 2021 at 10:27 AM Ben Widawsky <ben.widawsky@intel.com> wrote:
>
> In preparation for passing around the Register Block Indicator (RBI) as
> a parameter, it is desirable to convert the type to an enum so that the
> interface can use a well defined type checked parameter.
C wouldn't type check this unless it failed an integer conversion,
right? It would need to be a struct to get useful type checking.
I don't mind this for the self documenting properties it has for the
functions that will take this as a parameter, but maybe clarify what
you mean by type checked parameter?
>
> As a result of this change, should future versions of the spec add
> sparsely defined identifiers, it could become a problem if checking for
> invalid identifiers since the code currently checks for the max
> identifier. This is not an issue with current spec, and the algorithm to
> obtain the register blocks will change before those possible additions
> are made.
In general let's not spend changelog space trying to guess what future
specs may or may not do. I.e. I think this text can be dropped,
especially because enums can support sparse number spaces.
^ permalink raw reply
* Re: [PATCH] powerpc/40x: Map 32Mbytes of memory at startup
From: cp @ 2021-09-28 0:07 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <e2b142ad4a44535d5aa81b0c00c5f05f312f9097.1632738876.git.christophe.leroy@csgroup.eu>
hi,
this is my second patch-test report.
Today I have successfully tested Christophe Leroy's patch.
Attached a cleaned patch. With the previous one the kernel booted, but
there was a line missing.
I have also tested two different kernels with success
both kernel sizes were ~9.4MB
the Entry Point was always 0x00901b00
used toolchain:
- powerpc-unknown-linux-gnu-binutiles-v2.34
- powerpc-unknown-linux-gnu-gcc-v9.3.0
host:
- macmini-intel, Gentoo cross-compiler, 32bit userland
target:
- AMCC PPC405GP
wrapper:
- cuboot
Applied to
- kernel-v5.2.1-vanilla
- kernel-v5.7.19-vanilla
Attached I report here is the difference between the original file and mine.
Thanks guys!
Carlo
-----------------------
map 32MB of ram rather than 16MB
--- arch/powerpc/kernel/head_40x.S.original 2021-09-28
00:07:27.768000000 -0000
+++ arch/powerpc/kernel/head_40x.S 2021-09-28 00:07:27.760000000 -0000
@@ -25,6 +25,7 @@
* Kernel execution entry point code.
*/
+
#include <linux/init.h>
#include <asm/processor.h>
#include <asm/page.h>
@@ -842,17 +843,33 @@
mtspr SPRN_PID,r0
sync
- /* Configure and load one entry into TLB slots 63 */
- clrrwi r4,r4,10 /* Mask off the real page number */
- ori r4,r4,(TLB_WR | TLB_EX) /* Set the write and execute bits */
-
- clrrwi r3,r3,10 /* Mask off the effective page number */
- ori r3,r3,(TLB_VALID | TLB_PAGESZ(PAGESZ_16M))
-
- li r0,63 /* TLB slot 63 */
-
- tlbwe r4,r0,TLB_DATA /* Load the data portion of the entry */
- tlbwe r3,r0,TLB_TAG /* Load the tag portion of the entry */
+ /*
+ * Configure and load two entries into TLB slots 62 and 63.
+ * TLB 62 is used for first 16M page
+ * TLB 63 is for the second 16M page
+ * In case we are pinning TLBs, these are reserved in by
+ * the other TLB functions.
+ * If not reserved, then it doesn't matter where they are loaded.
+ */
+ clrrwi r4,r4,10 /* Mask off the real page number */
+ ori r4,r4,(TLB_WR | TLB_EX) /* Set the write and execute bits */
+
+ clrrwi r3,r3,10 /* Mask off the effective
page number */
+ ori r3,r3,(TLB_VALID | TLB_PAGESZ(PAGESZ_16M))
+
+ li r0,62 /* TLB slot 62 */
+
+ tlbwe r4,r0,TLB_DATA /* Load the data portion of
the entry */
+ tlbwe r3,r0,TLB_TAG /* Load the tag portion of the entry */
+
+ addis r4, r4, 0x0100 /* Map next 16 Mentries */
+ addis r3, r3, 0x0100
+
+ li r0,63 /* TLB slot 63 */
+
+ /* Load up the kernel context */
+ tlbwe r4,r0,TLB_DATA /* Load the data portion of
the entry */
+ tlbwe r3,r0,TLB_TAG /* Load the tag portion of the entry */
isync
On Mon, 27 Sept 2021 at 12:35, Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
> As reported by Carlo, 16Mbytes is not enough with modern kernels
> that tend to be a bit big, so map another 16M page at boot.
^ permalink raw reply
* Re: [RFC PATCH 4/8] powerpc: add CPU field to struct thread_info
From: Michael Ellerman @ 2021-09-28 0:16 UTC (permalink / raw)
To: Ard Biesheuvel, Linux Kernel Mailing List
Cc: Peter Zijlstra, Catalin Marinas, Paul Mackerras, linux-riscv,
Will Deacon, open list:S390, Arnd Bergmann, Russell King,
Christian Borntraeger, Ingo Molnar, Albert Ou, Kees Cook,
Vasily Gorbik, Heiko Carstens, Keith Packard, Borislav Petkov,
Andy Lutomirski, Paul Walmsley, Thomas Gleixner, Linux ARM,
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), Palmer Dabbelt,
Linus Torvalds
In-Reply-To: <87ee99lii7.fsf@mpe.ellerman.id.au>
Michael Ellerman <mpe@ellerman.id.au> writes:
> Ard Biesheuvel <ardb@kernel.org> writes:
>> On Tue, 14 Sept 2021 at 14:11, Ard Biesheuvel <ardb@kernel.org> wrote:
>>>
>>> The CPU field will be moved back into thread_info even when
>>> THREAD_INFO_IN_TASK is enabled, so add it back to powerpc's definition
>>> of struct thread_info.
>>>
>>> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>>
>> Michael,
>>
>> Do you have any objections or issues with this patch or the subsequent
>> ones cleaning up the task CPU kludge for ppc32? Christophe indicated
>> that he was happy with it.
>
> No objections, it looks good to me, thanks for cleaning up that horror :)
>
> It didn't apply cleanly to master so I haven't tested it at all, if you can point me at a
> git tree with the dependencies I'd be happy to run some tests over it.
Actually I realised I can just drop the last patch.
So that looks fine, passes my standard quick build & boot on qemu tests,
and builds with/without stack protector enabled.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/40x: Map 32Mbytes of memory at startup
From: Michael Ellerman @ 2021-09-28 0:19 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: cp, linuxppc-dev, linux-kernel
In-Reply-To: <e2b142ad4a44535d5aa81b0c00c5f05f312f9097.1632738876.git.christophe.leroy@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> As reported by Carlo, 16Mbytes is not enough with modern kernels
> that tend to be a bit big, so map another 16M page at boot.
I guess we're not expecting systems with less than 32MB, so making it
unconditional is OK?
cheers
> diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S
> index 7d72ee5ab387..5fce4680d2d3 100644
> --- a/arch/powerpc/kernel/head_40x.S
> +++ b/arch/powerpc/kernel/head_40x.S
> @@ -650,7 +650,7 @@ start_here:
> b . /* prevent prefetch past rfi */
>
> /* Set up the initial MMU state so we can do the first level of
> - * kernel initialization. This maps the first 16 MBytes of memory 1:1
> + * kernel initialization. This maps the first 32 MBytes of memory 1:1
> * virtual to physical and more importantly sets the cache mode.
> */
> initial_mmu:
> @@ -687,6 +687,12 @@ initial_mmu:
> tlbwe r4,r0,TLB_DATA /* Load the data portion of the entry */
> tlbwe r3,r0,TLB_TAG /* Load the tag portion of the entry */
>
> + li r0,62 /* TLB slot 62 */
> + addis r4,r4,SZ_16M
> + addis r3,r3,SZ_16M
> + tlbwe r4,r0,TLB_DATA /* Load the data portion of the entry */
> + tlbwe r3,r0,TLB_TAG /* Load the tag portion of the entry */
> +
> isync
>
> /* Establish the exception vector base
> --
> 2.31.1
^ permalink raw reply
* Re: [PATCH] powerpc/40x: Map 32Mbytes of memory at startup
From: cp @ 2021-09-28 0:28 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <87mtnx1rhr.fsf@mpe.ellerman.id.au>
> I guess we're not expecting systems with less than 32MB, so making it
> unconditional is OK?
hi
it's not 32MB of total physical ram, but rather using 32MB of the
total physical ram to correctly boot a kernel bigger than 8MB.
The problem is complex:
- u-boot loads things at 0x0200.0000 (in my case)
- then cuboot copies the kernel to 0x0090.0000, and appends the flat
device tree to the end of kernel
- then cuboot copies again the kernel to 0x0000.0000, and invokes head.S
at this point head.S needs to initialize the virtual memory, and needs
to have 32MB mapped in order to correctly gets the flat device tree
if the kernel is smaller than 8MB, then cuboot copies it to
0x0080.0000, and head.S only need to have 16MB mapped in order to gets
the flat device tree
Cheers
^ permalink raw reply
* Re: [PATCH] powerpc: don't select KFENCE on platform PPC_FSL_BOOK3E
From: Liu Shixin @ 2021-09-28 3:06 UTC (permalink / raw)
To: Christophe Leroy, Marco Elver, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <f8d12860-56d7-5697-7cba-3cac95bb0a1c@csgroup.eu>
On 2021/9/24 14:41, Christophe Leroy wrote:
>
>
> Le 24/09/2021 à 08:39, Liu Shixin a écrit :
>> On platform PPC_FSL_BOOK3E, all lowmem is managed by tlbcam. That means
>> we didn't really map the kfence pool with page granularity. Therefore,
>> if KFENCE is enabled, the system will hit the following panic:
>
> Could you please explain a bit more what the problem is ?
>
> KFENCE has been implemented with the same logic as DEBUG_PAGEALLOC.
>
> DEBUG_PAGEALLOC is enabled on FSL_BOOK3E.
>
> In MMU_setup(), __map_without_ltlbs is set to 1 when KFENCE is enabled.
>
> __map_without_ltlbs should disable the use of tlbcam.
>
>
> So what's wrong really ?
>
> Does DEBUG_PAGEALLOC work on FSL_BOOK3E ?
>
> Thanks
> Christophe
hi Christophe,
In the last e-mail I have said that DEBUG_PAGEALLOC works well on FSL_BOOK3E, that is wrong.
Actually, I add some printed information and find DEBUG_PAGEALLOC Skip all pages.
So neither DEBUG_PAGEALLOC nor kfence is really working.
diff --git a/mm/memory.c b/mm/memory.c
index 25fc46e87214..37fb1b14bc3f 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2564,8 +2564,10 @@ static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud,
}
do {
next = pmd_addr_end(addr, end);
- if (pmd_none(*pmd) && !create)
+ if (pmd_none(*pmd) && !create) {
+ pr_info("---------pmd_none----------\n");
continue;
+ }
if (WARN_ON_ONCE(pmd_leaf(*pmd)))
return -EINVAL;
if (!pmd_none(*pmd) && WARN_ON_ONCE(pmd_bad(*pmd))) {
>
>>
>> BUG: Kernel NULL pointer dereference on read at 0x00000000
>> Faulting instruction address: 0xc01de598
>> Oops: Kernel access of bad area, sig: 11 [#1]
>> BE PAGE_SIZE=4K SMP NR_CPUS=4 MPC8544 DS
>> Dumping ftrace buffer:
>> (ftrace buffer empty)
>> Modules linked in:
>> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.12.0-rc3+ #298
>> NIP: c01de598 LR: c08ae9c4 CTR: 00000000
>> REGS: c0b4bea0 TRAP: 0300 Not tainted (5.12.0-rc3+)
>> MSR: 00021000 <CE,ME> CR: 24000228 XER: 20000000
>> DEAR: 00000000 ESR: 00000000
>> GPR00: c08ae9c4 c0b4bf60 c0ad64e0 ef720000 00021000 00000000 00000000 00000200
>> GPR08: c0ad5000 00000000 00000000 00000004 00000000 008fbb30 00000000 00000000
>> GPR16: 00000000 00000000 00000000 00000000 c0000000 00000000 00000000 00000000
>> GPR24: c08ca004 c08ca004 c0b6a0e0 c0b60000 c0b58f00 c0850000 c08ca000 ef720000
>> NIP [c01de598] kfence_protect+0x44/0x6c
>> LR [c08ae9c4] kfence_init+0xfc/0x2a4
>> Call Trace:
>> [c0b4bf60] [efffe160] 0xefffe160 (unreliable)
>> [c0b4bf70] [c08ae9c4] kfence_init+0xfc/0x2a4
>> [c0b4bfb0] [c0894d3c] start_kernel+0x3bc/0x574
>> [c0b4bff0] [c0000470] set_ivor+0x14c/0x188
>> Instruction dump:
>> 7c0802a6 8109d594 546a653a 90010014 54630026 39200000 7d48502e 2c0a0000
>> 41820010 554a0026 5469b53a 7d295214 <81490000> 38831000 554a003c 91490000
>> random: get_random_bytes called from print_oops_end_marker+0x40/0x78 with crng_init=0
>> ---[ end trace 0000000000000000 ]---
>>
>> Signed-off-by: Liu Shixin <liushixin2@huawei.com>
>> ---
>> arch/powerpc/Kconfig | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> index d46db0bfb998..cffd57bcb5e4 100644
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -185,7 +185,7 @@ config PPC
>> select HAVE_ARCH_KASAN if PPC32 && PPC_PAGE_SHIFT <= 14
>> select HAVE_ARCH_KASAN_VMALLOC if PPC32 && PPC_PAGE_SHIFT <= 14
>> select HAVE_ARCH_KGDB
>> - select HAVE_ARCH_KFENCE if PPC32
>> + select HAVE_ARCH_KFENCE if PPC32 && !PPC_FSL_BOOK3E
>> select HAVE_ARCH_MMAP_RND_BITS
>> select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
>> select HAVE_ARCH_NVRAM_OPS
>>
> .
>
^ permalink raw reply related
* Re: [PATCH v2 6/9] PCI: Add pci_find_dvsec_capability to find designated VSEC
From: Andrew Donnellan @ 2021-09-28 5:50 UTC (permalink / raw)
To: Ben Widawsky, linux-cxl
Cc: linux-pci, Frederic Barrat, iommu, Bjorn Helgaas, David E . Box,
Jonathan Cameron, Bjorn Helgaas, Dan Williams, Kan Liang,
linuxppc-dev, David Woodhouse, Lu Baolu
In-Reply-To: <20210923172647.72738-7-ben.widawsky@intel.com>
On 24/9/21 3:26 am, Ben Widawsky wrote:
> Add pci_find_dvsec_capability to locate a Designated Vendor-Specific
> Extended Capability with the specified DVSEC ID.
>
> The Designated Vendor-Specific Extended Capability (DVSEC) allows one or
> more vendor specific capabilities that aren't tied to the vendor ID of
> the PCI component.
>
> DVSEC is critical for both the Compute Express Link (CXL) driver as well
> as the driver for OpenCAPI coherent accelerator (OCXL).
>
> Cc: David E. Box <david.e.box@linux.intel.com>
> Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: linux-pci@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: Andrew Donnellan <ajd@linux.ibm.com>
> Cc: Lu Baolu <baolu.lu@linux.intel.com>
> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
Looks good to me, it's essentially identical to the existing
implementation in ocxl.
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH v2 8/9] ocxl: Use pci core's DVSEC functionality
From: Andrew Donnellan @ 2021-09-28 5:52 UTC (permalink / raw)
To: Ben Widawsky, linux-cxl
Cc: David Woodhouse, iommu, Bjorn Helgaas, David E. Box, linux-pci,
Frederic Barrat, Lu Baolu, linuxppc-dev, Kan Liang
In-Reply-To: <20210923172647.72738-9-ben.widawsky@intel.com>
On 24/9/21 3:26 am, Ben Widawsky wrote:
> Reduce maintenance burden of DVSEC query implementation by using the
> centralized PCI core implementation.
>
> There are two obvious places to simply drop in the new core
> implementation. There remains find_dvsec_from_pos() which would benefit
> from using a core implementation. As that change is less trivial it is
> reserved for later.
>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: Andrew Donnellan <ajd@linux.ibm.com>
> Acked-by: Frederic Barrat <fbarrat@linux.ibm.com> (v1)
> Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
Looks fine, but we should clean up find_dvsec_from_pos() afterwards.
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* [PATCH v2 4/4] s390: Use generic version of arch_is_kernel_initmem_freed()
From: Christophe Leroy @ 2021-09-28 7:15 UTC (permalink / raw)
To: Andrew Morton, arnd
Cc: linux-arch, linux-s390, linux-kernel, linux-mm, Gerald Schaefer,
linuxppc-dev
In-Reply-To: <ffa99e8e91e756b081427b27e408f275b7d43df7.1632813331.git.christophe.leroy@csgroup.eu>
Generic version of arch_is_kernel_initmem_freed() now does the same
as s390 version.
Remove the s390 version.
Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
v2: No change
---
arch/s390/include/asm/sections.h | 12 ------------
arch/s390/mm/init.c | 3 ---
2 files changed, 15 deletions(-)
diff --git a/arch/s390/include/asm/sections.h b/arch/s390/include/asm/sections.h
index 85881dd48022..3fecaa4e8b74 100644
--- a/arch/s390/include/asm/sections.h
+++ b/arch/s390/include/asm/sections.h
@@ -2,20 +2,8 @@
#ifndef _S390_SECTIONS_H
#define _S390_SECTIONS_H
-#define arch_is_kernel_initmem_freed arch_is_kernel_initmem_freed
-
#include <asm-generic/sections.h>
-extern bool initmem_freed;
-
-static inline int arch_is_kernel_initmem_freed(unsigned long addr)
-{
- if (!initmem_freed)
- return 0;
- return addr >= (unsigned long)__init_begin &&
- addr < (unsigned long)__init_end;
-}
-
/*
* .boot.data section contains variables "shared" between the decompressor and
* the decompressed kernel. The decompressor will store values in them, and
diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
index a04faf49001a..8c6f258a6183 100644
--- a/arch/s390/mm/init.c
+++ b/arch/s390/mm/init.c
@@ -58,8 +58,6 @@ unsigned long empty_zero_page, zero_page_mask;
EXPORT_SYMBOL(empty_zero_page);
EXPORT_SYMBOL(zero_page_mask);
-bool initmem_freed;
-
static void __init setup_zero_pages(void)
{
unsigned int order;
@@ -214,7 +212,6 @@ void __init mem_init(void)
void free_initmem(void)
{
- initmem_freed = true;
__set_memory((unsigned long)_sinittext,
(unsigned long)(_einittext - _sinittext) >> PAGE_SHIFT,
SET_MEMORY_RW | SET_MEMORY_NX);
--
2.31.1
^ permalink raw reply related
* [PATCH v2 3/4] powerpc: Use generic version of arch_is_kernel_initmem_freed()
From: Christophe Leroy @ 2021-09-28 7:15 UTC (permalink / raw)
To: Andrew Morton, arnd
Cc: linux-arch, linux-s390, linux-kernel, linux-mm, linuxppc-dev
In-Reply-To: <ffa99e8e91e756b081427b27e408f275b7d43df7.1632813331.git.christophe.leroy@csgroup.eu>
Generic version of arch_is_kernel_initmem_freed() now does the same
as powerpc version.
Remove the powerpc version.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
v2: No change
---
arch/powerpc/include/asm/sections.h | 13 -------------
1 file changed, 13 deletions(-)
diff --git a/arch/powerpc/include/asm/sections.h b/arch/powerpc/include/asm/sections.h
index 6e4af4492a14..79cb7a25a5fb 100644
--- a/arch/powerpc/include/asm/sections.h
+++ b/arch/powerpc/include/asm/sections.h
@@ -6,21 +6,8 @@
#include <linux/elf.h>
#include <linux/uaccess.h>
-#define arch_is_kernel_initmem_freed arch_is_kernel_initmem_freed
-
#include <asm-generic/sections.h>
-extern bool init_mem_is_free;
-
-static inline int arch_is_kernel_initmem_freed(unsigned long addr)
-{
- if (!init_mem_is_free)
- return 0;
-
- return addr >= (unsigned long)__init_begin &&
- addr < (unsigned long)__init_end;
-}
-
extern char __head_end[];
#ifdef __powerpc64__
--
2.31.1
^ permalink raw reply related
* [PATCH v2 1/4] mm: Create a new system state and fix core_kernel_text()
From: Christophe Leroy @ 2021-09-28 7:15 UTC (permalink / raw)
To: Andrew Morton, arnd
Cc: linux-arch, linux-s390, linux-kernel, linux-mm, Gerald Schaefer,
linuxppc-dev
core_kernel_text() considers that until system_state in at least
SYSTEM_RUNNING, init memory is valid.
But init memory is freed a few lines before setting SYSTEM_RUNNING,
so we have a small period of time when core_kernel_text() is wrong.
Create an intermediate system state called SYSTEM_FREEING_INIT that
is set before starting freeing init memory, and use it in
core_kernel_text() to report init memory invalid earlier.
Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
v2: New
---
include/linux/kernel.h | 1 +
init/main.c | 2 ++
kernel/extable.c | 2 +-
3 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 2776423a587e..471bc0593679 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -248,6 +248,7 @@ extern bool early_boot_irqs_disabled;
extern enum system_states {
SYSTEM_BOOTING,
SYSTEM_SCHEDULING,
+ SYSTEM_FREEING_INITMEM,
SYSTEM_RUNNING,
SYSTEM_HALT,
SYSTEM_POWER_OFF,
diff --git a/init/main.c b/init/main.c
index 3f7216934441..c457d393fdd4 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1505,6 +1505,8 @@ static int __ref kernel_init(void *unused)
kernel_init_freeable();
/* need to finish all async __init code before freeing the memory */
async_synchronize_full();
+
+ system_state = SYSTEM_FREEING_INITMEM;
kprobe_free_init_mem();
ftrace_free_init_mem();
kgdb_free_init_mem();
diff --git a/kernel/extable.c b/kernel/extable.c
index b0ea5eb0c3b4..290661f68e6b 100644
--- a/kernel/extable.c
+++ b/kernel/extable.c
@@ -76,7 +76,7 @@ int notrace core_kernel_text(unsigned long addr)
addr < (unsigned long)_etext)
return 1;
- if (system_state < SYSTEM_RUNNING &&
+ if (system_state < SYSTEM_FREEING_INITMEM &&
init_kernel_text(addr))
return 1;
return 0;
--
2.31.1
^ permalink raw reply related
* [PATCH v2 2/4] mm: Make generic arch_is_kernel_initmem_freed() do what it says
From: Christophe Leroy @ 2021-09-28 7:15 UTC (permalink / raw)
To: Andrew Morton, arnd
Cc: linux-arch, linux-s390, linux-kernel, linux-mm, Gerald Schaefer,
linuxppc-dev
In-Reply-To: <ffa99e8e91e756b081427b27e408f275b7d43df7.1632813331.git.christophe.leroy@csgroup.eu>
Commit 7a5da02de8d6 ("locking/lockdep: check for freed initmem in
static_obj()") added arch_is_kernel_initmem_freed() which is supposed
to report whether an object is part of already freed init memory.
For the time being, the generic version of arch_is_kernel_initmem_freed()
always reports 'false', allthough free_initmem() is generically called
on all architectures.
Therefore, change the generic version of arch_is_kernel_initmem_freed()
to check whether free_initmem() has been called. If so, then check
if a given address falls into init memory.
In order to use function init_section_contains(), the fonction is
moved at the end of asm-generic/section.h
Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
v2: Change to using the new SYSTEM_FREEING_INITMEM state
---
include/asm-generic/sections.h | 31 +++++++++++++++++--------------
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
index d16302d3eb59..13f301239007 100644
--- a/include/asm-generic/sections.h
+++ b/include/asm-generic/sections.h
@@ -80,20 +80,6 @@ static inline int arch_is_kernel_data(unsigned long addr)
}
#endif
-/*
- * Check if an address is part of freed initmem. This is needed on architectures
- * with virt == phys kernel mapping, for code that wants to check if an address
- * is part of a static object within [_stext, _end]. After initmem is freed,
- * memory can be allocated from it, and such allocations would then have
- * addresses within the range [_stext, _end].
- */
-#ifndef arch_is_kernel_initmem_freed
-static inline int arch_is_kernel_initmem_freed(unsigned long addr)
-{
- return 0;
-}
-#endif
-
/**
* memory_contains - checks if an object is contained within a memory region
* @begin: virtual address of the beginning of the memory region
@@ -172,4 +158,21 @@ static inline bool is_kernel_rodata(unsigned long addr)
addr < (unsigned long)__end_rodata;
}
+/*
+ * Check if an address is part of freed initmem. This is needed on architectures
+ * with virt == phys kernel mapping, for code that wants to check if an address
+ * is part of a static object within [_stext, _end]. After initmem is freed,
+ * memory can be allocated from it, and such allocations would then have
+ * addresses within the range [_stext, _end].
+ */
+#ifndef arch_is_kernel_initmem_freed
+static inline int arch_is_kernel_initmem_freed(unsigned long addr)
+{
+ if (system_state < SYSTEM_FREEING_INITMEM)
+ return 0;
+
+ return init_section_contains((void *)addr, 1);
+}
+#endif
+
#endif /* _ASM_GENERIC_SECTIONS_H_ */
--
2.31.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox