public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Aleksander Sanochkin <asanochkin@Lnxw.COM>
Cc: linux-mtd@lists.infradead.org, jffs-dev@axis.com
Subject: Re: JFFS1/MTD bug-fixes
Date: Sat, 01 Dec 2001 10:47:21 +0000	[thread overview]
Message-ID: <17628.1007203641@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0111300926130.13550-200000@newbast.lynuxworks.com>

> --- cvs/drivers/mtd/chips/cfi_cmdset_0002.c	Wed Oct 24 13:37:30 2001
> +++ other/drivers/mtd/chips/cfi_cmdset_0002.c	Wed Nov 21 12:58:47 2001
> @@ -162,10 +162,7 @@
>  	/* Also select the correct geometry setup too */ 
>  	mtd->size = devsize * cfi->numchips;
>  	
> -	if (cfi->cfiq->NumEraseRegions == 1) {
> -		/* No need to muck about with multiple erase sizes */
> -		mtd->erasesize = ((cfi->cfiq->EraseRegionInfo[0] >> 8) & ~0xff) * cfi->interleave;
> -	} else {
> +	{
>  		unsigned long offset = 0;
>  		int i,j;

Why do we need this? If NumEraseRegions is one (or zero, for that matter), 
we don't need to allocate the structure containing the region information, 
as the whole device is known to have the same 'major' erasesize.

>     mtd_info = (struct mtd_info *)kmalloc(sizeof(struct mtd_info), GFP_KERNEL);
>     if (!mtd_info)
> -      return 0;
> +      return -ENOMEM;

Applied.

>  	default:
>  		DEBUG(MTD_DEBUG_LEVEL0, "Invalid ioctl %x (MEMGETINFO = %x)\n", cmd, MEMGETINFO);
> -		ret = -ENOTTY;
> +		ret = -ENOIOCTLCMD;

Strange though it may seem, I thought -ENOTTY was correct there. 

       ENOTTY The specified request does not apply to the kind of
              object that the descriptor d references.

> +			if (mtd->usage_counter)
> +			{
> +				up(&mtd_table_mutex);
> +				return -EBUSY;
> +			}

Do we need to provide this in the kernel? I can see it protects against 
user error, but that isn't necessarily the kernel's job. Am I missing 
another need for it?

> --- cvs/fs/jffs/inode-v23.c	Tue Oct  2 13:16:02 2001
> +++ other/fs/jffs/inode-v23.c	Wed Nov 21 18:36:46 2001
> @@ -137,10 +137,22 @@
>  	if (c->gc_maxdirty_threshold < c->fmc->sector_size)
>  		c->gc_maxdirty_threshold = c->fmc->sector_size;
>  
> +	init_completion(&c->gc_thread_comp);
> +	c->gc_task = 0;

Agreed. The existing code is racy. 

> +	while (! c->gc_task)
> +	{
> +		schedule();
> +	}

Better to do this with a semaphore. Start it locked, have the GC thread 
call up(), and this code wait in down(). 

The rest of the JFFS changes look sane. Would you be happy to take over 
maintenance of JFFS1?

--
dwmw2

  reply	other threads:[~2001-12-01 10:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-30 17:29 JFFS1/MTD bug-fixes Aleksander Sanochkin
2001-12-01 10:47 ` David Woodhouse [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-12-03 15:36 Aleksander Sanochkin
2001-12-03 15:55 ` David Woodhouse
2001-12-04  9:07   ` Jörn Engel
2001-12-04 16:30 Aleksander Sanochkin
2001-12-04 22:44 ` Jörn Engel
2001-12-04 16:36 Aleksander Sanochkin
2001-12-04 22:18 ` Jörn Engel
2001-12-07 13:07 Aleksander Sanochkin
2001-12-07 15:40 ` Jörn Engel
2001-12-07 13:11 Aleksander Sanochkin
2001-12-07 15:34 ` Jörn Engel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17628.1007203641@redhat.com \
    --to=dwmw2@infradead.org \
    --cc=asanochkin@Lnxw.COM \
    --cc=jffs-dev@axis.com \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox