linux-kernel - Re: [PATCH 2.6.20-rc5] SPI: alternative fix for spi_busnum_to

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <200701231543.56669.david-b@pacbell.net>
Date:	Tue, 23 Jan 2007 15:43:56 -0800
From:	David Brownell <david-b@...bell.net>
To:	Atsushi Nemoto <anemo@....ocn.ne.jp>
Cc:	linux-kernel@...r.kernel.org, hcegtvedt@...el.com, akpm@...l.org
Subject: Re: [PATCH 2.6.20-rc5] SPI: alternative fix for spi_busnum_to_master

On Tuesday 23 January 2007 8:07 am, Atsushi Nemoto wrote:
> On Tue, 23 Jan 2007 07:42:15 -0800, David Brownell <david-b@...bell.net> wrote:
> > > Indeed the check can be omitted.  Should I send a new patch just
> > > moving class_device_get() into "if (master->bus_num == bus_num)"
> > > block?
> > 
> > Yes, please.
> 
> OK, here is.  This patch uses spi_master_get() instead of
> class_device_get().

Much better.  This should be merged for 2.6.20 ...

> 
> 
> Subject: SPI: alternative fix for spi_busnum_to_master
> 
> If a SPI master device exists, udev (udevtrigger) causes kernel crash,
> due to wrong kobj pointer in kobject_uevent_env().  This problem was
> not in 2.6.19.
> 
> The backtrace (on MIPS) was:
> [<8024db6c>] kobject_uevent_env+0x54c/0x5e8
> [<802a8264>] store_uevent+0x1c/0x3c  (in drivers/class.c)
> [<801cb14c>] subsys_attr_store+0x2c/0x50
> [<801cb80c>] flush_write_buffer+0x38/0x5c
> [<801cb900>] sysfs_write_file+0xd0/0x190
> [<80181444>] vfs_write+0xc4/0x1a0
> [<80181cdc>] sys_write+0x54/0xa0
> [<8010dae4>] stack_done+0x20/0x3c
> 
> flush_write_buffer() passes kobject of spi_master_class.subsys to
> subsys_addr_store(), then subsys_addr_store() passes a pointer to a
> struct subsystem to store_uevent() which expects a pointer to a struct
> class_device.  The problem seems subsys_attr_store() called instead of
> class_device_attr_store().
> 
> This mismatch was caused by commit
> 3bd0f6943520e459659d10f3282285e43d3990f1, which overrides kset of
> master class.  This made spi_master_class.subsys.kset.ktype NULL so
> subsys_sysfs_ops is used instead of class_dev_sysfs_ops.
> 
> The commit was to fix spi_busnum_to_master().  Here is a patch fixes
> this function in other way, just searching children list of
> class_device.
> 
> Signed-off-by: Atsushi Nemoto <anemo@....ocn.ne.jp>
> ---
> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index 270e621..6307428 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -366,7 +366,6 @@ spi_alloc_master(struct device *dev, uns
>  
>  	class_device_initialize(&master->cdev);
>  	master->cdev.class = &spi_master_class;
> -	kobj_set_kset_s(&master->cdev, spi_master_class.subsys);
>  	master->cdev.dev = get_device(dev);
>  	spi_master_set_devdata(master, &master[1]);
>  
> @@ -466,14 +465,20 @@ EXPORT_SYMBOL_GPL(spi_unregister_master)
>   */
>  struct spi_master *spi_busnum_to_master(u16 bus_num)
>  {
> -	char			name[9];
> -	struct kobject		*bus;
> -
> -	snprintf(name, sizeof name, "spi%u", bus_num);
> -	bus = kset_find_obj(&spi_master_class.subsys.kset, name);
> -	if (bus)
> -		return container_of(bus, struct spi_master, cdev.kobj);
> -	return NULL;
> +	struct class_device	*cdev;
> +	struct spi_master	*master = NULL;
> +	struct spi_master	*m;
> +
> +	down(&spi_master_class.sem);
> +	list_for_each_entry(cdev, &spi_master_class.children, node) {
> +		m = container_of(cdev, struct spi_master, cdev);
> +		if (m->bus_num == bus_num) {
> +			master = spi_master_get(m);
> +			break;
> +		}
> +	}
> +	up(&spi_master_class.sem);
> +	return master;
>  }
>  EXPORT_SYMBOL_GPL(spi_busnum_to_master);
>  
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/