Ben Shelton | 31 Oct 19:50 2014

[PATCH 0/4] UBIFS: add xattr support for security / SELinux

I'm reposting the patch series for security xattr / SELinux support on UBIFS
from Subodh Nijsure and Marc Kleine-Budde [1] in order to restart the process
of getting this support upstream.

Notes:

 - I removed 'UBIFS: xattr: protect ui_size and data_len by ui_mutex' because
   after looking through the comments before the definition of struct
   ubifs_inode, I'm not sure what this was intended to fix.  It looks like
   i_size and data_len are not intended to be protected by ui_mutex, and I'm
   unclear on why ui->ui_size needs to be protected here by host_ui's ui_mutex.
   CCing Marc -- could you comment on how this is supposed to work?

 - I made the suggested locking fixes in [2], with the exception of removing the
   i_mutex lock/unlock around the call to security_inode_init_security(), which 
   caused an assert.  With these fixes, I turned on lockdep and ran with SELinux
   enabled on an ARM-based embedded target using UBIFS, and I saw no lockdep
   warnings during filesystem labeling and normal operation.

[1] http://lists.infradead.org/pipermail/linux-mtd/2013-February/045794.html
[2] http://lists.infradead.org/pipermail/linux-mtd/2013-February/045871.html

Subodh Nijsure (4):
  UBIFS: fix a couple bugs in UBIFS xattr length calculation
  UBIFS: Add xattr support for symlinks
  UBIFS: Add security.* XATTR support for the UBIFS
  UBIFS: add ubifs_err() to print error reason

 fs/ubifs/dir.c     |  20 +++++++++
 fs/ubifs/file.c    |   4 ++
(Continue reading)

hujianyang | 31 Oct 11:36 2014

Report: mtd-utils: "Floating point exception" with ubiformat

Hi,

Here is an interesting problem. I used a nand flash driver with
wrong partition table and an error like this occurred:

# insmod nandflash.ko

[454096.098834] mtd: partition "ubi1" is out of reach -- disabled

The display of /proc/mtd shows the size of mtd1 is zero:

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 20000000 00020000 "ubi0"
mtd1: 00000000 00000000 "ubi1"
mtd2: 20000000 00020000 "rest"

When performing ubiformat with this mtd1, the utility breaks
down with a message:

# ubiformat /dev/mtd1
Floating point exception

I used to think it is because ubiformat can't deal with a zero
size MTD device. So I want to add something like a error branch
for this. But now I find it is because the "erasesize" in
"/sys/class/mtd/mtd1" is zero.

:/sys/class/mtd/mtd1# cat erasesize
0
(Continue reading)

Tarzon, Megan | 30 Oct 10:26 2014

RE:


________________________________
From: Tarzon, Megan
Sent: Thursday, October 30, 2014 12:40 AM
To: Tarzon, Megan
Subject:

Good day.
l am the Chief Risk Officer and Executive Director of China Guangfa Bank in Hong Kong. I want to present you as
the owner of 49.5 million USD In my bank since i am the only one aware of the funds due to my investigations.
signify your interest by replying to this Email: morrowhkmorro1 <at> rogers.com
James Morrow.

CONFIDENTIALITY NOTICE: This communication and any attachments may contain confidential or privileged
information for the use by the designated recipient(s) named above.   If you are not the intended
recipient, you are hereby notified that you have received this communication in error and that any
review, disclosure, dissemination, distribution or copying of it or the attachments is strictly
prohibited.  If you have received this communication in error, please contact the sender  and destroy all
copies of the communication and attachments.  Thank you. MSG:104-123

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Karsten Jeppesen | 30 Oct 09:19 2014
Picon

libscan: warning!: inconsistent VID header offset

Hi Guys,

Can one of you set my head straight please?
When using ubinize to create an image for ubiformat to flash, it goes south.
Here is what I don't understand:
- How come the LEB size is so small when using a simple ubiformat
- Why does it differ from that calculated by ubinize? (ubiformat: 126976; ubinize: 130944)

