Instead of relying on fragile documentation which can easily let us
slip, use a symbol namespace to annotate which symbols should not be
used by others.

This ensures no other users pop up by mistake easily and provides
us a with an easy vehicle to do the same with other routines should
we need it later.

Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
---
 block/partitions/core.c         | 6 +-----
 drivers/block/loop.c            | 2 ++
 drivers/s390/block/dasd_genhd.c | 2 ++
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/block/partitions/core.c b/block/partitions/core.c
index 7b8ef6296abd..9fdb69f08f4e 100644
--- a/block/partitions/core.c
+++ b/block/partitions/core.c
@@ -698,11 +698,7 @@ int bdev_disk_changed(struct gendisk *disk, bool invalidate)
 
 	return ret;
 }
-/*
- * Only exported for loop and dasd for historic reasons.  Don't use in new
- * code!
- */
-EXPORT_SYMBOL_GPL(bdev_disk_changed);
+EXPORT_SYMBOL_NS_GPL(bdev_disk_changed, BLOCK_DEPRECATED);
 
 void *read_part_sector(struct parsed_partitions *state, sector_t n, Sector *p)
 {
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 28eb59fd71ca..2e74cd93e8eb 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -37,6 +37,8 @@
 #include <linux/spinlock.h>
 #include <uapi/linux/loop.h>
 
+MODULE_IMPORT_NS(BLOCK_DEPRECATED);
+
 /* Possible states of device */
 enum {
 	Lo_unbound,
diff --git a/drivers/s390/block/dasd_genhd.c b/drivers/s390/block/dasd_genhd.c
index 998a961e1704..5ea244aec534 100644
--- a/drivers/s390/block/dasd_genhd.c
+++ b/drivers/s390/block/dasd_genhd.c
@@ -25,6 +25,8 @@
 
 #include "dasd_int.h"
 
+MODULE_IMPORT_NS(BLOCK_DEPRECATED);
+
 static unsigned int queue_depth = 32;
 static unsigned int nr_hw_queues = 4;
 
-- 
2.39.2

On Mon, Mar 27, 2023 at 11:44:10AM -0700, Luis Chamberlain wrote:
> Instead of relying on fragile documentation which can easily let us
> slip, use a symbol namespace to annotate which symbols should not be
> used by others.
> 
> This ensures no other users pop up by mistake easily and provides
> us a with an easy vehicle to do the same with other routines should
> we need it later.

I don't think deprecated really cuts it.  For these two drivers we
can't really get rid of the calls as it is part of their ABI.

What I'd really want is something like an

EXPORT_SYMBOL_FOR(bdev_disk_changed, loop, CONFIG_BLK_DEV_LOOP);
EXPORT_SYMBOL_FOR(bdev_disk_changed, dasd_kmod, CONFIG_DASD);

Which ensures that the symbol lookup only succeeds for loop.ko and
dasd_kmod.ko, and that the export only happens if the relevant
symbols are set.

On Mon, Mar 27, 2023 at 03:16:39PM -0700, Christoph Hellwig wrote:
> On Mon, Mar 27, 2023 at 11:44:10AM -0700, Luis Chamberlain wrote:
> > Instead of relying on fragile documentation which can easily let us
> > slip, use a symbol namespace to annotate which symbols should not be
> > used by others.
> > 
> > This ensures no other users pop up by mistake easily and provides
> > us a with an easy vehicle to do the same with other routines should
> > we need it later.
> 
> I don't think deprecated really cuts it.  For these two drivers we
> can't really get rid of the calls as it is part of their ABI.

Ah yes.

> What I'd really want is something like an
> 
> EXPORT_SYMBOL_FOR(bdev_disk_changed, loop, CONFIG_BLK_DEV_LOOP);
> EXPORT_SYMBOL_FOR(bdev_disk_changed, dasd_kmod, CONFIG_DASD);
> 
> Which ensures that the symbol lookup only succeeds for loop.ko and
> dasd_kmod.ko, and that the export only happens if the relevant
> symbols are set.

I think that could be done, sure.

  Luis

On Mon, Mar 27, 2023 at 04:02:02PM -0700, Luis Chamberlain wrote:
> On Mon, Mar 27, 2023 at 03:16:39PM -0700, Christoph Hellwig wrote:
> > What I'd really want is something like an
> > 
> > EXPORT_SYMBOL_FOR(bdev_disk_changed, loop, CONFIG_BLK_DEV_LOOP);
> > EXPORT_SYMBOL_FOR(bdev_disk_changed, dasd_kmod, CONFIG_DASD);
> > 
> > Which ensures that the symbol lookup only succeeds for loop.ko and
> > dasd_kmod.ko, and that the export only happens if the relevant
> > symbols are set.
> 
> I think that could be done, sure.

BTW is anyone aware of similar exports which are stuck in this way?

  Luis

On Mon, Mar 27, 2023 at 04:08:52PM -0700, Luis Chamberlain wrote:
> BTW is anyone aware of similar exports which are stuck in this way?

We have a few in fs code.   And there's thing like all kinds of very
low-level code exported that absolutely should only be used by kvm.