Mtdinfo:
mtd0
Name:                           Rootfs1
Type:                           nand
Eraseblock size:                131072 bytes, 128.0 KiB
Amount of eraseblocks:          4096 (536870912 bytes, 512.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:                  2048 bytes
OOB size:                       64 bytes
Character device major/minor:   90:0
Bad blocks are allowed:         true
Device is writable:             true

A non-image format says:
# ubiformat /dev/mtd0
ubiformat: mtd0 (nand), size 536870912 bytes (512.0 MiB), 4096 eraseblocks of 131072 bytes (128.0 KiB),
min. I/O size 2048 bytes
libscan: scanning eraseblock 4095 -- 100 % complete
ubiformat: 4092 eraseblocks have valid erase counter, mean value is 2
ubiformat: 4 bad eraseblocks found, numbers: 4092, 4093, 4094, 4095
ubiformat: formatting eraseblock 4095 -- 100 % complete

(Continue reading)

Chunhe Lan | 30 Oct 04:26 2014

[PATCH v2] mtd: spi-nor: Move n25q032 entry to Micron devices list

Because n25q032 is the Micron SPI chip, move it to Micron
devices list group. In order that know which Micron SPI
chips have been support at a glance. 

Signed-off-by: Chunhe Lan <Chunhe.Lan <at> freescale.com>
Cc: Brian Norris <computersforpeace <at> gmail.com>
Cc: Marek Vasut <marex <at> denx.de>
Cc: Huang Shijie <shijie8 <at> gmail.com>
---
Changes since v1:
* Add commit message.

 drivers/mtd/spi-nor/spi-nor.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index ae16aa2..1fa5e05 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
 <at>  <at>  -530,6 +530,7  <at>  <at>  const struct spi_device_id spi_nor_ids[] = {
 	{ "mx66l1g55g",  INFO(0xc2261b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ) },

 	/* Micron */
+	{ "n25q032",	 INFO(0x20ba16, 0, 64 * 1024,   64, 0) },
 	{ "n25q064",     INFO(0x20ba17, 0, 64 * 1024,  128, 0) },
 	{ "n25q128a11",  INFO(0x20bb18, 0, 64 * 1024,  256, 0) },
 	{ "n25q128a13",  INFO(0x20ba18, 0, 64 * 1024,  256, 0) },
 <at>  <at>  -586,7 +587,6  <at>  <at>  const struct spi_device_id spi_nor_ids[] = {
 	{ "m25p32",  INFO(0x202016,  0,  64 * 1024,  64, 0) },
 	{ "m25p64",  INFO(0x202017,  0,  64 * 1024, 128, 0) },
(Continue reading)

Richard Weinberger | 29 Oct 13:45 2014
Picon

UBI Fastmap stabilization

This series brings a massive stabilization update for UBI Fastmap.
During the last weeks many issues have been identified and fixed.
Both power-cut and excessive run-time tests uncovered bugs which
got addressed. No on-disk layout change was needed.

Besides of plain bug fixes this series introduces also much better Fastmap
self checks. These can be enabled by the UBI debugfs knob "chk_fastmap".
It will enable checks which ensure that every PEB is known to Fastmap
while writing a fastmap to flash and will run an expensive check while attaching.
To have Fastmap checking enabled by default a new UBI module parameter was
added, "fm_debug". This parameter is useful for the attach self check. Upon
attach time no debugfs is available and therefore the check cannot be enabled.
The attach self check will load the fastmap data structure and will issue a full
scan to verify it. Therefore, don't enable it in production, it will make
attachment by Fastmap slow.

Power-cut related issues have been found by my power-cut emulation patches for UBI.
These patches are currently under internal review/polishing and will be published
next week.

Patch 29 to 35 are a massive cleanup as requested by Artem. It moves all Fastmap
specific code out of wl.c. Some Fastmap functions are very closely related to the WL
sub-system, these function are now in fastmap-wl.c located. The amount of Fastmap
specific #ifdefs have been reduced to a minimum.

After this series went mainline I'll create a list of stable patches and make sure
that all Fastmap fixes go into -stable.

Enjoy!
//richard
(Continue reading)

Mark Brown | 29 Oct 13:27 2014

[PATCH] mtd: dataflash: Remove use of tx_dma

We are trying to remove the legacy tx_dma and rx_dma fields from the
spi_transfer structure. Currently dataflash uses tx_dma but only to make
sure that it's set to 0 so we can remove this use by replacing with a
zero initialisation of the entire spi_transfer struct.

Signed-off-by: Mark Brown <broonie <at> kernel.org>
---
 drivers/mtd/devices/mtd_dataflash.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/devices/mtd_dataflash.c b/drivers/mtd/devices/mtd_dataflash.c
index dd22ce2cc9ad..0099aba72a8b 100644
--- a/drivers/mtd/devices/mtd_dataflash.c
+++ b/drivers/mtd/devices/mtd_dataflash.c
 <at>  <at>  -149,7 +149,7  <at>  <at>  static int dataflash_erase(struct mtd_info *mtd, struct erase_info *instr)
 {
 	struct dataflash	*priv = mtd->priv;
 	struct spi_device	*spi = priv->spi;
-	struct spi_transfer	x = { .tx_dma = 0, };
+	struct spi_transfer	x = { };
 	struct spi_message	msg;
 	unsigned		blocksize = priv->page_size << 3;
 	uint8_t			*command;
 <at>  <at>  -235,7 +235,7  <at>  <at>  static int dataflash_read(struct mtd_info *mtd, loff_t from, size_t len,
 			       size_t *retlen, u_char *buf)
 {
 	struct dataflash	*priv = mtd->priv;
-	struct spi_transfer	x[2] = { { .tx_dma = 0, }, };
+	struct spi_transfer	x[2] = { };
 	struct spi_message	msg;
(Continue reading)

Chunhe Lan | 29 Oct 10:57 2014

[PATCH] mtd: spi-nor: Move n25q032 entry to Micron devices list

Signed-off-by: Chunhe Lan <Chunhe.Lan <at> freescale.com>
Cc: Brian Norris <computersforpeace <at> gmail.com>
Cc: Marek Vasut <marex <at> denx.de>
Cc: Huang Shijie <shijie8 <at> gmail.com>
---
 drivers/mtd/spi-nor/spi-nor.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index ae16aa2..1fa5e05 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
 <at>  <at>  -530,6 +530,7  <at>  <at>  const struct spi_device_id spi_nor_ids[] = {
 	{ "mx66l1g55g",  INFO(0xc2261b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ) },

 	/* Micron */
+	{ "n25q032",	 INFO(0x20ba16, 0, 64 * 1024,   64, 0) },
 	{ "n25q064",     INFO(0x20ba17, 0, 64 * 1024,  128, 0) },
 	{ "n25q128a11",  INFO(0x20bb18, 0, 64 * 1024,  256, 0) },
 	{ "n25q128a13",  INFO(0x20ba18, 0, 64 * 1024,  256, 0) },
 <at>  <at>  -586,7 +587,6  <at>  <at>  const struct spi_device_id spi_nor_ids[] = {
 	{ "m25p32",  INFO(0x202016,  0,  64 * 1024,  64, 0) },
 	{ "m25p64",  INFO(0x202017,  0,  64 * 1024, 128, 0) },
 	{ "m25p128", INFO(0x202018,  0, 256 * 1024,  64, 0) },
-	{ "n25q032", INFO(0x20ba16,  0,  64 * 1024,  64, 0) },

 	{ "m25p05-nonjedec",  INFO(0, 0,  32 * 1024,   2, 0) },
 	{ "m25p10-nonjedec",  INFO(0, 0,  32 * 1024,   4, 0) },
--

-- 
1.7.6.5
(Continue reading)

Barthel Anna | 28 Oct 22:44 2014
Picon

Mystery shopper needed Contact <at> shopper182 <at> qq.com

Please a mystery shopper needed in your region, you can earn up to 
$150-200 per week. To learn more, contact Mark Davis at 
(shopper182 <at> qq.com) with your full name to

proceed.

Thank you,
Barthel Anna
Task Coordinator

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Stefan Wahren | 26 Oct 21:01 2014

Questions about OTP driver

Hi,

currently i try to port a driver for One Time Programmable memory pages on
Freescale MX23/MX28 (ARM9) SoC.
This driver gives readonly access to these memory pages via Sysfs.

As i created a patch RFC [1], Arnd Bergmann suggested me to move the driver to
MTD.

Now i have some questions:

1. What exact directory is suggested for OTP on SoC driver?
2. What is a good example implementaton of an OTP driver?

Best regards

Stefan Wahren

[1] -
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/295228.html

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Richard Weinberger | 25 Oct 19:43 2014
Picon

[PATCH] UBI: vtbl: Use ubi_eba_atomic_leb_change()

This is more a cosmetic change than a fix.
By using ubi_eba_atomic_leb_change()
we can guarantee that the first VTBL record is always
correct and we don't really need the second one anymore.
But we have to keep the second one to not break anything.

Signed-off-by: Richard Weinberger <richard <at> nod.at>
---
 drivers/mtd/ubi/vtbl.c | 16 ++++------------
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/mtd/ubi/vtbl.c b/drivers/mtd/ubi/vtbl.c
index 07cac5f..0d26051 100644
--- a/drivers/mtd/ubi/vtbl.c
+++ b/drivers/mtd/ubi/vtbl.c
 <at>  <at>  -96,12 +96,8  <at>  <at>  int ubi_change_vtbl_record(struct ubi_device *ubi, int idx,

 	memcpy(&ubi->vtbl[idx], vtbl_rec, sizeof(struct ubi_vtbl_record));
 	for (i = 0; i < UBI_LAYOUT_VOLUME_EBS; i++) {
-		err = ubi_eba_unmap_leb(ubi, layout_vol, i);
-		if (err)
-			return err;
-
-		err = ubi_eba_write_leb(ubi, layout_vol, i, ubi->vtbl, 0,
-					ubi->vtbl_size);
+		err = ubi_eba_atomic_leb_change(ubi, layout_vol, i, ubi->vtbl,
+						ubi->vtbl_size);
 		if (err)
 			return err;
 	}
(Continue reading)


Gmane