Re: [RFC PATCH-tip v4 02/10] locking/rwsem: Stop active read lock ASAP

[Christoph Hellwig]

On Wed, Oct 12, 2016 at 08:06:40AM +1100, Dave Chinner wrote:
> Um, I seem to have completely missed that change - when did that
> happen and why?
> 
> Oh, it was part of the misguided "enable DAX on block devices"
> changes -

o, that commit just switched it to use ->f_mapping:

-   return (filp->f_flags & O_DIRECT) || IS_DAX(file_inode(filp));
+   return (filp->f_flags & O_DIRECT) || IS_DAX(filp->f_mapping->host);

The original version of it goes all the way back to introducing the
current-day DAX code in d475c6346 ("dax,ext2: replace XIP read and write
with DAX I/O");

> Hence I'd suggest that DAX check in io_is_direct() should be removed
> ASAP; the filesystems don't need it as they check the inode DAX
> state directly, and the code it "fixed" is no longer in the tree.

As long as ext4 still uses the overloaded direct_IO we need the
checks for DAX in the filemap.c generic read/write code.  It seems
like that's only two spots anyway, but I'd feel much safer once ext4
is switched over to the iomap version of the dax code.

Re: [RFC PATCH-tip v4 02/10] locking/rwsem: Stop active read lock ASAP

[Christoph Hellwig]

On Wed, Oct 12, 2016 at 08:06:40AM +1100, Dave Chinner wrote:
> Um, I seem to have completely missed that change - when did that
> happen and why?
> 
> Oh, it was part of the misguided "enable DAX on block devices"
> changes -

o, that commit just switched it to use ->f_mapping:

-   return (filp->f_flags & O_DIRECT) || IS_DAX(file_inode(filp));
+   return (filp->f_flags & O_DIRECT) || IS_DAX(filp->f_mapping->host);

The original version of it goes all the way back to introducing the
current-day DAX code in d475c6346 ("dax,ext2: replace XIP read and write
with DAX I/O");

> Hence I'd suggest that DAX check in io_is_direct() should be removed
> ASAP; the filesystems don't need it as they check the inode DAX
> state directly, and the code it "fixed" is no longer in the tree.

As long as ext4 still uses the overloaded direct_IO we need the
checks for DAX in the filemap.c generic read/write code.  It seems
like that's only two spots anyway, but I'd feel much safer once ext4
is switched over to the iomap version of the dax code.

[PATCH] aio: fix a use after free (and fix freeze protection of aio writes)

[Christoph Hellwig]

From: Jan Kara 

Currently we dropped freeze protection of aio writes just after IO was
submitted. Thus aio write could be in flight while the filesystem was
frozen and that could result in unexpected situation like aio completion
wanting to convert extent type on frozen filesystem. Testcase from
Dmitry triggering this is like:

for ((i=0;i<60;i++));do fsfreeze -f /mnt ;sleep 1;fsfreeze -u /mnt;done &
fio --bs=4k --ioengine=libaio --iodepth=128 --size=1g --direct=1 \
--runtime=60 --filename=/mnt/file --name=rand-write --rw=randwrite

Fix the problem by dropping freeze protection only once IO is completed
in aio_complete().

[hch: The above was the changelog of the original patch from Jan.
 It turns out that it fixes something even more important - a use
 after free of the file structucture given that the direct I/O
 code calls fput and potentially drops the last reference to it in
 aio_complete.  Together with two racing threads and a zero sized
 I/O this seems easily exploitable]

Reported-by: Dmitry Monakhov 
Signed-off-by: Jan Kara 
[hch: switch to use __sb_writers_acquired and file_inode(file),
  updated changelog]
Signed-off-by: Christoph Hellwig 
---
 fs/aio.c   | 28 +---
 include/linux/fs.h |  1 +
 2 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/fs/aio.c b/fs/aio.c
index 1157e13..bf315cd 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1078,6 +1078,17 @@ static void aio_complete(struct kiocb *kiocb, long res, 
long res2)
unsigned tail, pos, head;
unsigned long   flags;
 
+   if (kiocb->ki_flags & IOCB_WRITE) {
+   struct file *file = kiocb->ki_filp;
+
+   /*
+* Tell lockdep we inherited freeze protection from submission
+* thread.
+*/
+   __sb_writers_acquired(file_inode(file)->i_sb, SB_FREEZE_WRITE);
+   file_end_write(file);
+   }
+
/*
 * Special case handling for sync iocbs:
 *  - events go directly into the iocb for fast handling
@@ -1460,13 +1471,24 @@ static ssize_t aio_run_iocb(struct kiocb *req, unsigned 
opcode,
return ret;
}
 
-   if (rw == WRITE)
+   if (rw == WRITE) {
file_start_write(file);
+   req->ki_flags |= IOCB_WRITE;
+   }
+
+   if (rw == WRITE) {
+   /*
+* We release freeze protection in aio_complete(). Fool
+* lockdep by telling it the lock got released so that
+* it doesn't complain about held lock when we return
+* to userspace.
+*/
+   __sb_writers_release(file_inode(file)->i_sb,
+   SB_FREEZE_WRITE);
+   }
 
ret = iter_op(req, );
 
-   if (rw == WRITE)
-   file_end_write(file);
kfree(iovec);
break;
 
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 16d2b6e..db600e9 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -321,6 +321,7 @@ struct writeback_control;
 #define IOCB_HIPRI (1 << 3)
 #define IOCB_DSYNC (1 << 4)
 #define IOCB_SYNC  (1 << 5)
+#define IOCB_WRITE (1 << 6)
 
 struct kiocb {
struct file *ki_filp;
-- 
2.1.4

[PATCH] aio: fix a use after free (and fix freeze protection of aio writes)

[Christoph Hellwig]

From: Jan Kara 

Currently we dropped freeze protection of aio writes just after IO was
submitted. Thus aio write could be in flight while the filesystem was
frozen and that could result in unexpected situation like aio completion
wanting to convert extent type on frozen filesystem. Testcase from
Dmitry triggering this is like:

for ((i=0;i<60;i++));do fsfreeze -f /mnt ;sleep 1;fsfreeze -u /mnt;done &
fio --bs=4k --ioengine=libaio --iodepth=128 --size=1g --direct=1 \
--runtime=60 --filename=/mnt/file --name=rand-write --rw=randwrite

Fix the problem by dropping freeze protection only once IO is completed
in aio_complete().

[hch: The above was the changelog of the original patch from Jan.
 It turns out that it fixes something even more important - a use
 after free of the file structucture given that the direct I/O
 code calls fput and potentially drops the last reference to it in
 aio_complete.  Together with two racing threads and a zero sized
 I/O this seems easily exploitable]

Reported-by: Dmitry Monakhov 
Signed-off-by: Jan Kara 
[hch: switch to use __sb_writers_acquired and file_inode(file),
  updated changelog]
Signed-off-by: Christoph Hellwig 
---
 fs/aio.c   | 28 +---
 include/linux/fs.h |  1 +
 2 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/fs/aio.c b/fs/aio.c
index 1157e13..bf315cd 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1078,6 +1078,17 @@ static void aio_complete(struct kiocb *kiocb, long res, 
long res2)
unsigned tail, pos, head;
unsigned long   flags;
 
+   if (kiocb->ki_flags & IOCB_WRITE) {
+   struct file *file = kiocb->ki_filp;
+
+   /*
+* Tell lockdep we inherited freeze protection from submission
+* thread.
+*/
+   __sb_writers_acquired(file_inode(file)->i_sb, SB_FREEZE_WRITE);
+   file_end_write(file);
+   }
+
/*
 * Special case handling for sync iocbs:
 *  - events go directly into the iocb for fast handling
@@ -1460,13 +1471,24 @@ static ssize_t aio_run_iocb(struct kiocb *req, unsigned 
opcode,
return ret;
}
 
-   if (rw == WRITE)
+   if (rw == WRITE) {
file_start_write(file);
+   req->ki_flags |= IOCB_WRITE;
+   }
+
+   if (rw == WRITE) {
+   /*
+* We release freeze protection in aio_complete(). Fool
+* lockdep by telling it the lock got released so that
+* it doesn't complain about held lock when we return
+* to userspace.
+*/
+   __sb_writers_release(file_inode(file)->i_sb,
+   SB_FREEZE_WRITE);
+   }
 
ret = iter_op(req, );
 
-   if (rw == WRITE)
-   file_end_write(file);
kfree(iovec);
break;
 
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 16d2b6e..db600e9 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -321,6 +321,7 @@ struct writeback_control;
 #define IOCB_HIPRI (1 << 3)
 #define IOCB_DSYNC (1 << 4)
 #define IOCB_SYNC  (1 << 5)
+#define IOCB_WRITE (1 << 6)
 
 struct kiocb {
struct file *ki_filp;
-- 
2.1.4

[PATCH v2] iio: light: ltr501: claim direct mode during raw writes

[Alison Schofield]

Driver was checking for direct mode but not locking it.  Use
claim/release helper functions to guarantee the device stays
in direct mode during all raw write operations.

Signed-off-by: Alison Schofield 
---
Changes in v2:
  Replaced 'goto release' statements with breaks.
  The release helper function remains in the same place as in version
  one of patch, but now break statements control the flow rather than
  jumping out with goto's.
  
  I may have 'break'd more than needed at tail end of nested switch.
  Tried to follow official c language definition.  


 drivers/iio/light/ltr501.c | 81 +-
 1 file changed, 51 insertions(+), 30 deletions(-)

diff --git a/drivers/iio/light/ltr501.c b/drivers/iio/light/ltr501.c
index 3afc53a..8f9d5cf 100644
--- a/drivers/iio/light/ltr501.c
+++ b/drivers/iio/light/ltr501.c
@@ -729,8 +729,9 @@ static int ltr501_write_raw(struct iio_dev *indio_dev,
int i, ret, freq_val, freq_val2;
struct ltr501_chip_info *info = data->chip_info;
 
-   if (iio_buffer_enabled(indio_dev))
-   return -EBUSY;
+   ret = iio_device_claim_direct_mode(indio_dev);
+   if (ret)
+   return ret;
 
switch (mask) {
case IIO_CHAN_INFO_SCALE:
@@ -739,85 +740,105 @@ static int ltr501_write_raw(struct iio_dev *indio_dev,
i = ltr501_get_gain_index(info->als_gain,
  info->als_gain_tbl_size,
  val, val2);
-   if (i < 0)
-   return -EINVAL;
+   if (i < 0) {
+   ret = -EINVAL;
+   break;
+   }
 
data->als_contr &= ~info->als_gain_mask;
data->als_contr |= i << info->als_gain_shift;
 
-   return regmap_write(data->regmap, LTR501_ALS_CONTR,
-   data->als_contr);
+   ret = regmap_write(data->regmap, LTR501_ALS_CONTR,
+  data->als_contr);
+   break;
case IIO_PROXIMITY:
i = ltr501_get_gain_index(info->ps_gain,
  info->ps_gain_tbl_size,
  val, val2);
-   if (i < 0)
-   return -EINVAL;
+   if (i < 0) {
+   ret = -EINVAL;
+   break;
+   }
data->ps_contr &= ~LTR501_CONTR_PS_GAIN_MASK;
data->ps_contr |= i << LTR501_CONTR_PS_GAIN_SHIFT;
 
-   return regmap_write(data->regmap, LTR501_PS_CONTR,
-   data->ps_contr);
+   ret = regmap_write(data->regmap, LTR501_PS_CONTR,
+  data->ps_contr);
+   break;
default:
-   return -EINVAL;
+   ret = -EINVAL;
+   break;
}
+   break;
+
case IIO_CHAN_INFO_INT_TIME:
switch (chan->type) {
case IIO_INTENSITY:
-   if (val != 0)
-   return -EINVAL;
+   if (val != 0) {
+   ret = -EINVAL;
+   break;
+   }
mutex_lock(>lock_als);
-   i = ltr501_set_it_time(data, val2);
+   ret = ltr501_set_it_time(data, val2);
mutex_unlock(>lock_als);
-   return i;
+   break;
default:
-   return -EINVAL;
+   ret = -EINVAL;
+   break;
}
+   break;
+
case IIO_CHAN_INFO_SAMP_FREQ:
switch (chan->type) {
case IIO_INTENSITY:
ret = ltr501_als_read_samp_freq(data, _val,
_val2);
if (ret < 0)
-   return ret;
+   break;
 
ret = ltr501_als_write_samp_freq(data, val, val2);
if (ret < 0)
-   return ret;
+   break;
 
/* update persistence count when changing frequency */
ret = ltr501_write_intr_prst(data, chan->type,
 0, data->als_period);
 
if (ret < 0)
-   

[PATCH v2] iio: light: ltr501: claim direct mode during raw writes

[Alison Schofield]

Driver was checking for direct mode but not locking it.  Use
claim/release helper functions to guarantee the device stays
in direct mode during all raw write operations.

Signed-off-by: Alison Schofield 
---
Changes in v2:
  Replaced 'goto release' statements with breaks.
  The release helper function remains in the same place as in version
  one of patch, but now break statements control the flow rather than
  jumping out with goto's.
  
  I may have 'break'd more than needed at tail end of nested switch.
  Tried to follow official c language definition.  


 drivers/iio/light/ltr501.c | 81 +-
 1 file changed, 51 insertions(+), 30 deletions(-)

diff --git a/drivers/iio/light/ltr501.c b/drivers/iio/light/ltr501.c
index 3afc53a..8f9d5cf 100644
--- a/drivers/iio/light/ltr501.c
+++ b/drivers/iio/light/ltr501.c
@@ -729,8 +729,9 @@ static int ltr501_write_raw(struct iio_dev *indio_dev,
int i, ret, freq_val, freq_val2;
struct ltr501_chip_info *info = data->chip_info;
 
-   if (iio_buffer_enabled(indio_dev))
-   return -EBUSY;
+   ret = iio_device_claim_direct_mode(indio_dev);
+   if (ret)
+   return ret;
 
switch (mask) {
case IIO_CHAN_INFO_SCALE:
@@ -739,85 +740,105 @@ static int ltr501_write_raw(struct iio_dev *indio_dev,
i = ltr501_get_gain_index(info->als_gain,
  info->als_gain_tbl_size,
  val, val2);
-   if (i < 0)
-   return -EINVAL;
+   if (i < 0) {
+   ret = -EINVAL;
+   break;
+   }
 
data->als_contr &= ~info->als_gain_mask;
data->als_contr |= i << info->als_gain_shift;
 
-   return regmap_write(data->regmap, LTR501_ALS_CONTR,
-   data->als_contr);
+   ret = regmap_write(data->regmap, LTR501_ALS_CONTR,
+  data->als_contr);
+   break;
case IIO_PROXIMITY:
i = ltr501_get_gain_index(info->ps_gain,
  info->ps_gain_tbl_size,
  val, val2);
-   if (i < 0)
-   return -EINVAL;
+   if (i < 0) {
+   ret = -EINVAL;
+   break;
+   }
data->ps_contr &= ~LTR501_CONTR_PS_GAIN_MASK;
data->ps_contr |= i << LTR501_CONTR_PS_GAIN_SHIFT;
 
-   return regmap_write(data->regmap, LTR501_PS_CONTR,
-   data->ps_contr);
+   ret = regmap_write(data->regmap, LTR501_PS_CONTR,
+  data->ps_contr);
+   break;
default:
-   return -EINVAL;
+   ret = -EINVAL;
+   break;
}
+   break;
+
case IIO_CHAN_INFO_INT_TIME:
switch (chan->type) {
case IIO_INTENSITY:
-   if (val != 0)
-   return -EINVAL;
+   if (val != 0) {
+   ret = -EINVAL;
+   break;
+   }
mutex_lock(>lock_als);
-   i = ltr501_set_it_time(data, val2);
+   ret = ltr501_set_it_time(data, val2);
mutex_unlock(>lock_als);
-   return i;
+   break;
default:
-   return -EINVAL;
+   ret = -EINVAL;
+   break;
}
+   break;
+
case IIO_CHAN_INFO_SAMP_FREQ:
switch (chan->type) {
case IIO_INTENSITY:
ret = ltr501_als_read_samp_freq(data, _val,
_val2);
if (ret < 0)
-   return ret;
+   break;
 
ret = ltr501_als_write_samp_freq(data, val, val2);
if (ret < 0)
-   return ret;
+   break;
 
/* update persistence count when changing frequency */
ret = ltr501_write_intr_prst(data, chan->type,
 0, data->als_period);
 
if (ret < 0)
-   

[PATCH v2] iio: light: ltr501: claim direct mode during select raw reads

[Alison Schofield]

Driver was checking for direct mode but not locking it.  Use
claim/release helper functions to guarantee the device stays
in direct mode during required raw read cases.

Signed-off-by: Alison Schofield 
---
Changes in v2:
 Reworked IIO_CHAN_INFO_RAW case so claim and release are
 executed at same level in the switch statements. (rather
 than claims on top level and releases nested in cases)

 drivers/iio/light/ltr501.c | 30 --
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/iio/light/ltr501.c b/drivers/iio/light/ltr501.c
index 3afc53a..d577477 100644
--- a/drivers/iio/light/ltr501.c
+++ b/drivers/iio/light/ltr501.c
@@ -631,14 +631,16 @@ static int ltr501_read_raw(struct iio_dev *indio_dev,
 
switch (mask) {
case IIO_CHAN_INFO_PROCESSED:
-   if (iio_buffer_enabled(indio_dev))
-   return -EBUSY;
-
switch (chan->type) {
case IIO_LIGHT:
+   ret = iio_device_claim_direct_mode(indio_dev);
+   if (ret)
+   return ret;
+
mutex_lock(>lock_als);
ret = ltr501_read_als(data, buf);
mutex_unlock(>lock_als);
+   iio_device_release_direct_mode(indio_dev);
if (ret < 0)
return ret;
*val = ltr501_calculate_lux(le16_to_cpu(buf[1]),
@@ -648,8 +650,9 @@ static int ltr501_read_raw(struct iio_dev *indio_dev,
return -EINVAL;
}
case IIO_CHAN_INFO_RAW:
-   if (iio_buffer_enabled(indio_dev))
-   return -EBUSY;
+   ret = iio_device_claim_direct_mode(indio_dev);
+   if (ret)
+   return ret;
 
switch (chan->type) {
case IIO_INTENSITY:
@@ -657,21 +660,28 @@ static int ltr501_read_raw(struct iio_dev *indio_dev,
ret = ltr501_read_als(data, buf);
mutex_unlock(>lock_als);
if (ret < 0)
-   return ret;
+   break;
*val = le16_to_cpu(chan->address == LTR501_ALS_DATA1 ?
   buf[0] : buf[1]);
-   return IIO_VAL_INT;
+   ret = IIO_VAL_INT;
+   break;
case IIO_PROXIMITY:
mutex_lock(>lock_ps);
ret = ltr501_read_ps(data);
mutex_unlock(>lock_ps);
if (ret < 0)
-   return ret;
+   break;
*val = ret & LTR501_PS_DATA_MASK;
-   return IIO_VAL_INT;
+   ret = IIO_VAL_INT;
+   break;
default:
-   return -EINVAL;
+   ret = -EINVAL;
+   break;
}
+
+   iio_device_release_direct_mode(indio_dev);
+   return ret;
+
case IIO_CHAN_INFO_SCALE:
switch (chan->type) {
case IIO_INTENSITY:
-- 
2.1.4

[PATCH v2] iio: light: ltr501: claim direct mode during select raw reads

[Alison Schofield]

Driver was checking for direct mode but not locking it.  Use
claim/release helper functions to guarantee the device stays
in direct mode during required raw read cases.

Signed-off-by: Alison Schofield 
---
Changes in v2:
 Reworked IIO_CHAN_INFO_RAW case so claim and release are
 executed at same level in the switch statements. (rather
 than claims on top level and releases nested in cases)

 drivers/iio/light/ltr501.c | 30 --
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/iio/light/ltr501.c b/drivers/iio/light/ltr501.c
index 3afc53a..d577477 100644
--- a/drivers/iio/light/ltr501.c
+++ b/drivers/iio/light/ltr501.c
@@ -631,14 +631,16 @@ static int ltr501_read_raw(struct iio_dev *indio_dev,
 
switch (mask) {
case IIO_CHAN_INFO_PROCESSED:
-   if (iio_buffer_enabled(indio_dev))
-   return -EBUSY;
-
switch (chan->type) {
case IIO_LIGHT:
+   ret = iio_device_claim_direct_mode(indio_dev);
+   if (ret)
+   return ret;
+
mutex_lock(>lock_als);
ret = ltr501_read_als(data, buf);
mutex_unlock(>lock_als);
+   iio_device_release_direct_mode(indio_dev);
if (ret < 0)
return ret;
*val = ltr501_calculate_lux(le16_to_cpu(buf[1]),
@@ -648,8 +650,9 @@ static int ltr501_read_raw(struct iio_dev *indio_dev,
return -EINVAL;
}
case IIO_CHAN_INFO_RAW:
-   if (iio_buffer_enabled(indio_dev))
-   return -EBUSY;
+   ret = iio_device_claim_direct_mode(indio_dev);
+   if (ret)
+   return ret;
 
switch (chan->type) {
case IIO_INTENSITY:
@@ -657,21 +660,28 @@ static int ltr501_read_raw(struct iio_dev *indio_dev,
ret = ltr501_read_als(data, buf);
mutex_unlock(>lock_als);
if (ret < 0)
-   return ret;
+   break;
*val = le16_to_cpu(chan->address == LTR501_ALS_DATA1 ?
   buf[0] : buf[1]);
-   return IIO_VAL_INT;
+   ret = IIO_VAL_INT;
+   break;
case IIO_PROXIMITY:
mutex_lock(>lock_ps);
ret = ltr501_read_ps(data);
mutex_unlock(>lock_ps);
if (ret < 0)
-   return ret;
+   break;
*val = ret & LTR501_PS_DATA_MASK;
-   return IIO_VAL_INT;
+   ret = IIO_VAL_INT;
+   break;
default:
-   return -EINVAL;
+   ret = -EINVAL;
+   break;
}
+
+   iio_device_release_direct_mode(indio_dev);
+   return ret;
+
case IIO_CHAN_INFO_SCALE:
switch (chan->type) {
case IIO_INTENSITY:
-- 
2.1.4

cris-linux-objcopy: error: the input file 'arch/cris/boot/rescue/rescue.o' has no sections

[kbuild test robot]

Hi Guenter,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1001354ca34179f3db924eb66672442a173147dc
commit: f9f3f864b5e8c09d7837d8980edba4ad52969819 cris: Fix section mismatches 
in architecture startup code
date:   10 months ago
config: cris-allnoconfig (attached as .config)
compiler: cris-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout f9f3f864b5e8c09d7837d8980edba4ad52969819
# save the attached .config to linux build tree
make.cross ARCH=cris 

All errors (new ones prefixed by >>):

>> cris-linux-objcopy: error: the input file 'arch/cris/boot/rescue/rescue.o' 
>> has no sections

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

cris-linux-objcopy: error: the input file 'arch/cris/boot/rescue/rescue.o' has no sections

[kbuild test robot]

Hi Guenter,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1001354ca34179f3db924eb66672442a173147dc
commit: f9f3f864b5e8c09d7837d8980edba4ad52969819 cris: Fix section mismatches 
in architecture startup code
date:   10 months ago
config: cris-allnoconfig (attached as .config)
compiler: cris-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout f9f3f864b5e8c09d7837d8980edba4ad52969819
# save the attached .config to linux build tree
make.cross ARCH=cris 

All errors (new ones prefixed by >>):

>> cris-linux-objcopy: error: the input file 'arch/cris/boot/rescue/rescue.o' 
>> has no sections

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

drivers/regulator/lp872x.c:773: undefined reference to `devm_gpio_request_one'

[kbuild test robot]

Hi Linus,

It's probably a bug fix that unveils the link errors.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1001354ca34179f3db924eb66672442a173147dc
commit: 2527ecc9195e9c66252af24c4689e8a67cd4ccb9 gpio: Fix OF build problem on 
UM
date:   8 weeks ago
config: um-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 2527ecc9195e9c66252af24c4689e8a67cd4ccb9
# save the attached .config to linux build tree
make ARCH=um 

All errors (new ones prefixed by >>):

   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc7d1): warning: Using 'getgrnam' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc61c): warning: Using 'getpwuid' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc935): warning: Using 'getaddrinfo' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoaddr':
   (.text+0x1d3c5): warning: Using 'gethostbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametonetaddr':
   (.text+0x1d465): warning: Using 'getnetbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoproto':
   (.text+0x1d685): warning: Using 'getprotobyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoport':
   (.text+0x1d4b7): warning: Using 'getservbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   drivers/built-in.o: In function `fwnode_get_named_gpiod':
   drivers/gpio/gpiolib.c:3215: undefined reference to 
`of_get_named_gpiod_flags'
   drivers/built-in.o: In function `gpiod_get_index':
   drivers/gpio/gpiolib.c:3140: undefined reference to 
`of_get_named_gpiod_flags'
   drivers/built-in.o: In function `lp872x_probe':
>> drivers/regulator/lp872x.c:773: undefined reference to 
>> `devm_gpio_request_one'
   drivers/regulator/lp872x.c:746: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `max8952_pmic_probe':
>> drivers/regulator/max8952.c:249: undefined reference to 
>> `devm_gpio_request_one'
   drivers/built-in.o: In function `max8973_probe':
>> drivers/regulator/max8973-regulator.c:715: undefined reference to 
>> `devm_gpio_request_one'
   drivers/regulator/max8973-regulator.c:770: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `pwm_regulator_probe':
>> drivers/regulator/pwm-regulator.c:387: undefined reference to 
>> `devm_gpiod_get_optional'
   drivers/built-in.o: In function `tps62360_probe':
>> drivers/regulator/tps62360-regulator.c:433: undefined reference to 
>> `devm_gpio_request_one'
   drivers/regulator/tps62360-regulator.c:444: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `fdp_nci_i2c_probe':
>> drivers/nfc/fdp/i2c.c:326: undefined reference to `devm_gpiod_get'
   drivers/built-in.o: In function `nfcmrvl_nci_unregister_dev':
>> drivers/nfc/nfcmrvl/main.c:198: undefined reference to `devm_gpio_free'
   drivers/built-in.o: In function `nfcmrvl_nci_register_dev':
>> drivers/nfc/nfcmrvl/main.c:127: undefined reference to 
>> `devm_gpio_request_one'
   drivers/built-in.o: In function `st21nfca_hci_i2c_probe':
>> drivers/nfc/st21nfca/i2c.c:597: undefined reference to 
>> `devm_gpio_request_one'
   drivers/built-in.o: In function `st_nci_i2c_probe':
>> drivers/nfc/st-nci/i2c.c:300: undefined reference to `devm_gpio_request_one'
   drivers/built-in.o: In function `nxp_nci_i2c_probe':
>> drivers/nfc/nxp-nci/i2c.c:361: undefined reference to `devm_gpio_request_one'
   drivers/built-in.o: In function `mdio_gpio_probe':
>> drivers/net/phy/mdio-gpio.c:177: undefined reference to `devm_gpio_request'
   drivers/built-in.o: In function `at803x_probe':
>> drivers/net/phy/at803x.c:283: undefined reference to 
>> `devm_gpiod_get_optional'
   drivers/built-in.o: In function `mv88e6xxx_probe':
>> drivers/net/dsa/mv88e6xxx/chip.c:4022: undefined reference to 
>> `devm_gpiod_get_optional'
   drivers/built-in.o: In function `pps_gpio_probe':
>> drivers/pps/clients/pps-gpio.c:125: undefined reference to 
>> `devm_gpio_request'
   drivers/built-in.o: In function `max8903_probe':
   drivers/power/max8903_charger.c:248: undefined reference to 
`devm_gpio_request'
   

drivers/regulator/lp872x.c:773: undefined reference to `devm_gpio_request_one'

[kbuild test robot]

Hi Linus,

It's probably a bug fix that unveils the link errors.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1001354ca34179f3db924eb66672442a173147dc
commit: 2527ecc9195e9c66252af24c4689e8a67cd4ccb9 gpio: Fix OF build problem on 
UM
date:   8 weeks ago
config: um-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 2527ecc9195e9c66252af24c4689e8a67cd4ccb9
# save the attached .config to linux build tree
make ARCH=um 

All errors (new ones prefixed by >>):

   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc7d1): warning: Using 'getgrnam' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc61c): warning: Using 'getpwuid' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc935): warning: Using 'getaddrinfo' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoaddr':
   (.text+0x1d3c5): warning: Using 'gethostbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametonetaddr':
   (.text+0x1d465): warning: Using 'getnetbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoproto':
   (.text+0x1d685): warning: Using 'getprotobyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoport':
   (.text+0x1d4b7): warning: Using 'getservbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   drivers/built-in.o: In function `fwnode_get_named_gpiod':
   drivers/gpio/gpiolib.c:3215: undefined reference to 
`of_get_named_gpiod_flags'
   drivers/built-in.o: In function `gpiod_get_index':
   drivers/gpio/gpiolib.c:3140: undefined reference to 
`of_get_named_gpiod_flags'
   drivers/built-in.o: In function `lp872x_probe':
>> drivers/regulator/lp872x.c:773: undefined reference to 
>> `devm_gpio_request_one'
   drivers/regulator/lp872x.c:746: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `max8952_pmic_probe':
>> drivers/regulator/max8952.c:249: undefined reference to 
>> `devm_gpio_request_one'
   drivers/built-in.o: In function `max8973_probe':
>> drivers/regulator/max8973-regulator.c:715: undefined reference to 
>> `devm_gpio_request_one'
   drivers/regulator/max8973-regulator.c:770: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `pwm_regulator_probe':
>> drivers/regulator/pwm-regulator.c:387: undefined reference to 
>> `devm_gpiod_get_optional'
   drivers/built-in.o: In function `tps62360_probe':
>> drivers/regulator/tps62360-regulator.c:433: undefined reference to 
>> `devm_gpio_request_one'
   drivers/regulator/tps62360-regulator.c:444: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `fdp_nci_i2c_probe':
>> drivers/nfc/fdp/i2c.c:326: undefined reference to `devm_gpiod_get'
   drivers/built-in.o: In function `nfcmrvl_nci_unregister_dev':
>> drivers/nfc/nfcmrvl/main.c:198: undefined reference to `devm_gpio_free'
   drivers/built-in.o: In function `nfcmrvl_nci_register_dev':
>> drivers/nfc/nfcmrvl/main.c:127: undefined reference to 
>> `devm_gpio_request_one'
   drivers/built-in.o: In function `st21nfca_hci_i2c_probe':
>> drivers/nfc/st21nfca/i2c.c:597: undefined reference to 
>> `devm_gpio_request_one'
   drivers/built-in.o: In function `st_nci_i2c_probe':
>> drivers/nfc/st-nci/i2c.c:300: undefined reference to `devm_gpio_request_one'
   drivers/built-in.o: In function `nxp_nci_i2c_probe':
>> drivers/nfc/nxp-nci/i2c.c:361: undefined reference to `devm_gpio_request_one'
   drivers/built-in.o: In function `mdio_gpio_probe':
>> drivers/net/phy/mdio-gpio.c:177: undefined reference to `devm_gpio_request'
   drivers/built-in.o: In function `at803x_probe':
>> drivers/net/phy/at803x.c:283: undefined reference to 
>> `devm_gpiod_get_optional'
   drivers/built-in.o: In function `mv88e6xxx_probe':
>> drivers/net/dsa/mv88e6xxx/chip.c:4022: undefined reference to 
>> `devm_gpiod_get_optional'
   drivers/built-in.o: In function `pps_gpio_probe':
>> drivers/pps/clients/pps-gpio.c:125: undefined reference to 
>> `devm_gpio_request'
   drivers/built-in.o: In function `max8903_probe':
   drivers/power/max8903_charger.c:248: undefined reference to 
`devm_gpio_request'
   

Re: [PATCH 1/5] KVM: x86: avoid atomic operations on APICv vmentry

[Michael S. Tsirkin]

On Fri, Oct 14, 2016 at 08:21:27PM +0200, Paolo Bonzini wrote:
> On some benchmarks (e.g. netperf with ioeventfd disabled), APICv
> posted interrupts turn out to be slower than interrupt injection via
> KVM_REQ_EVENT.
> 
> This patch optimizes a bit the IRR update, avoiding expensive atomic
> operations in the common case where PI.ON=0 at vmentry or the PIR vector
> is mostly zero.  This saves at least 20 cycles (1%) per vmexit, as
> measured by kvm-unit-tests' inl_from_qemu test (20 runs):
> 
>   | enable_apicv=1  |  enable_apicv=0
>   | mean stdev  |  mean stdev
> --|-|--
> before| 5826 32.65  |  5765 47.09
> after | 5809 43.42  |  5777 77.02
> 
> Of course, any change in the right column is just placebo effect. :)
> The savings are bigger if interrupts are frequent.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  arch/x86/kvm/lapic.c | 6 --
>  arch/x86/kvm/vmx.c   | 9 -
>  2 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 23b99f305382..63a442aefc12 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -342,9 +342,11 @@ void __kvm_apic_update_irr(u32 *pir, void *regs)
>   u32 i, pir_val;
>  
>   for (i = 0; i <= 7; i++) {
> - pir_val = xchg([i], 0);
> - if (pir_val)
> + pir_val = READ_ONCE(pir[i]);
> + if (pir_val) {
> + pir_val = xchg([i], 0);
>   *((u32 *)(regs + APIC_IRR + i * 0x10)) |= pir_val;
> + }
>   }
>  }
>  EXPORT_SYMBOL_GPL(__kvm_apic_update_irr);

gcc doesn't seem to unroll this loop and it's
probably worth unrolling it

The following seems to do the trick for me on upstream - I didn't
benchmark it though. Is there a kvm unit test for interrupts?

--->

kvm: unroll the loop in __kvm_apic_update_irr.

This is hot data path in interrupt-rich workloads, worth unrolling.

Signed-off-by: Michael S. Tsirkin 


diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index b62c852..0c3462c 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -337,7 +337,8 @@ static u8 count_vectors(void *bitmap)
return count;
 }
 
-void __kvm_apic_update_irr(u32 *pir, void *regs)
+void __attribute__((optimize("unroll-loops")))
+__kvm_apic_update_irr(u32 *pir, void *regs)
 {
u32 i, pir_val;
 

Re: [PATCH 1/5] KVM: x86: avoid atomic operations on APICv vmentry

[Michael S. Tsirkin]

On Fri, Oct 14, 2016 at 08:21:27PM +0200, Paolo Bonzini wrote:
> On some benchmarks (e.g. netperf with ioeventfd disabled), APICv
> posted interrupts turn out to be slower than interrupt injection via
> KVM_REQ_EVENT.
> 
> This patch optimizes a bit the IRR update, avoiding expensive atomic
> operations in the common case where PI.ON=0 at vmentry or the PIR vector
> is mostly zero.  This saves at least 20 cycles (1%) per vmexit, as
> measured by kvm-unit-tests' inl_from_qemu test (20 runs):
> 
>   | enable_apicv=1  |  enable_apicv=0
>   | mean stdev  |  mean stdev
> --|-|--
> before| 5826 32.65  |  5765 47.09
> after | 5809 43.42  |  5777 77.02
> 
> Of course, any change in the right column is just placebo effect. :)
> The savings are bigger if interrupts are frequent.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  arch/x86/kvm/lapic.c | 6 --
>  arch/x86/kvm/vmx.c   | 9 -
>  2 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 23b99f305382..63a442aefc12 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -342,9 +342,11 @@ void __kvm_apic_update_irr(u32 *pir, void *regs)
>   u32 i, pir_val;
>  
>   for (i = 0; i <= 7; i++) {
> - pir_val = xchg([i], 0);
> - if (pir_val)
> + pir_val = READ_ONCE(pir[i]);
> + if (pir_val) {
> + pir_val = xchg([i], 0);
>   *((u32 *)(regs + APIC_IRR + i * 0x10)) |= pir_val;
> + }
>   }
>  }
>  EXPORT_SYMBOL_GPL(__kvm_apic_update_irr);

gcc doesn't seem to unroll this loop and it's
probably worth unrolling it

The following seems to do the trick for me on upstream - I didn't
benchmark it though. Is there a kvm unit test for interrupts?

--->

kvm: unroll the loop in __kvm_apic_update_irr.

This is hot data path in interrupt-rich workloads, worth unrolling.

Signed-off-by: Michael S. Tsirkin 


diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index b62c852..0c3462c 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -337,7 +337,8 @@ static u8 count_vectors(void *bitmap)
return count;
 }
 
-void __kvm_apic_update_irr(u32 *pir, void *regs)
+void __attribute__((optimize("unroll-loops")))
+__kvm_apic_update_irr(u32 *pir, void *regs)
 {
u32 i, pir_val;
 

[patch ]mm/zs_malloc: Fix bit spinlock replacement

[Mike Galbraith]

Do not alter HANDLE_SIZE, memory corruption ensues.  The handle is
a pointer, allocate space for the struct it points to and align it
ZS_ALIGN.  Also, when accessing the struct, mask HANDLE_PIN_BIT.

Signed-off-by: Mike Galbraith 
---
 mm/zsmalloc.c |   13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -71,6 +71,8 @@
 #define ZS_MAX_ZSPAGE_ORDER 2
 #define ZS_MAX_PAGES_PER_ZSPAGE (_AC(1, UL) << ZS_MAX_ZSPAGE_ORDER)
 
+#define ZS_HANDLE_SIZE (sizeof(unsigned long))
+
 #ifdef CONFIG_PREEMPT_RT_BASE
 
 struct zsmalloc_handle {
@@ -78,11 +80,11 @@ struct zsmalloc_handle {
struct mutex lock;
 };
 
-#define ZS_HANDLE_SIZE (sizeof(struct zsmalloc_handle))
+#define ZS_HANDLE_ALLOC_SIZE (sizeof(struct zsmalloc_handle))
 
 #else
 
-#define ZS_HANDLE_SIZE (sizeof(unsigned long))
+#define ZS_HANDLE_ALLOC_SIZE ZS_HANDLE_SIZE
 #endif
 
 /*
@@ -339,8 +341,9 @@ static void SetZsPageMovable(struct zs_p
 
 static int create_cache(struct zs_pool *pool)
 {
-   pool->handle_cachep = kmem_cache_create("zs_handle", ZS_HANDLE_SIZE,
-   0, 0, NULL);
+   pool->handle_cachep = kmem_cache_create("zs_handle",
+   ZS_HANDLE_ALLOC_SIZE,
+   ZS_ALIGN, 0, NULL);
if (!pool->handle_cachep)
return 1;
 
@@ -380,7 +383,7 @@ static unsigned long cache_alloc_handle(
 #ifdef CONFIG_PREEMPT_RT_BASE
 static struct zsmalloc_handle *zs_get_pure_handle(unsigned long handle)
 {
-   return (void *)(handle &~((1 << OBJ_TAG_BITS) - 1));
+   return (void *)(handle & ~BIT(HANDLE_PIN_BIT));
 }
 #endif
 

[patch ]mm/zs_malloc: Fix bit spinlock replacement

[Mike Galbraith]

Do not alter HANDLE_SIZE, memory corruption ensues.  The handle is
a pointer, allocate space for the struct it points to and align it
ZS_ALIGN.  Also, when accessing the struct, mask HANDLE_PIN_BIT.

Signed-off-by: Mike Galbraith 
---
 mm/zsmalloc.c |   13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -71,6 +71,8 @@
 #define ZS_MAX_ZSPAGE_ORDER 2
 #define ZS_MAX_PAGES_PER_ZSPAGE (_AC(1, UL) << ZS_MAX_ZSPAGE_ORDER)
 
+#define ZS_HANDLE_SIZE (sizeof(unsigned long))
+
 #ifdef CONFIG_PREEMPT_RT_BASE
 
 struct zsmalloc_handle {
@@ -78,11 +80,11 @@ struct zsmalloc_handle {
struct mutex lock;
 };
 
-#define ZS_HANDLE_SIZE (sizeof(struct zsmalloc_handle))
+#define ZS_HANDLE_ALLOC_SIZE (sizeof(struct zsmalloc_handle))
 
 #else
 
-#define ZS_HANDLE_SIZE (sizeof(unsigned long))
+#define ZS_HANDLE_ALLOC_SIZE ZS_HANDLE_SIZE
 #endif
 
 /*
@@ -339,8 +341,9 @@ static void SetZsPageMovable(struct zs_p
 
 static int create_cache(struct zs_pool *pool)
 {
-   pool->handle_cachep = kmem_cache_create("zs_handle", ZS_HANDLE_SIZE,
-   0, 0, NULL);
+   pool->handle_cachep = kmem_cache_create("zs_handle",
+   ZS_HANDLE_ALLOC_SIZE,
+   ZS_ALIGN, 0, NULL);
if (!pool->handle_cachep)
return 1;
 
@@ -380,7 +383,7 @@ static unsigned long cache_alloc_handle(
 #ifdef CONFIG_PREEMPT_RT_BASE
 static struct zsmalloc_handle *zs_get_pure_handle(unsigned long handle)
 {
-   return (void *)(handle &~((1 << OBJ_TAG_BITS) - 1));
+   return (void *)(handle & ~BIT(HANDLE_PIN_BIT));
 }
 #endif
 

[patch] drivers/zram: Don't disable preemption in zcomp_stream_get/put()

[Mike Galbraith]

In v4.7, the driver switched to percpu compression streams, disabling
preemption (get/put_cpu_ptr()).  Use get/put_cpu_light() instead.

Signed-off-by: Mike Galbraith 
---
 drivers/block/zram/zcomp.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -118,12 +118,12 @@ ssize_t zcomp_available_show(const char
 
 struct zcomp_strm *zcomp_stream_get(struct zcomp *comp)
 {
-   return *get_cpu_ptr(comp->stream);
+   return *per_cpu_ptr(comp->stream, get_cpu_light());
 }
 
 void zcomp_stream_put(struct zcomp *comp)
 {
-   put_cpu_ptr(comp->stream);
+   put_cpu_light();
 }
 
 int zcomp_compress(struct zcomp_strm *zstrm,

cc1: error: '-march=r3900' requires '-mfp32'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1001354ca34179f3db924eb66672442a173147dc
commit: 034827c727f7f3946a18355b63995b402c226c82 MIPS: Fix -mabi=64 build of 
vdso.lds
date:   5 days ago
config: mips-jmr3927_defconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 034827c727f7f3946a18355b63995b402c226c82
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> cc1: error: '-march=r3900' requires '-mfp32'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[patch] drivers/zram: Don't disable preemption in zcomp_stream_get/put()

[Mike Galbraith]

In v4.7, the driver switched to percpu compression streams, disabling
preemption (get/put_cpu_ptr()).  Use get/put_cpu_light() instead.

Signed-off-by: Mike Galbraith 
---
 drivers/block/zram/zcomp.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -118,12 +118,12 @@ ssize_t zcomp_available_show(const char
 
 struct zcomp_strm *zcomp_stream_get(struct zcomp *comp)
 {
-   return *get_cpu_ptr(comp->stream);
+   return *per_cpu_ptr(comp->stream, get_cpu_light());
 }
 
 void zcomp_stream_put(struct zcomp *comp)
 {
-   put_cpu_ptr(comp->stream);
+   put_cpu_light();
 }
 
 int zcomp_compress(struct zcomp_strm *zstrm,

cc1: error: '-march=r3900' requires '-mfp32'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1001354ca34179f3db924eb66672442a173147dc
commit: 034827c727f7f3946a18355b63995b402c226c82 MIPS: Fix -mabi=64 build of 
vdso.lds
date:   5 days ago
config: mips-jmr3927_defconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 034827c727f7f3946a18355b63995b402c226c82
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> cc1: error: '-march=r3900' requires '-mfp32'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[patch] drivers,connector: Protect send_msg() with a local lock for RT

[Mike Galbraith]

[ 6496.323071] BUG: sleeping function called from invalid context at 
kernel/locking/rtmutex.c:931
[ 6496.323072] in_atomic(): 1, irqs_disabled(): 0, pid: 31807, name: sleep
[ 6496.323077] Preemption disabled at:[] 
proc_exit_connector+0xbb/0x140
[ 6496.323077]
[ 6496.323080] CPU: 4 PID: 31807 Comm: sleep Tainted: GW   E   
4.8.0-rt11-rt #106
[ 6496.323081] Hardware name: IBM System x3550 M3 -[7944K3G]-/69Y5698 , 
BIOS -[D6E150AUS-1.10]- 12/15/2010
[ 6496.323084]   8801051d3d08 813436cd 

[ 6496.323086]  880167ccab80 8801051d3d28 8109c425 
81ce91c0
[ 6496.323088]   8801051d3d40 816406b0 
81ce91c0
[ 6496.323089] Call Trace:
[ 6496.323092]  [] dump_stack+0x65/0x88
[ 6496.323094]  [] ___might_sleep+0xf5/0x180
[ 6496.323097]  [] __rt_spin_lock+0x20/0x50
[ 6496.323100]  [] rt_read_lock+0x28/0x30
[ 6496.323103]  [] netlink_broadcast_filtered+0x49/0x3f0
[ 6496.323106]  [] ? __kmalloc_reserve.isra.33+0x31/0x90
[ 6496.323109]  [] netlink_broadcast+0x1d/0x20
[ 6496.323111]  [] cn_netlink_send_mult+0x19a/0x1f0
[ 6496.323114]  [] cn_netlink_send+0x1b/0x20
[ 6496.323116]  [] proc_exit_connector+0xf8/0x140
[ 6496.323119]  [] do_exit+0x5d1/0xba0
[ 6496.323122]  [] do_group_exit+0x4c/0xc0
[ 6496.323125]  [] SyS_exit_group+0x14/0x20
[ 6496.323127]  [] entry_SYSCALL_64_fastpath+0x1a/0xa4

Signed-off-by: Mike Galbraith 
---
 drivers/connector/cn_proc.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/connector/cn_proc.c
+++ b/drivers/connector/cn_proc.c
@@ -32,6 +32,7 @@
 #include 
 
 #include 
+#include 
 
 /*
  * Size of a cn_msg followed by a proc_event structure.  Since the
@@ -54,10 +55,12 @@ static struct cb_id cn_proc_event_id = {
 
 /* proc_event_counts is used as the sequence number of the netlink message */
 static DEFINE_PER_CPU(__u32, proc_event_counts) = { 0 };
+static DEFINE_LOCAL_IRQ_LOCK(send_msg_lock);
 
 static inline void send_msg(struct cn_msg *msg)
 {
-   preempt_disable();
+   /* RT ordering protection, maps to preempt_disable() for !RT */
+   local_lock(send_msg_lock);
 
msg->seq = __this_cpu_inc_return(proc_event_counts) - 1;
((struct proc_event *)msg->data)->cpu = smp_processor_id();
@@ -70,7 +73,7 @@ static inline void send_msg(struct cn_ms
 */
cn_netlink_send(msg, 0, CN_IDX_PROC, GFP_NOWAIT);
 
-   preempt_enable();
+   local_unlock(send_msg_lock);
 }
 
 void proc_fork_connector(struct task_struct *task)

[patch] drivers,connector: Protect send_msg() with a local lock for RT

[Mike Galbraith]

[ 6496.323071] BUG: sleeping function called from invalid context at 
kernel/locking/rtmutex.c:931
[ 6496.323072] in_atomic(): 1, irqs_disabled(): 0, pid: 31807, name: sleep
[ 6496.323077] Preemption disabled at:[] 
proc_exit_connector+0xbb/0x140
[ 6496.323077]
[ 6496.323080] CPU: 4 PID: 31807 Comm: sleep Tainted: GW   E   
4.8.0-rt11-rt #106
[ 6496.323081] Hardware name: IBM System x3550 M3 -[7944K3G]-/69Y5698 , 
BIOS -[D6E150AUS-1.10]- 12/15/2010
[ 6496.323084]   8801051d3d08 813436cd 

[ 6496.323086]  880167ccab80 8801051d3d28 8109c425 
81ce91c0
[ 6496.323088]   8801051d3d40 816406b0 
81ce91c0
[ 6496.323089] Call Trace:
[ 6496.323092]  [] dump_stack+0x65/0x88
[ 6496.323094]  [] ___might_sleep+0xf5/0x180
[ 6496.323097]  [] __rt_spin_lock+0x20/0x50
[ 6496.323100]  [] rt_read_lock+0x28/0x30
[ 6496.323103]  [] netlink_broadcast_filtered+0x49/0x3f0
[ 6496.323106]  [] ? __kmalloc_reserve.isra.33+0x31/0x90
[ 6496.323109]  [] netlink_broadcast+0x1d/0x20
[ 6496.323111]  [] cn_netlink_send_mult+0x19a/0x1f0
[ 6496.323114]  [] cn_netlink_send+0x1b/0x20
[ 6496.323116]  [] proc_exit_connector+0xf8/0x140
[ 6496.323119]  [] do_exit+0x5d1/0xba0
[ 6496.323122]  [] do_group_exit+0x4c/0xc0
[ 6496.323125]  [] SyS_exit_group+0x14/0x20
[ 6496.323127]  [] entry_SYSCALL_64_fastpath+0x1a/0xa4

Signed-off-by: Mike Galbraith 
---
 drivers/connector/cn_proc.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/connector/cn_proc.c
+++ b/drivers/connector/cn_proc.c
@@ -32,6 +32,7 @@
 #include 
 
 #include 
+#include 
 
 /*
  * Size of a cn_msg followed by a proc_event structure.  Since the
@@ -54,10 +55,12 @@ static struct cb_id cn_proc_event_id = {
 
 /* proc_event_counts is used as the sequence number of the netlink message */
 static DEFINE_PER_CPU(__u32, proc_event_counts) = { 0 };
+static DEFINE_LOCAL_IRQ_LOCK(send_msg_lock);
 
 static inline void send_msg(struct cn_msg *msg)
 {
-   preempt_disable();
+   /* RT ordering protection, maps to preempt_disable() for !RT */
+   local_lock(send_msg_lock);
 
msg->seq = __this_cpu_inc_return(proc_event_counts) - 1;
((struct proc_event *)msg->data)->cpu = smp_processor_id();
@@ -70,7 +73,7 @@ static inline void send_msg(struct cn_ms
 */
cn_netlink_send(msg, 0, CN_IDX_PROC, GFP_NOWAIT);
 
-   preempt_enable();
+   local_unlock(send_msg_lock);
 }
 
 void proc_fork_connector(struct task_struct *task)

[patch] ftrace: Fix latency trace header alignment

[Mike Galbraith]

Line up helper arrows to the right column.

Signed-off-by: Mike Galbraith 
---
 kernel/trace/trace.c |   22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2896,17 +2896,17 @@ get_total_entries(struct trace_buffer *b
 
 static void print_lat_help_header(struct seq_file *m)
 {
-   seq_puts(m, "#   _=> CPU#  \n"
-   "#  / _---=> irqs-off  \n"
-   "# | / _--=> need-resched  \n"
-   "# || / _-=> need-resched_lazy \n"
-   "# ||| / _=> hardirq/softirq   \n"
-   "#  / _---=> preempt-depth \n"
-   "# | / _--=> preempt-lazy-depth\n"
-   "# || / _-=> migrate-disable   \n"
-   "# ||| / delay \n"
-   "#  cmd pid time  |   caller   \n"
-   "# \\   /    \\   |   /\n");
+   seq_puts(m, "#  _=> CPU#  \n"
+   "# / _---=> irqs-off  \n"
+   "#| / _--=> need-resched  \n"
+   "#|| / _-=> need-resched_lazy \n"
+   "#||| / _=> hardirq/softirq   \n"
+   "# / _---=> preempt-depth \n"
+   "#| / _--=> preempt-lazy-depth\n"
+   "#|| / _-=> migrate-disable   \n"
+   "#||| / delay \n"
+   "# cmd pid time   |  caller   \n"
+   "# \\   /     \\|  /\n");
 }
 
 static void print_event_info(struct trace_buffer *buf, struct seq_file *m)

[patch] ftrace: Fix latency trace header alignment

[Mike Galbraith]

Line up helper arrows to the right column.

Signed-off-by: Mike Galbraith 
---
 kernel/trace/trace.c |   22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2896,17 +2896,17 @@ get_total_entries(struct trace_buffer *b
 
 static void print_lat_help_header(struct seq_file *m)
 {
-   seq_puts(m, "#   _=> CPU#  \n"
-   "#  / _---=> irqs-off  \n"
-   "# | / _--=> need-resched  \n"
-   "# || / _-=> need-resched_lazy \n"
-   "# ||| / _=> hardirq/softirq   \n"
-   "#  / _---=> preempt-depth \n"
-   "# | / _--=> preempt-lazy-depth\n"
-   "# || / _-=> migrate-disable   \n"
-   "# ||| / delay \n"
-   "#  cmd pid time  |   caller   \n"
-   "# \\   /    \\   |   /\n");
+   seq_puts(m, "#  _=> CPU#  \n"
+   "# / _---=> irqs-off  \n"
+   "#| / _--=> need-resched  \n"
+   "#|| / _-=> need-resched_lazy \n"
+   "#||| / _=> hardirq/softirq   \n"
+   "# / _---=> preempt-depth \n"
+   "#| / _--=> preempt-lazy-depth\n"
+   "#|| / _-=> migrate-disable   \n"
+   "#||| / delay \n"
+   "# cmd pid time   |  caller   \n"
+   "# \\   /     \\|  /\n");
 }
 
 static void print_event_info(struct trace_buffer *buf, struct seq_file *m)

vgacon.c:undefined reference to `screen_info'

[kbuild test robot]

Hi Chen,

It's probably a bug fix that unveils the link errors.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1001354ca34179f3db924eb66672442a173147dc
commit: f69405ce6c0fc9f4a039011007371b31f80b470d openrisc: include: asm: 
Kbuild: add default "vga.h"
date:   2 years, 11 months ago
config: openrisc-alldefconfig (attached as .config)
compiler: or32-linux-gcc (GCC) 4.5.1-or32-1.0rc1
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout f69405ce6c0fc9f4a039011007371b31f80b470d
# save the attached .config to linux build tree
make.cross ARCH=openrisc 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `vgacon_save_screen':
>> vgacon.c:(.text+0x20e0): undefined reference to `screen_info'
   vgacon.c:(.text+0x20e8): undefined reference to `screen_info'
   drivers/built-in.o: In function `vgacon_init':
   vgacon.c:(.text+0x284c): undefined reference to `screen_info'
   vgacon.c:(.text+0x2850): undefined reference to `screen_info'
   drivers/built-in.o: In function `vgacon_startup':
   vgacon.c:(.text+0x28d8): undefined reference to `screen_info'
   drivers/built-in.o:vgacon.c:(.text+0x28f0): more undefined references to 
`screen_info' follow

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

vgacon.c:undefined reference to `screen_info'

[kbuild test robot]

Hi Chen,

It's probably a bug fix that unveils the link errors.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1001354ca34179f3db924eb66672442a173147dc
commit: f69405ce6c0fc9f4a039011007371b31f80b470d openrisc: include: asm: 
Kbuild: add default "vga.h"
date:   2 years, 11 months ago
config: openrisc-alldefconfig (attached as .config)
compiler: or32-linux-gcc (GCC) 4.5.1-or32-1.0rc1
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout f69405ce6c0fc9f4a039011007371b31f80b470d
# save the attached .config to linux build tree
make.cross ARCH=openrisc 

All errors (new ones prefixed by >>):

   drivers/built-in.o: In function `vgacon_save_screen':
>> vgacon.c:(.text+0x20e0): undefined reference to `screen_info'
   vgacon.c:(.text+0x20e8): undefined reference to `screen_info'
   drivers/built-in.o: In function `vgacon_init':
   vgacon.c:(.text+0x284c): undefined reference to `screen_info'
   vgacon.c:(.text+0x2850): undefined reference to `screen_info'
   drivers/built-in.o: In function `vgacon_startup':
   vgacon.c:(.text+0x28d8): undefined reference to `screen_info'
   drivers/built-in.o:vgacon.c:(.text+0x28f0): more undefined references to 
`screen_info' follow

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

drivers/gpu/drm/i915/i915_gem_gtt.c:2367: error: 'gtt_entry' may be used uninitialized in this function

[kbuild test robot]

Hi Dave,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1001354ca34179f3db924eb66672442a173147dc
commit: 85d1225ec066b2ef46fbd0ed1bae78ae1f3e6c91 drm/i915: Introduce & use new 
lightweight SGL iterators
date:   5 months ago
config: x86_64-randconfig-a0-10160938 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
git checkout 85d1225ec066b2ef46fbd0ed1bae78ae1f3e6c91
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All errors (new ones prefixed by >>):

   cc1: warnings being treated as errors
   drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen8_ggtt_insert_entries':
>> drivers/gpu/drm/i915/i915_gem_gtt.c:2367: error: 'gtt_entry' may be used 
>> uninitialized in this function
   drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen6_ggtt_insert_entries':
   drivers/gpu/drm/i915/i915_gem_gtt.c:2442: error: 'gtt_entry' may be used 
uninitialized in this function

vim +/gtt_entry +2367 drivers/gpu/drm/i915/i915_gem_gtt.c

  2361   enum i915_cache_level level, u32 
unused)
  2362  {
  2363  struct drm_i915_private *dev_priv = to_i915(vm->dev);
  2364  struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
  2365  struct sgt_iter sgt_iter;
  2366  gen8_pte_t __iomem *gtt_entries;
> 2367  gen8_pte_t gtt_entry;
  2368  dma_addr_t addr;
  2369  int rpm_atomic_seq;
  2370  int i = 0;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

drivers/gpu/drm/i915/i915_gem_gtt.c:2367: error: 'gtt_entry' may be used uninitialized in this function

[kbuild test robot]

Hi Dave,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1001354ca34179f3db924eb66672442a173147dc
commit: 85d1225ec066b2ef46fbd0ed1bae78ae1f3e6c91 drm/i915: Introduce & use new 
lightweight SGL iterators
date:   5 months ago
config: x86_64-randconfig-a0-10160938 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
git checkout 85d1225ec066b2ef46fbd0ed1bae78ae1f3e6c91
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All errors (new ones prefixed by >>):

   cc1: warnings being treated as errors
   drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen8_ggtt_insert_entries':
>> drivers/gpu/drm/i915/i915_gem_gtt.c:2367: error: 'gtt_entry' may be used 
>> uninitialized in this function
   drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen6_ggtt_insert_entries':
   drivers/gpu/drm/i915/i915_gem_gtt.c:2442: error: 'gtt_entry' may be used 
uninitialized in this function

vim +/gtt_entry +2367 drivers/gpu/drm/i915/i915_gem_gtt.c

  2361   enum i915_cache_level level, u32 
unused)
  2362  {
  2363  struct drm_i915_private *dev_priv = to_i915(vm->dev);
  2364  struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
  2365  struct sgt_iter sgt_iter;
  2366  gen8_pte_t __iomem *gtt_entries;
> 2367  gen8_pte_t gtt_entry;
  2368  dma_addr_t addr;
  2369  int rpm_atomic_seq;
  2370  int i = 0;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3900' requires '-mfp32'

[kbuild test robot]

Hi Guenter,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1001354ca34179f3db924eb66672442a173147dc
commit: 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e MIPS: VDSO: Fix build error 
with binutils 2.24 and earlier
date:   10 months ago
config: mips-jmr3927_defconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3900' requires '-mfp32'
/*


vim +1 arch/mips/vdso/gettimeofday.c

a7f4df4e Alex Smith 2015-10-21 @1  /*
a7f4df4e Alex Smith 2015-10-21  2   * Copyright (C) 2015 Imagination 
Technologies
a7f4df4e Alex Smith 2015-10-21  3   * Author: Alex Smith 
a7f4df4e Alex Smith 2015-10-21  4   *
a7f4df4e Alex Smith 2015-10-21  5   * This program is free software; you can 
redistribute it and/or modify it
a7f4df4e Alex Smith 2015-10-21  6   * under the terms of the GNU General Public 
License as published by the
a7f4df4e Alex Smith 2015-10-21  7   * Free Software Foundation;  either version 
2 of the  License, or (at your
a7f4df4e Alex Smith 2015-10-21  8   * option) any later version.
a7f4df4e Alex Smith 2015-10-21  9   */

:: The code at line 1 was first introduced by commit
:: a7f4df4e21dd8a8dab96e88acd2c9c5017b83fc6 MIPS: VDSO: Add implementations 
of gettimeofday() and clock_gettime()

:: TO: Alex Smith 
:: CC: Ralf Baechle 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3900' requires '-mfp32'

[kbuild test robot]

Hi Guenter,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1001354ca34179f3db924eb66672442a173147dc
commit: 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e MIPS: VDSO: Fix build error 
with binutils 2.24 and earlier
date:   10 months ago
config: mips-jmr3927_defconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3900' requires '-mfp32'
/*


vim +1 arch/mips/vdso/gettimeofday.c

a7f4df4e Alex Smith 2015-10-21 @1  /*
a7f4df4e Alex Smith 2015-10-21  2   * Copyright (C) 2015 Imagination 
Technologies
a7f4df4e Alex Smith 2015-10-21  3   * Author: Alex Smith 
a7f4df4e Alex Smith 2015-10-21  4   *
a7f4df4e Alex Smith 2015-10-21  5   * This program is free software; you can 
redistribute it and/or modify it
a7f4df4e Alex Smith 2015-10-21  6   * under the terms of the GNU General Public 
License as published by the
a7f4df4e Alex Smith 2015-10-21  7   * Free Software Foundation;  either version 
2 of the  License, or (at your
a7f4df4e Alex Smith 2015-10-21  8   * option) any later version.
a7f4df4e Alex Smith 2015-10-21  9   */

:: The code at line 1 was first introduced by commit
:: a7f4df4e21dd8a8dab96e88acd2c9c5017b83fc6 MIPS: VDSO: Add implementations 
of gettimeofday() and clock_gettime()

:: TO: Alex Smith 
:: CC: Ralf Baechle 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

arch/mips/vdso/elf.S:1:0: error: '-march=r3900' requires '-mfp32'

[kbuild test robot]

Hi Alex,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1001354ca34179f3db924eb66672442a173147dc
commit: ebb5e78cc63417a35254a791de66e1cc84f963cc MIPS: Initial implementation 
of a VDSO
date:   11 months ago
config: mips-jmr3927_defconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ebb5e78cc63417a35254a791de66e1cc84f963cc
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> arch/mips/vdso/elf.S:1:0: error: '-march=r3900' requires '-mfp32'
/*

--
>> arch/mips/vdso/sigreturn.S:1:0: error: '-march=r3900' requires '-mfp32'
/*


vim +1 arch/mips/vdso/elf.S

   > 1  /*
 2   * Copyright (C) 2015 Imagination Technologies
 3   * Author: Alex Smith 
 4   *

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

arch/mips/vdso/elf.S:1:0: error: '-march=r3900' requires '-mfp32'

[kbuild test robot]

Hi Alex,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1001354ca34179f3db924eb66672442a173147dc
commit: ebb5e78cc63417a35254a791de66e1cc84f963cc MIPS: Initial implementation 
of a VDSO
date:   11 months ago
config: mips-jmr3927_defconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ebb5e78cc63417a35254a791de66e1cc84f963cc
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> arch/mips/vdso/elf.S:1:0: error: '-march=r3900' requires '-mfp32'
/*

--
>> arch/mips/vdso/sigreturn.S:1:0: error: '-march=r3900' requires '-mfp32'
/*


vim +1 arch/mips/vdso/elf.S

   > 1  /*
 2   * Copyright (C) 2015 Imagination Technologies
 3   * Author: Alex Smith 
 4   *

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 1/5] KVM: x86: avoid atomic operations on APICv vmentry

[Michael S. Tsirkin]

On Sat, Oct 15, 2016 at 03:47:45AM -0400, Paolo Bonzini wrote:
> 
> > > On Oct 14, 2016, at 11:56 AM, Paolo Bonzini  wrote:
> > >>> 
> > >>> for (i = 0; i <= 7; i++) {
> > >>> -   pir_val = xchg([i], 0);
> > >>> -   if (pir_val)
> > >>> +   pir_val = READ_ONCE(pir[i]);
> > >> 
> > >> Out of curiosity, do you really need this READ_ONCE?
> > > 
> > > The answer can only be "depends on the compiler's whims". :)
> > > If you think of READ_ONCE as a C11 relaxed atomic load, then yes.
> > 
> > Hm.. So the idea is to make the code "race-free” in the sense
> > that every concurrent memory access is done using READ_ONCE/WRITE_ONCE?
> > 
> > If that is the case, I think there are many other cases that need to be
> > changed, for example apic->irr_pending and vcpu->arch.pv.pv_unhalted.
> 
> There is no documentation for this in the kernel tree unfortunately.
> But yes, I think we should do that.  Using READ_ONCE/WRITE_ONCE around
> memory barriers is a start.
> 
> Paolo

I'm beginning to think that if a value is always (maybe except for init
where we don't much care about the code size anyway) accessed through
*_ONCE macros, we should just mark it volatile and be done with it. The
code will look cleaner, and there will be less space for errors
like forgetting *_ONCE macros.

Would such code (where all accesses are done through
READ_ONCE/WRITE_ONCE otherwise) be an exception to
volatile-considered-harmful.txt rules?

Cc Paul and Jonathan (for volatile-considered-harmful.txt).


-- 
MST

Re: [PATCH 1/5] KVM: x86: avoid atomic operations on APICv vmentry

[Michael S. Tsirkin]

On Sat, Oct 15, 2016 at 03:47:45AM -0400, Paolo Bonzini wrote:
> 
> > > On Oct 14, 2016, at 11:56 AM, Paolo Bonzini  wrote:
> > >>> 
> > >>> for (i = 0; i <= 7; i++) {
> > >>> -   pir_val = xchg([i], 0);
> > >>> -   if (pir_val)
> > >>> +   pir_val = READ_ONCE(pir[i]);
> > >> 
> > >> Out of curiosity, do you really need this READ_ONCE?
> > > 
> > > The answer can only be "depends on the compiler's whims". :)
> > > If you think of READ_ONCE as a C11 relaxed atomic load, then yes.
> > 
> > Hm.. So the idea is to make the code "race-free” in the sense
> > that every concurrent memory access is done using READ_ONCE/WRITE_ONCE?
> > 
> > If that is the case, I think there are many other cases that need to be
> > changed, for example apic->irr_pending and vcpu->arch.pv.pv_unhalted.
> 
> There is no documentation for this in the kernel tree unfortunately.
> But yes, I think we should do that.  Using READ_ONCE/WRITE_ONCE around
> memory barriers is a start.
> 
> Paolo

I'm beginning to think that if a value is always (maybe except for init
where we don't much care about the code size anyway) accessed through
*_ONCE macros, we should just mark it volatile and be done with it. The
code will look cleaner, and there will be less space for errors
like forgetting *_ONCE macros.

Would such code (where all accesses are done through
READ_ONCE/WRITE_ONCE otherwise) be an exception to
volatile-considered-harmful.txt rules?

Cc Paul and Jonathan (for volatile-considered-harmful.txt).


-- 
MST

Re: when to size_t for representing length instead of int ?

[none]

Le 2016-10-14 01:37, Al Viro a écrit :

On Fri, Oct 14, 2016 at 12:12:43AM +0200, none wrote:

Hello,

I wanted to known the rules in coding guidelines concerning the use of
size_t.
It seems the signed int type is used most of the time for representing
string sizes, including in some parts written by Linus in /lib.
They’re can buffer overflows attack if ssize_t if larger than 
sizeof(int)

(though I agree this isn’t the only way, but at least it´s less error
prone).


Huh?  size_t is the type of sizoef result; ssize_t is its signed 
counterpart.
With large strings, you can make buffer overflows by turning ints into 
negative values (this lead to cwe 195). However, they just crash the 
process and thus can’t be used for remote code execution. So as long as 
the truncation can’t lead to positive values there’s nothing to fear 
(which mean using in instead of size_t is acceptable if the machine 
isn’t big_endian).


So is it guaranteed for all current and future cpu architectures the 
Linux

kernel support that ssize_t will always be equal to sizeof(int) ?


Of course it isn't.  Not true on any 64bit architecture we support...

No this is guaranteed, at least for amd64 because of -mcmodel=kernel

What attacks are, in your opinion, enabled by that fact?  I'm sure that
libc (and C standard) folks would be very interested, considering that
e.g. strlen() is declared as function that takes a pointer to const 
char and

returns size_t...
Plenty  attacks which leads to plenty types of cwe (192 or 190)… 
Basically you feed the software with a string which can fit in size_t 
but not in an unsigned int.
I call this “size_t to positive int truncation” attacks (too bad that 
there’s no specific cwe for it). This rely on the following abi 
characteristics :
— being able to get a variable representing the length of a string 
(which uses size_t because of malloc) to a positive value of a variable 
which use the “int” type
— being on little endian machine makes the remote execution easier 
(because bettes every odd values which count the number of times of 
sizeof(int) the buffer overflow will be positive).


But the best illustration of this is probably myself being listed in the 
top ten of https://bounty.github.com because of that kind of bug in git 
:)

iii

Re: when to size_t for representing length instead of int ?

[none]

Le 2016-10-14 01:37, Al Viro a écrit :

On Fri, Oct 14, 2016 at 12:12:43AM +0200, none wrote:

Hello,

I wanted to known the rules in coding guidelines concerning the use of
size_t.
It seems the signed int type is used most of the time for representing
string sizes, including in some parts written by Linus in /lib.
They’re can buffer overflows attack if ssize_t if larger than 
sizeof(int)

(though I agree this isn’t the only way, but at least it´s less error
prone).


Huh?  size_t is the type of sizoef result; ssize_t is its signed 
counterpart.
With large strings, you can make buffer overflows by turning ints into 
negative values (this lead to cwe 195). However, they just crash the 
process and thus can’t be used for remote code execution. So as long as 
the truncation can’t lead to positive values there’s nothing to fear 
(which mean using in instead of size_t is acceptable if the machine 
isn’t big_endian).


So is it guaranteed for all current and future cpu architectures the 
Linux

kernel support that ssize_t will always be equal to sizeof(int) ?


Of course it isn't.  Not true on any 64bit architecture we support...

No this is guaranteed, at least for amd64 because of -mcmodel=kernel

What attacks are, in your opinion, enabled by that fact?  I'm sure that
libc (and C standard) folks would be very interested, considering that
e.g. strlen() is declared as function that takes a pointer to const 
char and

returns size_t...
Plenty  attacks which leads to plenty types of cwe (192 or 190)… 
Basically you feed the software with a string which can fit in size_t 
but not in an unsigned int.
I call this “size_t to positive int truncation” attacks (too bad that 
there’s no specific cwe for it). This rely on the following abi 
characteristics :
— being able to get a variable representing the length of a string 
(which uses size_t because of malloc) to a positive value of a variable 
which use the “int” type
— being on little endian machine makes the remote execution easier 
(because bettes every odd values which count the number of times of 
sizeof(int) the buffer overflow will be positive).


But the best illustration of this is probably myself being listed in the 
top ten of https://bounty.github.com because of that kind of bug in git 
:)

iii

[patch] perf_event_open.2: PERF_RECORD_LOST_SAMPLES record type

[Vince Weaver]

Linux 4.2 added a new record type: PERF_RECORD_LOST_SAMPLES
It is generated when hardware samples (currently only Intel PEBS)
are lost.

Signed-off-by: Vince Weaver 

diff --git a/man2/perf_event_open.2 b/man2/perf_event_open.2
index 9f33122..a47df2d 100644
--- a/man2/perf_event_open.2
+++ b/man2/perf_event_open.2
@@ -2551,6 +2551,25 @@ process ID of the thread starting an instruction trace.
 .I tid
 thread ID of the thread starting an instruction trace.
 .RE
+.TP
+.BR PERF_RECORD_LOST_SAMPLES " (since Linux 4.2)"
+\" f38b0dbb491a6987e198aa6b428db8692a6480f8
+When using hardware sampling (such as Intel PEBS) this record
+indicates some number of samples may have been lost.
+
+.in +4n
+.nf
+struct {
+struct perf_event_header header;
+u64 lost;
+struct sample_id sample_id;
+};
+.fi
+.RS
+.TP
+.I lost
+the number of potentially lost samples.
+.RE
 .RE
 .SS Overflow handling
 Events can be set to notify when a threshold is crossed,

[patch] perf_event_open.2: PERF_RECORD_LOST_SAMPLES record type

[Vince Weaver]

Linux 4.2 added a new record type: PERF_RECORD_LOST_SAMPLES
It is generated when hardware samples (currently only Intel PEBS)
are lost.

Signed-off-by: Vince Weaver 

diff --git a/man2/perf_event_open.2 b/man2/perf_event_open.2
index 9f33122..a47df2d 100644
--- a/man2/perf_event_open.2
+++ b/man2/perf_event_open.2
@@ -2551,6 +2551,25 @@ process ID of the thread starting an instruction trace.
 .I tid
 thread ID of the thread starting an instruction trace.
 .RE
+.TP
+.BR PERF_RECORD_LOST_SAMPLES " (since Linux 4.2)"
+\" f38b0dbb491a6987e198aa6b428db8692a6480f8
+When using hardware sampling (such as Intel PEBS) this record
+indicates some number of samples may have been lost.
+
+.in +4n
+.nf
+struct {
+struct perf_event_header header;
+u64 lost;
+struct sample_id sample_id;
+};
+.fi
+.RS
+.TP
+.I lost
+the number of potentially lost samples.
+.RE
 .RE
 .SS Overflow handling
 Events can be set to notify when a threshold is crossed,

virtio-rng scatterlist null pointer dereference with VMAP_STACK=y

[Matt Mullins]

With VMAP_STACK=y and HW_RANDOM_VIRTIO=y, I get the following crash:

[1.470437] BUG: unable to handle kernel NULL pointer dereference at  (null)
[1.473350] IP: [] sg_init_one+0x65/0x90
[1.474658] PGD 0 
[1.475169] Oops:  [#1] SMP

Entering kdb (current=0x880069b0c980, pid 1) on processor 1 Oops: (null)
due to oops @ 0x812f7c35
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.8.0-08682-g41844e3 #246
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 880069b0c980 task.stack: c9c54000
RIP: 0010:[]  [] sg_init_one+0x65/0x90
RSP: :c9c57d00  EFLAGS: 00010246
RAX:  RBX: c9c57d20 RCX: 00082000
RDX: 0d68 RSI: 00041c57 RDI: c9c57d40
RBP: 0820 R08:  R09: c9c57d20
R10: 00019228 R11: 88017fff8500 R12: 0010
R13: 0010 R14:  R15: 
FS:  () GS:88017fc0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2:  CR3: 01806000 CR4: 001406a0
Stack:
 8800694bf500 0001 c9c57d68 8138286f
 0002   
 8800694bf500 c9c57d68 8800694bf500 
Call Trace:
 [] ? virtio_read+0x9f/0xe0
 [] ? add_early_randomness+0x3e/0xa0
 [] ? set_current_rng+0x3f/0x160
 [] ? hwrng_register+0x186/0x1d0
 [] ? virtrng_scan+0x10/0x20
 [] ? virtio_dev_probe+0x21e/0x2b0
 [] ? really_probe+0x14e/0x250
 [] ? __driver_attach+0x82/0xa0
 [] ? really_probe+0x250/0x250
 [] ? bus_for_each_dev+0x52/0x80
 [] ? bus_add_driver+0x1a3/0x220
 [] ? hwrng_modinit+0xc/0xc
 [] ? driver_register+0x56/0xd0
 [] ? hwrng_modinit+0xc/0xc
 [] ? do_one_initcall+0x32/0x150
 [] ? parse_args+0x170/0x390
 [] ? kernel_init_freeable+0x11e/0x1a3
 [] ? set_debug_rodata+0xc/0xc
 [] ? rest_init+0x70/0x70
 [] ? kernel_init+0x5/0x100
 [] ? ret_from_fork+0x25/0x30
Code: 01 c5 48 89 ee 48 89 e9 48 c1 ed 23 48 8b 04 ed c0 49 9c 81 48 c1 ee 0c
48 c1 e9 1b 48 85 c0 74 0a 0f b6 c9 48 c1 e1 04 48 01 c8 <48> 8b 08 48 89 f0 89
53 08 48 c1 e0 06 44 89 63 0c 48 83 e1 fc 


It looks like add_early_randomness() uses a buffer on the stack, which (with
VMAP_STACK) fails to be added to a scatterlist due to use of virt_to_page in
sg_set_buf().

None of this looks obviously wrong to me, but in combination it is not
functional.  Hence, I don't have a particular fix in mind, and I've CC'ed folks
from both the hw_random and scatterlist history.

virtio-rng scatterlist null pointer dereference with VMAP_STACK=y

[Matt Mullins]

With VMAP_STACK=y and HW_RANDOM_VIRTIO=y, I get the following crash:

[1.470437] BUG: unable to handle kernel NULL pointer dereference at  (null)
[1.473350] IP: [] sg_init_one+0x65/0x90
[1.474658] PGD 0 
[1.475169] Oops:  [#1] SMP

Entering kdb (current=0x880069b0c980, pid 1) on processor 1 Oops: (null)
due to oops @ 0x812f7c35
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.8.0-08682-g41844e3 #246
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 880069b0c980 task.stack: c9c54000
RIP: 0010:[]  [] sg_init_one+0x65/0x90
RSP: :c9c57d00  EFLAGS: 00010246
RAX:  RBX: c9c57d20 RCX: 00082000
RDX: 0d68 RSI: 00041c57 RDI: c9c57d40
RBP: 0820 R08:  R09: c9c57d20
R10: 00019228 R11: 88017fff8500 R12: 0010
R13: 0010 R14:  R15: 
FS:  () GS:88017fc0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2:  CR3: 01806000 CR4: 001406a0
Stack:
 8800694bf500 0001 c9c57d68 8138286f
 0002   
 8800694bf500 c9c57d68 8800694bf500 
Call Trace:
 [] ? virtio_read+0x9f/0xe0
 [] ? add_early_randomness+0x3e/0xa0
 [] ? set_current_rng+0x3f/0x160
 [] ? hwrng_register+0x186/0x1d0
 [] ? virtrng_scan+0x10/0x20
 [] ? virtio_dev_probe+0x21e/0x2b0
 [] ? really_probe+0x14e/0x250
 [] ? __driver_attach+0x82/0xa0
 [] ? really_probe+0x250/0x250
 [] ? bus_for_each_dev+0x52/0x80
 [] ? bus_add_driver+0x1a3/0x220
 [] ? hwrng_modinit+0xc/0xc
 [] ? driver_register+0x56/0xd0
 [] ? hwrng_modinit+0xc/0xc
 [] ? do_one_initcall+0x32/0x150
 [] ? parse_args+0x170/0x390
 [] ? kernel_init_freeable+0x11e/0x1a3
 [] ? set_debug_rodata+0xc/0xc
 [] ? rest_init+0x70/0x70
 [] ? kernel_init+0x5/0x100
 [] ? ret_from_fork+0x25/0x30
Code: 01 c5 48 89 ee 48 89 e9 48 c1 ed 23 48 8b 04 ed c0 49 9c 81 48 c1 ee 0c
48 c1 e9 1b 48 85 c0 74 0a 0f b6 c9 48 c1 e1 04 48 01 c8 <48> 8b 08 48 89 f0 89
53 08 48 c1 e0 06 44 89 63 0c 48 83 e1 fc 


It looks like add_early_randomness() uses a buffer on the stack, which (with
VMAP_STACK) fails to be added to a scatterlist due to use of virt_to_page in
sg_set_buf().

None of this looks obviously wrong to me, but in combination it is not
functional.  Hence, I don't have a particular fix in mind, and I've CC'ed folks
from both the hw_random and scatterlist history.

Re: btrfs bio linked list corruption.

[Dave Jones]

On Thu, Oct 13, 2016 at 05:18:46PM -0400, Chris Mason wrote:

 > >  > > .. and of course the first thing that happens is a completely 
 > > different
 > >  > > btrfs trace..
 > >  > >
 > >  > >
 > >  > > WARNING: CPU: 1 PID: 21706 at fs/btrfs/transaction.c:489 
 > > start_transaction+0x40a/0x440 [btrfs]
 > >  > > CPU: 1 PID: 21706 Comm: trinity-c16 Not tainted 4.8.0-think+ #14
 > >  > >  c900019076a8 b731ff3c  
 > >  > >  c900019076e8 b707a6c1 01e9f5806ce0 8804f74c4d98
 > >  > >  0801 880501cfa2a8 008a 008a
 > >  >
 > >  > This isn't even IO.  Uuug.  We're going to need a fast enough test
 > >  > that we can bisect.
 > >
 > > Progress...
 > > I've found that this combination of syscalls..
 > >
 > > ./trinity -C64 -q -l off -a64 --enable-fds=testfile -c fsync -c fsetxattr 
 > > -c lremovexattr -c pwritev2
 > >
 > > hits one of these two bugs in a few minutes runtime.
 > >
 > > Just the xattr syscalls + fsync isn't enough, neither is just pwrite + 
 > > fsync.
 > > Mix them together though, and something goes awry.
 > >
 > Hasn't triggered here yet.  I'll leave it running though.

The hits keep coming..

BUG: Bad page state in process kworker/u8:12  pfn:4988fa
page:ea0012623e80 count:0 mapcount:0 mapping:8804450456e0 index:0x9

flags: 0x400c(referenced|uptodate)
page dumped because: non-NULL mapping
CPU: 2 PID: 1388 Comm: kworker/u8:12 Not tainted 4.8.0-think+ #18 
Workqueue: writeback wb_workfn
 (flush-btrfs-1)

 c9aef7e8
 81320e7c
 ea0012623e80
 819fe6ec

 c9aef810
 81159b3f
 
 ea0012623e80

 400c
 c9aef820
 81159bfa
 c9aef868

Call Trace:
 [] dump_stack+0x4f/0x73
 [] bad_page+0xbf/0x120
 [] free_pages_check_bad+0x5a/0x70
 [] free_hot_cold_page+0x20b/0x270
 [] free_hot_cold_page_list+0x2b/0x50
 [] release_pages+0x2d2/0x380
 [] __pagevec_release+0x22/0x30
 [] extent_write_cache_pages.isra.48.constprop.63+0x350/0x430 
[btrfs]
 [] ? debug_smp_processor_id+0x17/0x20
 [] ? get_lock_stats+0x19/0x50
 [] extent_writepages+0x58/0x80 [btrfs]
 [] ? btrfs_releasepage+0x40/0x40 [btrfs]
 [] btrfs_writepages+0x23/0x30 [btrfs]
 [] do_writepages+0x1c/0x30
 [] __writeback_single_inode+0x33/0x180
 [] writeback_sb_inodes+0x2cb/0x5d0
 [] __writeback_inodes_wb+0x8d/0xc0
 [] wb_writeback+0x203/0x210
 [] wb_workfn+0xe7/0x2a0
 [] ? __lock_acquire.isra.32+0x1cf/0x8c0
 [] process_one_work+0x1da/0x4b0
 [] ? process_one_work+0x17a/0x4b0
 [] worker_thread+0x49/0x490
 [] ? process_one_work+0x4b0/0x4b0
 [] ? process_one_work+0x4b0/0x4b0

Re: btrfs bio linked list corruption.

[Dave Jones]

On Thu, Oct 13, 2016 at 05:18:46PM -0400, Chris Mason wrote:

 > >  > > .. and of course the first thing that happens is a completely 
 > > different
 > >  > > btrfs trace..
 > >  > >
 > >  > >
 > >  > > WARNING: CPU: 1 PID: 21706 at fs/btrfs/transaction.c:489 
 > > start_transaction+0x40a/0x440 [btrfs]
 > >  > > CPU: 1 PID: 21706 Comm: trinity-c16 Not tainted 4.8.0-think+ #14
 > >  > >  c900019076a8 b731ff3c  
 > >  > >  c900019076e8 b707a6c1 01e9f5806ce0 8804f74c4d98
 > >  > >  0801 880501cfa2a8 008a 008a
 > >  >
 > >  > This isn't even IO.  Uuug.  We're going to need a fast enough test
 > >  > that we can bisect.
 > >
 > > Progress...
 > > I've found that this combination of syscalls..
 > >
 > > ./trinity -C64 -q -l off -a64 --enable-fds=testfile -c fsync -c fsetxattr 
 > > -c lremovexattr -c pwritev2
 > >
 > > hits one of these two bugs in a few minutes runtime.
 > >
 > > Just the xattr syscalls + fsync isn't enough, neither is just pwrite + 
 > > fsync.
 > > Mix them together though, and something goes awry.
 > >
 > Hasn't triggered here yet.  I'll leave it running though.

The hits keep coming..

BUG: Bad page state in process kworker/u8:12  pfn:4988fa
page:ea0012623e80 count:0 mapcount:0 mapping:8804450456e0 index:0x9

flags: 0x400c(referenced|uptodate)
page dumped because: non-NULL mapping
CPU: 2 PID: 1388 Comm: kworker/u8:12 Not tainted 4.8.0-think+ #18 
Workqueue: writeback wb_workfn
 (flush-btrfs-1)

 c9aef7e8
 81320e7c
 ea0012623e80
 819fe6ec

 c9aef810
 81159b3f
 
 ea0012623e80

 400c
 c9aef820
 81159bfa
 c9aef868

Call Trace:
 [] dump_stack+0x4f/0x73
 [] bad_page+0xbf/0x120
 [] free_pages_check_bad+0x5a/0x70
 [] free_hot_cold_page+0x20b/0x270
 [] free_hot_cold_page_list+0x2b/0x50
 [] release_pages+0x2d2/0x380
 [] __pagevec_release+0x22/0x30
 [] extent_write_cache_pages.isra.48.constprop.63+0x350/0x430 
[btrfs]
 [] ? debug_smp_processor_id+0x17/0x20
 [] ? get_lock_stats+0x19/0x50
 [] extent_writepages+0x58/0x80 [btrfs]
 [] ? btrfs_releasepage+0x40/0x40 [btrfs]
 [] btrfs_writepages+0x23/0x30 [btrfs]
 [] do_writepages+0x1c/0x30
 [] __writeback_single_inode+0x33/0x180
 [] writeback_sb_inodes+0x2cb/0x5d0
 [] __writeback_inodes_wb+0x8d/0xc0
 [] wb_writeback+0x203/0x210
 [] wb_workfn+0xe7/0x2a0
 [] ? __lock_acquire.isra.32+0x1cf/0x8c0
 [] process_one_work+0x1da/0x4b0
 [] ? process_one_work+0x17a/0x4b0
 [] worker_thread+0x49/0x490
 [] ? process_one_work+0x4b0/0x4b0
 [] ? process_one_work+0x4b0/0x4b0

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Omar Sandoval]

On Fri, Oct 14, 2016 at 10:12:46PM +0200, Michal Marek wrote:
> Hi Linus,
> 
> please pull these kbuild changes for v4.9-rc1:
> 
> - EXPORT_SYMBOL for asm source by Al Viro. This does bring a regression,
>   because genksyms no longer generates checksums for these symbols
>   (CONFIG_MODVERSIONS). Nick Piggin is working on a patch to fix this.
>   Plus, we are talking about functions like strcpy(), which rarely
>   change prototypes.

So this has broken all module loading for me. I get the following dmesg
spew:

...
[4.586914] scsi_mod: no symbol version for memset
[4.587920] scsi_mod: Unknown symbol memset (err -22)
[4.588443] scsi_mod: no symbol version for ___preempt_schedule
[4.589026] scsi_mod: Unknown symbol ___preempt_schedule (err -22)
...

Reverting 784d5699eddc ("x86: move exports to actual definitions") fixes
it for me. This is with GCC 6.2.1, binutils 2.27, attached config.

-- 
Omar
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.9.0-rc1 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y

#
# RCU Subsystem
#
CONFIG_PREEMPT_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
# CONFIG_TASKS_RCU is not set
CONFIG_RCU_STALL_COMMON=y
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_EXPEDITE_BOOT is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=19
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_NMI_LOG_BUF_SHIFT=13
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_ARCH_SUPPORTS_INT128=y
CONFIG_NUMA_BALANCING=y
CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
CONFIG_CGROUPS=y
CONFIG_PAGE_COUNTER=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_MEMCG_SWAP_ENABLED=y
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_CGROUP_WRITEBACK=y
CONFIG_CGROUP_SCHED=y

Re: [GIT PULL] kbuild changes for v4.9-rc1

[Omar Sandoval]

On Fri, Oct 14, 2016 at 10:12:46PM +0200, Michal Marek wrote:
> Hi Linus,
> 
> please pull these kbuild changes for v4.9-rc1:
> 
> - EXPORT_SYMBOL for asm source by Al Viro. This does bring a regression,
>   because genksyms no longer generates checksums for these symbols
>   (CONFIG_MODVERSIONS). Nick Piggin is working on a patch to fix this.
>   Plus, we are talking about functions like strcpy(), which rarely
>   change prototypes.

So this has broken all module loading for me. I get the following dmesg
spew:

...
[4.586914] scsi_mod: no symbol version for memset
[4.587920] scsi_mod: Unknown symbol memset (err -22)
[4.588443] scsi_mod: no symbol version for ___preempt_schedule
[4.589026] scsi_mod: Unknown symbol ___preempt_schedule (err -22)
...

Reverting 784d5699eddc ("x86: move exports to actual definitions") fixes
it for me. This is with GCC 6.2.1, binutils 2.27, attached config.

-- 
Omar
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.9.0-rc1 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y

#
# RCU Subsystem
#
CONFIG_PREEMPT_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
# CONFIG_TASKS_RCU is not set
CONFIG_RCU_STALL_COMMON=y
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_EXPEDITE_BOOT is not set
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=19
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_NMI_LOG_BUF_SHIFT=13
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_ARCH_SUPPORTS_INT128=y
CONFIG_NUMA_BALANCING=y
CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
CONFIG_CGROUPS=y
CONFIG_PAGE_COUNTER=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_MEMCG_SWAP_ENABLED=y
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_CGROUP_WRITEBACK=y
CONFIG_CGROUP_SCHED=y

linux-next: Tree for Oct 16

[Stephen Rothwell]

Hi all,

Changes since 20161014:

The net tree gained a conflict against Linus' tree.

The akpm-current tree still had its build failures for which I applied
2 patches.

Non-merge commits (relative to Linus' tree): 389
 614 files changed, 17748 insertions(+), 3167 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 243 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (1001354ca341 Linux 4.9-rc1)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when 
not configured)
Merging arc-current/for-curr (8df0cc75f530 ARC: [build] Support gz, lzma 
compressed uImage)
Merging arm-current/fixes (fb833b1fbb68 ARM: fix delays)
Merging m68k-current/for-linus (6736e65effc3 m68k: Migrate exception table 
users off module.h and onto extable.h)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (b79331a5eb9f powerpc/powernv/pci: Fix m64 checks 
for SR-IOV and window alignment)
Merging sparc/master (4c1fad64eff4 Merge tag 'for-f2fs-4.9' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs)
Merging net/master (9e55d0f95460 Merge tag 
'wireless-drivers-for-davem-2016-10-14' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers)
CONFLICT (content): Merge conflict in drivers/net/ethernet/qlogic/Kconfig
Applying: qed*: merge fix for CONFIG_INFINIBAND_QEDR Kconfig move
Merging ipsec/master (7f92083eb58f vti6: flush x-netns xfrm cache when vti 
interface is removed)
Merging netfilter/master (6d3a4c404648 strparser: Propagate correct error code 
in strp_recv())
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (1ea2643961b0 ath6kl: add Dell OEM SDIO I/O for 
the Venue 8 Pro)
Merging mac80211/master (1d4de2e222b4 mac80211: fix CMD_FRAME for AP_VLAN)
Merging sound-current/for-linus (fdd8218d7d1b ALSA: line6: fix a crash in 
line6_hwdep_write())
Merging pci-current/for-linus (035ee288ae7a PCI: Fix bridge_d3 update on device 
removal)
Merging driver-core.current/driver-core-linus (b66484cd7470 Merge branch 'akpm' 
(patches from Andrew))
Merging tty.current/tty-linus (b66484cd7470 Merge branch 'akpm' (patches from 
Andrew))
Merging usb.current/usb-linus (b66484cd7470 Merge branch 'akpm' (patches from 
Andrew))
Merging usb-gadget-fixes/fixes (d8a4100ddc75 usb: gadget: udc: atmel: fix 
endpoint name)
Merging usb-serial-fixes/usb-linus (f190fd92458d USB: serial: simple: add 
support for another Infineon flashloader)
Merging usb-chipidea-fixes/ci-for-usb-stable (6b7f456e67a1 usb: chipidea: host: 
fix NULL ptr dereference during shutdown)
Merging staging.current/staging-linus (29fbff8698fc Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging char-misc.current/char-misc-linus (b66484cd7470 Merge branch 'akpm' 
(patches from Andrew))
Merging input-current/for-linus (1134ca268e73 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (c3afafa47898 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix 

linux-next: Tree for Oct 16

[Stephen Rothwell]

Hi all,

Changes since 20161014:

The net tree gained a conflict against Linus' tree.

The akpm-current tree still had its build failures for which I applied
2 patches.

Non-merge commits (relative to Linus' tree): 389
 614 files changed, 17748 insertions(+), 3167 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 243 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (1001354ca341 Linux 4.9-rc1)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when 
not configured)
Merging arc-current/for-curr (8df0cc75f530 ARC: [build] Support gz, lzma 
compressed uImage)
Merging arm-current/fixes (fb833b1fbb68 ARM: fix delays)
Merging m68k-current/for-linus (6736e65effc3 m68k: Migrate exception table 
users off module.h and onto extable.h)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (b79331a5eb9f powerpc/powernv/pci: Fix m64 checks 
for SR-IOV and window alignment)
Merging sparc/master (4c1fad64eff4 Merge tag 'for-f2fs-4.9' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs)
Merging net/master (9e55d0f95460 Merge tag 
'wireless-drivers-for-davem-2016-10-14' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers)
CONFLICT (content): Merge conflict in drivers/net/ethernet/qlogic/Kconfig
Applying: qed*: merge fix for CONFIG_INFINIBAND_QEDR Kconfig move
Merging ipsec/master (7f92083eb58f vti6: flush x-netns xfrm cache when vti 
interface is removed)
Merging netfilter/master (6d3a4c404648 strparser: Propagate correct error code 
in strp_recv())
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (1ea2643961b0 ath6kl: add Dell OEM SDIO I/O for 
the Venue 8 Pro)
Merging mac80211/master (1d4de2e222b4 mac80211: fix CMD_FRAME for AP_VLAN)
Merging sound-current/for-linus (fdd8218d7d1b ALSA: line6: fix a crash in 
line6_hwdep_write())
Merging pci-current/for-linus (035ee288ae7a PCI: Fix bridge_d3 update on device 
removal)
Merging driver-core.current/driver-core-linus (b66484cd7470 Merge branch 'akpm' 
(patches from Andrew))
Merging tty.current/tty-linus (b66484cd7470 Merge branch 'akpm' (patches from 
Andrew))
Merging usb.current/usb-linus (b66484cd7470 Merge branch 'akpm' (patches from 
Andrew))
Merging usb-gadget-fixes/fixes (d8a4100ddc75 usb: gadget: udc: atmel: fix 
endpoint name)
Merging usb-serial-fixes/usb-linus (f190fd92458d USB: serial: simple: add 
support for another Infineon flashloader)
Merging usb-chipidea-fixes/ci-for-usb-stable (6b7f456e67a1 usb: chipidea: host: 
fix NULL ptr dereference during shutdown)
Merging staging.current/staging-linus (29fbff8698fc Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging char-misc.current/char-misc-linus (b66484cd7470 Merge branch 'akpm' 
(patches from Andrew))
Merging input-current/for-linus (1134ca268e73 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (c3afafa47898 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix 

Re: [RFC] scripts: Include postprocessing script for memory allocation tracing

[Janani Ravichandran]

> On Oct 11, 2016, at 10:43 AM, Janani Ravichandran  
> wrote:
> 
> Alright. I’ll add a starting tracepoint, change the script accordingly and 
> send a v2. Thanks!
> 
I looked at it again and I think that the context information we need 
can be obtained from the tracepoint trace_mm_page_alloc in 
alloc_pages_nodemask().

I’ll include that tracepoint in the script and send it along with the other
changes you suggested, if you’re fine with it.

Thanks!
Janani.
>> 
> 

Re: [RFC] scripts: Include postprocessing script for memory allocation tracing

[Janani Ravichandran]

> On Oct 11, 2016, at 10:43 AM, Janani Ravichandran  
> wrote:
> 
> Alright. I’ll add a starting tracepoint, change the script accordingly and 
> send a v2. Thanks!
> 
I looked at it again and I think that the context information we need 
can be obtained from the tracepoint trace_mm_page_alloc in 
alloc_pages_nodemask().

I’ll include that tracepoint in the script and send it along with the other
changes you suggested, if you’re fine with it.

Thanks!
Janani.
>> 
> 

Re: [PATCH 0/2] net: Fix compiler warnings

[tndave]

On 10/15/2016 02:48 PM, David Miller wrote:

From: Tushar Dave 
Date: Fri, 14 Oct 2016 17:06:04 -0700


Recently, ATU (iommu) changes are submitted to linux-sparc that
enables 64bit DMA on SPARC. However, this change also makes
'incompatible pointer type' compiler warnings inevitable on sunqe
and sunbmac driver.

The two patches in series fix compiler warnings.


Only the sparc tree has this build problem, so these patches
really ought to be submitted for and applied there.

Okay. I will send these to sparclinux then.

Thanks.

-Tushar


Thanks.

Re: [PATCH 0/2] net: Fix compiler warnings

[tndave]

On 10/15/2016 02:48 PM, David Miller wrote:

From: Tushar Dave 
Date: Fri, 14 Oct 2016 17:06:04 -0700


Recently, ATU (iommu) changes are submitted to linux-sparc that
enables 64bit DMA on SPARC. However, this change also makes
'incompatible pointer type' compiler warnings inevitable on sunqe
and sunbmac driver.

The two patches in series fix compiler warnings.


Only the sparc tree has this build problem, so these patches
really ought to be submitted for and applied there.

Okay. I will send these to sparclinux then.

Thanks.

-Tushar


Thanks.

[PATCH] uapi: adfs_fs: Clean up code

[chengang]

From: Chen Gang 

Use tab instead of 4 white spaces for indent, and remove redundant empty
line.

Put constant macro definition before structure definition, so that the
structure definition can use the constant macro, e.g. ADFS_DR_SIZE.

And still left hardcode number "52" for unused52, since the name already
contents "52". If it was "unused", not "unused52", we could use struct
including union including struct to remove hardcode number "52".

Signed-off-by: Chen Gang 
---
 include/uapi/linux/adfs_fs.h | 61 ++--
 1 file changed, 30 insertions(+), 31 deletions(-)

diff --git a/include/uapi/linux/adfs_fs.h b/include/uapi/linux/adfs_fs.h
index a1bf437..0c9bc36 100644
--- a/include/uapi/linux/adfs_fs.h
+++ b/include/uapi/linux/adfs_fs.h
@@ -4,41 +4,40 @@
 #include 
 #include 
 
-/*
- * Disc Record at disc address 0xc00
- */
-struct adfs_discrecord {
-__u8  log2secsize;
-__u8  secspertrack;
-__u8  heads;
-__u8  density;
-__u8  idlen;
-__u8  log2bpmb;
-__u8  skew;
-__u8  bootoption;
-__u8  lowsector;
-__u8  nzones;
-__le16 zone_spare;
-__le32 root;
-__le32 disc_size;
-__le16 disc_id;
-__u8  disc_name[10];
-__le32 disc_type;
-__le32 disc_size_high;
-__u8  log2sharesize:4;
-__u8  unused40:4;
-__u8  big_flag:1;
-__u8  unused41:1;
-__u8  nzones_high;
-__le32 format_version;
-__le32 root_size;
-__u8  unused52[60 - 52];
-};
-
 #define ADFS_DISCRECORD(0xc00)
 #define ADFS_DR_OFFSET (0x1c0)
 #define ADFS_DR_SIZE60
 #define ADFS_DR_SIZE_BITS  (ADFS_DR_SIZE << 3)
 
+/*
+ * Disc Record at disc address 0xc00
+ */
+struct adfs_discrecord {
+   __u8  log2secsize;
+   __u8  secspertrack;
+   __u8  heads;
+   __u8  density;
+   __u8  idlen;
+   __u8  log2bpmb;
+   __u8  skew;
+   __u8  bootoption;
+   __u8  lowsector;
+   __u8  nzones;
+   __le16 zone_spare;
+   __le32 root;
+   __le32 disc_size;
+   __le16 disc_id;
+   __u8  disc_name[10];
+   __le32 disc_type;
+   __le32 disc_size_high;
+   __u8  log2sharesize:4;
+   __u8  unused40:4;
+   __u8  big_flag:1;
+   __u8  unused41:1;
+   __u8  nzones_high;
+   __le32 format_version;
+   __le32 root_size;
+   __u8  unused52[ADFS_DR_SIZE - 52];
+};
 
 #endif /* _UAPI_ADFS_FS_H */
-- 
1.9.3

[PATCH] uapi: adfs_fs: Clean up code

[chengang]

From: Chen Gang 

Use tab instead of 4 white spaces for indent, and remove redundant empty
line.

Put constant macro definition before structure definition, so that the
structure definition can use the constant macro, e.g. ADFS_DR_SIZE.

And still left hardcode number "52" for unused52, since the name already
contents "52". If it was "unused", not "unused52", we could use struct
including union including struct to remove hardcode number "52".

Signed-off-by: Chen Gang 
---
 include/uapi/linux/adfs_fs.h | 61 ++--
 1 file changed, 30 insertions(+), 31 deletions(-)

diff --git a/include/uapi/linux/adfs_fs.h b/include/uapi/linux/adfs_fs.h
index a1bf437..0c9bc36 100644
--- a/include/uapi/linux/adfs_fs.h
+++ b/include/uapi/linux/adfs_fs.h
@@ -4,41 +4,40 @@
 #include 
 #include 
 
-/*
- * Disc Record at disc address 0xc00
- */
-struct adfs_discrecord {
-__u8  log2secsize;
-__u8  secspertrack;
-__u8  heads;
-__u8  density;
-__u8  idlen;
-__u8  log2bpmb;
-__u8  skew;
-__u8  bootoption;
-__u8  lowsector;
-__u8  nzones;
-__le16 zone_spare;
-__le32 root;
-__le32 disc_size;
-__le16 disc_id;
-__u8  disc_name[10];
-__le32 disc_type;
-__le32 disc_size_high;
-__u8  log2sharesize:4;
-__u8  unused40:4;
-__u8  big_flag:1;
-__u8  unused41:1;
-__u8  nzones_high;
-__le32 format_version;
-__le32 root_size;
-__u8  unused52[60 - 52];
-};
-
 #define ADFS_DISCRECORD(0xc00)
 #define ADFS_DR_OFFSET (0x1c0)
 #define ADFS_DR_SIZE60
 #define ADFS_DR_SIZE_BITS  (ADFS_DR_SIZE << 3)
 
+/*
+ * Disc Record at disc address 0xc00
+ */
+struct adfs_discrecord {
+   __u8  log2secsize;
+   __u8  secspertrack;
+   __u8  heads;
+   __u8  density;
+   __u8  idlen;
+   __u8  log2bpmb;
+   __u8  skew;
+   __u8  bootoption;
+   __u8  lowsector;
+   __u8  nzones;
+   __le16 zone_spare;
+   __le32 root;
+   __le32 disc_size;
+   __le16 disc_id;
+   __u8  disc_name[10];
+   __le32 disc_type;
+   __le32 disc_size_high;
+   __u8  log2sharesize:4;
+   __u8  unused40:4;
+   __u8  big_flag:1;
+   __u8  unused41:1;
+   __u8  nzones_high;
+   __le32 format_version;
+   __le32 root_size;
+   __u8  unused52[ADFS_DR_SIZE - 52];
+};
 
 #endif /* _UAPI_ADFS_FS_H */
-- 
1.9.3

Re: [PATCH v3] mm: vmalloc: Replace purge_lock spinlock with atomic refcount

[Joel Fernandes]

Hi Christoph,

On Sat, Oct 15, 2016 at 9:54 AM, Christoph Hellwig  wrote:
> And now with a proper changelog, and the accidentall dropped call to
> flush_tlb_kernel_range reinstated:
>
> ---
> From f720cc324498ab5e7931c7ccb1653bd9b8cddc63 Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig 
> Date: Sat, 15 Oct 2016 18:39:44 +0200
> Subject: mm: rewrite __purge_vmap_area_lazy
>
> Remove the purge lock, there was nothing left to be protected:
>
>   - purge_fragmented_blocks seems to has it's own local protection.
>   - all handling of of valist is implicity protected by the atomic
> list deletion in llist_del_all, which also avoids multiple callers
> stomping on each other here.
>   - the manipulation of vmap_lazy_nr already is atomic
>   - flush_tlb_kernel_range does not require any synchronization
>   - the calls to __free_vmap_area are sychronized by vmap_area_lock
>   - *start and *end always point to on-stack variables, never mind
> that the caller never looks at the updated values anyway.
>
> Once that is done we can remove the sync argument by moving the calls
> to purge_fragmented_blocks_allcpus into the callers that need it,
> and the forced flush_tlb_kernel_range call even if no entries were
> found into the one caller that cares, and we can also pass start and
> end by reference.

Your patch changes the behavior of the original code I think. With the
patch, for the case where you have 2 concurrent tasks executing
alloc_vmap_area function, say both hit the overflow label and enter
the __purge_vmap_area_lazy at the same time. The first task empties
the purge list and sets nr to the total number of pages of all the
vmap areas in the list. Say the first task has just emptied the list
but hasn't started freeing the vmap areas and is preempted at this
point. Now the second task runs and since the purge list is empty, the
second task doesn't have anything to do and immediately returns to
alloc_vmap_area. Once it returns, it sets purged to 1 in
alloc_vmap_area and retries. Say it hits overflow label again in the
retry path. Now because purged was set to 1, it goes to err_free.
Without your patch, it would have waited on the spin_lock (sync = 1)
instead of just erroring out, so your patch does change the behavior
of the original code by not using the purge_lock. I realize my patch
also changes the behavior, but in mine I think we can make it behave
like the original code by spinning until purging=0 (if sync = 1)
because I still have the purging variable..

Some more comments below:

> Signed-off-by: Christoph Hellwig 
> ---
>  mm/vmalloc.c | 84 
> +++-
>  1 file changed, 26 insertions(+), 58 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index f2481cb..c3ca992 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -613,82 +613,44 @@ void set_iounmap_nonlazy(void)
> atomic_set(_lazy_nr, lazy_max_pages()+1);
>  }
>
> -/*
> - * Purges all lazily-freed vmap areas.
> - *
> - * If sync is 0 then don't purge if there is already a purge in progress.
> - * If force_flush is 1, then flush kernel TLBs between *start and *end even
> - * if we found no lazy vmap areas to unmap (callers can use this to optimise
> - * their own TLB flushing).
> - * Returns with *start = min(*start, lowest purged address)
> - *  *end = max(*end, highest purged address)
> - */
> -static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
> -   int sync, int force_flush)
> +static bool __purge_vmap_area_lazy(unsigned long start, unsigned long end)
>  {
> -   static DEFINE_SPINLOCK(purge_lock);
> struct llist_node *valist;
> struct vmap_area *va;
> struct vmap_area *n_va;
> int nr = 0;
>
> -   /*
> -* If sync is 0 but force_flush is 1, we'll go sync anyway but callers
> -* should not expect such behaviour. This just simplifies locking for
> -* the case that isn't actually used at the moment anyway.
> -*/
> -   if (!sync && !force_flush) {
> -   if (!spin_trylock(_lock))
> -   return;
> -   } else
> -   spin_lock(_lock);
> -
> -   if (sync)
> -   purge_fragmented_blocks_allcpus();
> -
> valist = llist_del_all(_purge_list);
> llist_for_each_entry(va, valist, purge_list) {
> -   if (va->va_start < *start)
> -   *start = va->va_start;
> -   if (va->va_end > *end)
> -   *end = va->va_end;
> +   if (va->va_start < start)
> +   start = va->va_start;
> +   if (va->va_end > end)
> +   end = va->va_end;
> nr += (va->va_end - va->va_start) >> PAGE_SHIFT;
> }
>
> -   if (nr)
> -   atomic_sub(nr, _lazy_nr);
> -
> -   if (nr || 

Re: [PATCH v3] mm: vmalloc: Replace purge_lock spinlock with atomic refcount

[Joel Fernandes]

Hi Christoph,

On Sat, Oct 15, 2016 at 9:54 AM, Christoph Hellwig  wrote:
> And now with a proper changelog, and the accidentall dropped call to
> flush_tlb_kernel_range reinstated:
>
> ---
> From f720cc324498ab5e7931c7ccb1653bd9b8cddc63 Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig 
> Date: Sat, 15 Oct 2016 18:39:44 +0200
> Subject: mm: rewrite __purge_vmap_area_lazy
>
> Remove the purge lock, there was nothing left to be protected:
>
>   - purge_fragmented_blocks seems to has it's own local protection.
>   - all handling of of valist is implicity protected by the atomic
> list deletion in llist_del_all, which also avoids multiple callers
> stomping on each other here.
>   - the manipulation of vmap_lazy_nr already is atomic
>   - flush_tlb_kernel_range does not require any synchronization
>   - the calls to __free_vmap_area are sychronized by vmap_area_lock
>   - *start and *end always point to on-stack variables, never mind
> that the caller never looks at the updated values anyway.
>
> Once that is done we can remove the sync argument by moving the calls
> to purge_fragmented_blocks_allcpus into the callers that need it,
> and the forced flush_tlb_kernel_range call even if no entries were
> found into the one caller that cares, and we can also pass start and
> end by reference.

Your patch changes the behavior of the original code I think. With the
patch, for the case where you have 2 concurrent tasks executing
alloc_vmap_area function, say both hit the overflow label and enter
the __purge_vmap_area_lazy at the same time. The first task empties
the purge list and sets nr to the total number of pages of all the
vmap areas in the list. Say the first task has just emptied the list
but hasn't started freeing the vmap areas and is preempted at this
point. Now the second task runs and since the purge list is empty, the
second task doesn't have anything to do and immediately returns to
alloc_vmap_area. Once it returns, it sets purged to 1 in
alloc_vmap_area and retries. Say it hits overflow label again in the
retry path. Now because purged was set to 1, it goes to err_free.
Without your patch, it would have waited on the spin_lock (sync = 1)
instead of just erroring out, so your patch does change the behavior
of the original code by not using the purge_lock. I realize my patch
also changes the behavior, but in mine I think we can make it behave
like the original code by spinning until purging=0 (if sync = 1)
because I still have the purging variable..

Some more comments below:

> Signed-off-by: Christoph Hellwig 
> ---
>  mm/vmalloc.c | 84 
> +++-
>  1 file changed, 26 insertions(+), 58 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index f2481cb..c3ca992 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -613,82 +613,44 @@ void set_iounmap_nonlazy(void)
> atomic_set(_lazy_nr, lazy_max_pages()+1);
>  }
>
> -/*
> - * Purges all lazily-freed vmap areas.
> - *
> - * If sync is 0 then don't purge if there is already a purge in progress.
> - * If force_flush is 1, then flush kernel TLBs between *start and *end even
> - * if we found no lazy vmap areas to unmap (callers can use this to optimise
> - * their own TLB flushing).
> - * Returns with *start = min(*start, lowest purged address)
> - *  *end = max(*end, highest purged address)
> - */
> -static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
> -   int sync, int force_flush)
> +static bool __purge_vmap_area_lazy(unsigned long start, unsigned long end)
>  {
> -   static DEFINE_SPINLOCK(purge_lock);
> struct llist_node *valist;
> struct vmap_area *va;
> struct vmap_area *n_va;
> int nr = 0;
>
> -   /*
> -* If sync is 0 but force_flush is 1, we'll go sync anyway but callers
> -* should not expect such behaviour. This just simplifies locking for
> -* the case that isn't actually used at the moment anyway.
> -*/
> -   if (!sync && !force_flush) {
> -   if (!spin_trylock(_lock))
> -   return;
> -   } else
> -   spin_lock(_lock);
> -
> -   if (sync)
> -   purge_fragmented_blocks_allcpus();
> -
> valist = llist_del_all(_purge_list);
> llist_for_each_entry(va, valist, purge_list) {
> -   if (va->va_start < *start)
> -   *start = va->va_start;
> -   if (va->va_end > *end)
> -   *end = va->va_end;
> +   if (va->va_start < start)
> +   start = va->va_start;
> +   if (va->va_end > end)
> +   end = va->va_end;
> nr += (va->va_end - va->va_start) >> PAGE_SHIFT;
> }
>
> -   if (nr)
> -   atomic_sub(nr, _lazy_nr);
> -
> -   if (nr || force_flush)
> -   

drivers/pci/hotplug/ibmphp_ebda.c:409:1: warning: the frame size of 1108 bytes is larger than 1024 bytes

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1001354ca34179f3db924eb66672442a173147dc
commit: 0766f788eb727e2e330d55d30545db65bcf2623f latent_entropy: Mark functions 
with __latent_entropy
date:   5 days ago
config: i386-randconfig-c0-10160635 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout 0766f788eb727e2e330d55d30545db65bcf2623f
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/pci/hotplug/ibmphp_ebda.c: In function 'ibmphp_access_ebda':
>> drivers/pci/hotplug/ibmphp_ebda.c:409:1: warning: the frame size of 1108 
>> bytes is larger than 1024 bytes [-Wframe-larger-than=]
}
^

vim +409 drivers/pci/hotplug/ibmphp_ebda.c

^1da177e Linus Torvalds 2005-04-16  393 rc = 
ebda_rio_table();
^1da177e Linus Torvalds 2005-04-16  394 if (rc)
^1da177e Linus Torvalds 2005-04-16  395 goto 
out;
^1da177e Linus Torvalds 2005-04-16  396 }
^1da177e Linus Torvalds 2005-04-16  397 }
^1da177e Linus Torvalds 2005-04-16  398 rc = ebda_rsrc_controller();
^1da177e Linus Torvalds 2005-04-16  399 if (rc)
^1da177e Linus Torvalds 2005-04-16  400 goto out;
^1da177e Linus Torvalds 2005-04-16  401  
^1da177e Linus Torvalds 2005-04-16  402 rc = ebda_rsrc_rsrc();
^1da177e Linus Torvalds 2005-04-16  403 goto out;
^1da177e Linus Torvalds 2005-04-16  404  error_nodev:
^1da177e Linus Torvalds 2005-04-16  405 rc = -ENODEV;
^1da177e Linus Torvalds 2005-04-16  406  out:
^1da177e Linus Torvalds 2005-04-16  407 iounmap(io_mem);
^1da177e Linus Torvalds 2005-04-16  408 return rc;
^1da177e Linus Torvalds 2005-04-16 @409  }
^1da177e Linus Torvalds 2005-04-16  410  
^1da177e Linus Torvalds 2005-04-16  411  /*
^1da177e Linus Torvalds 2005-04-16  412   * map info of scalability details and 
rio details from physical address
^1da177e Linus Torvalds 2005-04-16  413   */
^1da177e Linus Torvalds 2005-04-16  414  static int __init ebda_rio_table(void)
^1da177e Linus Torvalds 2005-04-16  415  {
^1da177e Linus Torvalds 2005-04-16  416 u16 offset;
^1da177e Linus Torvalds 2005-04-16  417 u8 i;

:: The code at line 409 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2

:: TO: Linus Torvalds 
:: CC: Linus Torvalds 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

drivers/pci/hotplug/ibmphp_ebda.c:409:1: warning: the frame size of 1108 bytes is larger than 1024 bytes

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1001354ca34179f3db924eb66672442a173147dc
commit: 0766f788eb727e2e330d55d30545db65bcf2623f latent_entropy: Mark functions 
with __latent_entropy
date:   5 days ago
config: i386-randconfig-c0-10160635 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout 0766f788eb727e2e330d55d30545db65bcf2623f
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/pci/hotplug/ibmphp_ebda.c: In function 'ibmphp_access_ebda':
>> drivers/pci/hotplug/ibmphp_ebda.c:409:1: warning: the frame size of 1108 
>> bytes is larger than 1024 bytes [-Wframe-larger-than=]
}
^

vim +409 drivers/pci/hotplug/ibmphp_ebda.c

^1da177e Linus Torvalds 2005-04-16  393 rc = 
ebda_rio_table();
^1da177e Linus Torvalds 2005-04-16  394 if (rc)
^1da177e Linus Torvalds 2005-04-16  395 goto 
out;
^1da177e Linus Torvalds 2005-04-16  396 }
^1da177e Linus Torvalds 2005-04-16  397 }
^1da177e Linus Torvalds 2005-04-16  398 rc = ebda_rsrc_controller();
^1da177e Linus Torvalds 2005-04-16  399 if (rc)
^1da177e Linus Torvalds 2005-04-16  400 goto out;
^1da177e Linus Torvalds 2005-04-16  401  
^1da177e Linus Torvalds 2005-04-16  402 rc = ebda_rsrc_rsrc();
^1da177e Linus Torvalds 2005-04-16  403 goto out;
^1da177e Linus Torvalds 2005-04-16  404  error_nodev:
^1da177e Linus Torvalds 2005-04-16  405 rc = -ENODEV;
^1da177e Linus Torvalds 2005-04-16  406  out:
^1da177e Linus Torvalds 2005-04-16  407 iounmap(io_mem);
^1da177e Linus Torvalds 2005-04-16  408 return rc;
^1da177e Linus Torvalds 2005-04-16 @409  }
^1da177e Linus Torvalds 2005-04-16  410  
^1da177e Linus Torvalds 2005-04-16  411  /*
^1da177e Linus Torvalds 2005-04-16  412   * map info of scalability details and 
rio details from physical address
^1da177e Linus Torvalds 2005-04-16  413   */
^1da177e Linus Torvalds 2005-04-16  414  static int __init ebda_rio_table(void)
^1da177e Linus Torvalds 2005-04-16  415  {
^1da177e Linus Torvalds 2005-04-16  416 u16 offset;
^1da177e Linus Torvalds 2005-04-16  417 u8 i;

:: The code at line 409 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2

:: TO: Linus Torvalds 
:: CC: Linus Torvalds 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH] ipvlan: constify l3mdev_ops structure

[David Miller]

From: Julia Lawall 
Date: Sat, 15 Oct 2016 17:40:30 +0200

> This l3mdev_ops structure is only stored in the l3mdev_ops field of a
> net_device structure.  This field is declared const, so the l3mdev_ops
> structure can be declared as const also.  Additionally drop the
> __read_mostly annotation.
> 
> The semantic patch that adds const is as follows:
> (http://coccinelle.lip6.fr/)
 ...
> Signed-off-by: Julia Lawall 

Applied, thanks.

Re: [PATCH] ipvlan: constify l3mdev_ops structure

[David Miller]

From: Julia Lawall 
Date: Sat, 15 Oct 2016 17:40:30 +0200

> This l3mdev_ops structure is only stored in the l3mdev_ops field of a
> net_device structure.  This field is declared const, so the l3mdev_ops
> structure can be declared as const also.  Additionally drop the
> __read_mostly annotation.
> 
> The semantic patch that adds const is as follows:
> (http://coccinelle.lip6.fr/)
 ...
> Signed-off-by: Julia Lawall 

Applied, thanks.

Re: [PATCH 0/2] net: Fix compiler warnings

[David Miller]

From: Tushar Dave 
Date: Fri, 14 Oct 2016 17:06:04 -0700

> Recently, ATU (iommu) changes are submitted to linux-sparc that
> enables 64bit DMA on SPARC. However, this change also makes
> 'incompatible pointer type' compiler warnings inevitable on sunqe
> and sunbmac driver.
> 
> The two patches in series fix compiler warnings.

Only the sparc tree has this build problem, so these patches
really ought to be submitted for and applied there.

Thanks.

Re: [PATCH 0/2] net: Fix compiler warnings

[David Miller]

From: Tushar Dave 
Date: Fri, 14 Oct 2016 17:06:04 -0700

> Recently, ATU (iommu) changes are submitted to linux-sparc that
> enables 64bit DMA on SPARC. However, this change also makes
> 'incompatible pointer type' compiler warnings inevitable on sunqe
> and sunbmac driver.
> 
> The two patches in series fix compiler warnings.

Only the sparc tree has this build problem, so these patches
really ought to be submitted for and applied there.

Thanks.

Re: [PATCH v2] vmxnet3: avoid assumption about invalid dma_pa in vmxnet3_set_mc()

[David Miller]

From: Alexey Khoroshilov 
Date: Sat, 15 Oct 2016 00:01:20 +0300

> vmxnet3_set_mc() checks new_table_pa returned by dma_map_single()
> with dma_mapping_error(), but even there it assumes zero is invalid pa
> (it assumes dma_mapping_error(...,0) returns true if new_table is NULL).
> 
> The patch adds an explicit variable to track status of new_table_pa.
> 
> Found by Linux Driver Verification project (linuxtesting.org).
> 
> v2: use "bool" and "true"/"false" for boolean variables.
> Signed-off-by: Alexey Khoroshilov 

Applied.

Re: [PATCH v2] vmxnet3: avoid assumption about invalid dma_pa in vmxnet3_set_mc()

[David Miller]

From: Alexey Khoroshilov 
Date: Sat, 15 Oct 2016 00:01:20 +0300

> vmxnet3_set_mc() checks new_table_pa returned by dma_map_single()
> with dma_mapping_error(), but even there it assumes zero is invalid pa
> (it assumes dma_mapping_error(...,0) returns true if new_table is NULL).
> 
> The patch adds an explicit variable to track status of new_table_pa.
> 
> Found by Linux Driver Verification project (linuxtesting.org).
> 
> v2: use "bool" and "true"/"false" for boolean variables.
> Signed-off-by: Alexey Khoroshilov 

Applied.

[git pull] tree-wide switch to linux/uaccess.h

[Al Viro]

Now everything can be switched from asm/uaccess.h to linux/uaccess.h
*and* the merges of this window have settled, we can do the actual switchover.
The thing is automatically generated (by
PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*'
sed -i -e "s!$PATT!#include !" \
`git grep -l "$PATT"|grep -v ^include/linux/uaccess.h`
ran over 4.9-rc1).  That sucker is a pre-req for uaccess unification work -
until it went in, we had to duplicate everything in each asm/uaccess.h
instance.  OTOH, at any earlier point it would cause pointless conflicts
for this merge window.  Please, apply.

Folks, please do _not_ add any asm/uaccess.h uses; with that thing
applied, only include/linux/uaccess.h has any business having those.

The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:

  Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus

for you to fetch changes up to d9c401c48bfac1cd1d1ed70101ce570691a460f8:

  [PATCH] tree-wide switch to linux/uaccess.h (2016-10-15 16:23:56 -0400)


Al Viro (1):
  tree-wide switch to linux/uaccess.h

 arch/alpha/boot/misc.c| 2 +-
 arch/alpha/kernel/irq.c   | 2 +-
 arch/alpha/kernel/osf_sys.c   | 2 +-
 arch/alpha/kernel/process.c   | 2 +-
 arch/alpha/kernel/ptrace.c| 2 +-
 arch/alpha/kernel/setup.c | 2 +-
 arch/alpha/kernel/signal.c| 2 +-
 arch/alpha/kernel/srm_env.c   | 2 +-
 arch/alpha/kernel/srmcons.c   | 2 +-
 arch/alpha/kernel/time.c  | 2 +-
 arch/alpha/kernel/traps.c | 2 +-
 arch/alpha/lib/csum_partial_copy.c| 2 +-
 arch/alpha/math-emu/math.c| 2 +-
 arch/alpha/mm/init.c  | 2 +-
 arch/arm/common/bL_switcher_dummy_if.c| 2 +-
 arch/arm/kernel/swp_emulate.c | 2 +-
 arch/arm/kvm/arm.c| 2 +-
 arch/arm/kvm/guest.c  | 2 +-
 arch/arm/mach-iop13xx/irq.c   | 2 +-
 arch/arm/mach-ixp4xx/common.c | 2 +-
 arch/arm/mach-rpc/dma.c   | 2 +-
 arch/arm/plat-iop/time.c  | 2 +-
 arch/arm64/include/asm/word-at-a-time.h   | 2 +-
 arch/arm64/kernel/armv8_deprecated.c  | 2 +-
 arch/arm64/kernel/probes/kprobes.c| 2 +-
 arch/arm64/kernel/signal32.c  | 2 +-
 arch/arm64/kvm/guest.c| 2 +-
 arch/avr32/kernel/avr32_ksyms.c   | 2 +-
 arch/avr32/kernel/ptrace.c| 2 +-
 arch/avr32/kernel/signal.c| 2 +-
 arch/avr32/mm/cache.c | 2 +-
 arch/blackfin/kernel/bfin_dma.c   | 2 +-
 arch/blackfin/kernel/kgdb_test.c  | 2 +-
 arch/blackfin/kernel/module.c | 2 +-
 arch/c6x/mm/init.c| 2 +-
 arch/cris/arch-v10/drivers/eeprom.c   | 2 +-
 arch/cris/arch-v10/drivers/sync_serial.c  | 2 +-
 arch/cris/arch-v10/kernel/ptrace.c| 2 +-
 arch/cris/arch-v10/kernel/signal.c| 2 +-
 arch/cris/arch-v10/kernel/traps.c | 2 +-
 arch/cris/arch-v10/lib/usercopy.c | 2 +-
 arch/cris/arch-v10/mm/fault.c | 2 +-
 arch/cris/arch-v32/drivers/cryptocop.c| 2 +-
 arch/cris/arch-v32/kernel/ptrace.c| 2 +-
 arch/cris/arch-v32/kernel/signal.c| 2 +-
 arch/cris/arch-v32/kernel/traps.c | 2 +-
 arch/cris/arch-v32/lib/usercopy.c | 2 +-
 arch/cris/kernel/crisksyms.c  | 2 +-
 arch/cris/kernel/process.c| 2 +-
 arch/cris/kernel/profile.c| 2 +-
 arch/cris/kernel/ptrace.c | 2 +-
 arch/cris/kernel/sys_cris.c   | 2 +-
 arch/cris/kernel/traps.c  | 2 +-
 arch/frv/include/asm/futex.h  | 2 +-
 arch/frv/kernel/irq.c | 2 +-
 arch/frv/kernel/pm-mb93093.c  | 2 +-
 arch/frv/kernel/pm.c  | 2 +-
 arch/frv/kernel/process.c | 2 +-
 arch/frv/kernel/ptrace.c  | 2 +-
 arch/frv/kernel/signal.c  | 2 +-
 

[git pull] tree-wide switch to linux/uaccess.h

[Al Viro]

Now everything can be switched from asm/uaccess.h to linux/uaccess.h
*and* the merges of this window have settled, we can do the actual switchover.
The thing is automatically generated (by
PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*'
sed -i -e "s!$PATT!#include !" \
`git grep -l "$PATT"|grep -v ^include/linux/uaccess.h`
ran over 4.9-rc1).  That sucker is a pre-req for uaccess unification work -
until it went in, we had to duplicate everything in each asm/uaccess.h
instance.  OTOH, at any earlier point it would cause pointless conflicts
for this merge window.  Please, apply.

Folks, please do _not_ add any asm/uaccess.h uses; with that thing
applied, only include/linux/uaccess.h has any business having those.

The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:

  Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus

for you to fetch changes up to d9c401c48bfac1cd1d1ed70101ce570691a460f8:

  [PATCH] tree-wide switch to linux/uaccess.h (2016-10-15 16:23:56 -0400)


Al Viro (1):
  tree-wide switch to linux/uaccess.h

 arch/alpha/boot/misc.c| 2 +-
 arch/alpha/kernel/irq.c   | 2 +-
 arch/alpha/kernel/osf_sys.c   | 2 +-
 arch/alpha/kernel/process.c   | 2 +-
 arch/alpha/kernel/ptrace.c| 2 +-
 arch/alpha/kernel/setup.c | 2 +-
 arch/alpha/kernel/signal.c| 2 +-
 arch/alpha/kernel/srm_env.c   | 2 +-
 arch/alpha/kernel/srmcons.c   | 2 +-
 arch/alpha/kernel/time.c  | 2 +-
 arch/alpha/kernel/traps.c | 2 +-
 arch/alpha/lib/csum_partial_copy.c| 2 +-
 arch/alpha/math-emu/math.c| 2 +-
 arch/alpha/mm/init.c  | 2 +-
 arch/arm/common/bL_switcher_dummy_if.c| 2 +-
 arch/arm/kernel/swp_emulate.c | 2 +-
 arch/arm/kvm/arm.c| 2 +-
 arch/arm/kvm/guest.c  | 2 +-
 arch/arm/mach-iop13xx/irq.c   | 2 +-
 arch/arm/mach-ixp4xx/common.c | 2 +-
 arch/arm/mach-rpc/dma.c   | 2 +-
 arch/arm/plat-iop/time.c  | 2 +-
 arch/arm64/include/asm/word-at-a-time.h   | 2 +-
 arch/arm64/kernel/armv8_deprecated.c  | 2 +-
 arch/arm64/kernel/probes/kprobes.c| 2 +-
 arch/arm64/kernel/signal32.c  | 2 +-
 arch/arm64/kvm/guest.c| 2 +-
 arch/avr32/kernel/avr32_ksyms.c   | 2 +-
 arch/avr32/kernel/ptrace.c| 2 +-
 arch/avr32/kernel/signal.c| 2 +-
 arch/avr32/mm/cache.c | 2 +-
 arch/blackfin/kernel/bfin_dma.c   | 2 +-
 arch/blackfin/kernel/kgdb_test.c  | 2 +-
 arch/blackfin/kernel/module.c | 2 +-
 arch/c6x/mm/init.c| 2 +-
 arch/cris/arch-v10/drivers/eeprom.c   | 2 +-
 arch/cris/arch-v10/drivers/sync_serial.c  | 2 +-
 arch/cris/arch-v10/kernel/ptrace.c| 2 +-
 arch/cris/arch-v10/kernel/signal.c| 2 +-
 arch/cris/arch-v10/kernel/traps.c | 2 +-
 arch/cris/arch-v10/lib/usercopy.c | 2 +-
 arch/cris/arch-v10/mm/fault.c | 2 +-
 arch/cris/arch-v32/drivers/cryptocop.c| 2 +-
 arch/cris/arch-v32/kernel/ptrace.c| 2 +-
 arch/cris/arch-v32/kernel/signal.c| 2 +-
 arch/cris/arch-v32/kernel/traps.c | 2 +-
 arch/cris/arch-v32/lib/usercopy.c | 2 +-
 arch/cris/kernel/crisksyms.c  | 2 +-
 arch/cris/kernel/process.c| 2 +-
 arch/cris/kernel/profile.c| 2 +-
 arch/cris/kernel/ptrace.c | 2 +-
 arch/cris/kernel/sys_cris.c   | 2 +-
 arch/cris/kernel/traps.c  | 2 +-
 arch/frv/include/asm/futex.h  | 2 +-
 arch/frv/kernel/irq.c | 2 +-
 arch/frv/kernel/pm-mb93093.c  | 2 +-
 arch/frv/kernel/pm.c  | 2 +-
 arch/frv/kernel/process.c | 2 +-
 arch/frv/kernel/ptrace.c  | 2 +-
 arch/frv/kernel/signal.c  | 2 +-
 

WARNING: SOMEONE RECEIVING THIS HAS BEEN HACKED (was: Re: [PATCH v2 0/4] PXA cpufreq conversion to clock API)

[Russell King - ARM Linux]

Guys,

Looks like gmail's been hacked (or something).  Within 50 minutes of
sending the reply below, I've received at least 10 replies with the
following headers:

In-Reply-To: <20161015203421.gg1...@n2100.armlinux.org.uk>
References: <1476561450-28407-1-git-send-email-robert.jarz...@free.fr> 
<20161015203421.gg1...@n2100.armlinux.org.uk>

from various gmail.com addresses, each and every one containing some kind
of spam.  Each reply is from a victim of spam - the replies themselves are
people replying to the spam that they have received.  The quoted message
is allegedly from me, and even includes the line:

 "On 15 Oct 2016, at 21:34, Russell King - ARM Linux 
 wrote:"

which is the time I sent the original message.

It's either that gmail has been hacked, or one of the mailing lists in
the recipients of this message has been hacked.

On Sat, Oct 15, 2016 at 09:34:21PM +0100, Russell King - ARM Linux wrote:
> On Sat, Oct 15, 2016 at 09:57:26PM +0200, Robert Jarzmik wrote:
> > Hi,
> > 
> > This serie is a preparation to shift the cpufreq of pxa2xx platforms to 
> > clocks
> > API.
> > 
> > The first 3 patches are review and merge material :
> >  - patch 1/4 for Viresh and Rafael
> >  - patches 2/4 and 3/4 for me
> > 
> > The 4th on is for review but not merge, as the clock changes must be fully
> > reviewed and go in first as a prequisite
> 
> Have you tested whether this patch set results in functional cpufreq
> support - looking at drivers/clk/pxa, the CPU clock is read-only -
> it can't be used to change the clock rate.  So, I very much doubt this
> has been functionally tested.
> 
> Don't forget that changing the CPU clock rate needs other changes
> (like the memory clock rate) so all that code you're removing in
> patch 4 (which does the actual clock change) needs to go somewhere.
> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

WARNING: SOMEONE RECEIVING THIS HAS BEEN HACKED (was: Re: [PATCH v2 0/4] PXA cpufreq conversion to clock API)

[Russell King - ARM Linux]

Guys,

Looks like gmail's been hacked (or something).  Within 50 minutes of
sending the reply below, I've received at least 10 replies with the
following headers:

In-Reply-To: <20161015203421.gg1...@n2100.armlinux.org.uk>
References: <1476561450-28407-1-git-send-email-robert.jarz...@free.fr> 
<20161015203421.gg1...@n2100.armlinux.org.uk>

from various gmail.com addresses, each and every one containing some kind
of spam.  Each reply is from a victim of spam - the replies themselves are
people replying to the spam that they have received.  The quoted message
is allegedly from me, and even includes the line:

 "On 15 Oct 2016, at 21:34, Russell King - ARM Linux 
 wrote:"

which is the time I sent the original message.

It's either that gmail has been hacked, or one of the mailing lists in
the recipients of this message has been hacked.

On Sat, Oct 15, 2016 at 09:34:21PM +0100, Russell King - ARM Linux wrote:
> On Sat, Oct 15, 2016 at 09:57:26PM +0200, Robert Jarzmik wrote:
> > Hi,
> > 
> > This serie is a preparation to shift the cpufreq of pxa2xx platforms to 
> > clocks
> > API.
> > 
> > The first 3 patches are review and merge material :
> >  - patch 1/4 for Viresh and Rafael
> >  - patches 2/4 and 3/4 for me
> > 
> > The 4th on is for review but not merge, as the clock changes must be fully
> > reviewed and go in first as a prequisite
> 
> Have you tested whether this patch set results in functional cpufreq
> support - looking at drivers/clk/pxa, the CPU clock is read-only -
> it can't be used to change the clock rate.  So, I very much doubt this
> has been functionally tested.
> 
> Don't forget that changing the CPU clock rate needs other changes
> (like the memory clock rate) so all that code you're removing in
> patch 4 (which does the actual clock change) needs to go somewhere.
> 
> -- 
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

ca54678efb: BUG: kernel hang in boot stage

[kernel test robot]

FYI, we noticed the following commit:

https://github.com/0day-ci/linux 
Grzegorz-Andrejczuk/Enabling-Ring-3-MONITOR-MWAIT-feature-for-Knights-Landing/20161012-202414
commit ca54678efb1a9e8b0ff83fb488175103d6616a81 ("Add R3MWAIT to CPU features")

in testcase: boot

on test machine: qemu-system-i386 -enable-kvm -cpu Haswell,+smep,+smap -m 360M

caused below changes:


+-+++
| | d19ea2b4b4 | ca54678efb |
+-+++
| boot_successes  | 4  | 0  |
| boot_failures   | 2  | 30 |
| BUG:kernel_reboot-without-warning_in_test_stage | 2  ||
| BUG:kernel_hang_in_boot_stage   | 0  | 30 |
+-+++



Booting the kernel.

Elapsed time: 510
BUG: kernel hang in boot stage
Linux version 4.8.0-rc8-4-gca54678 #1
Command line: ip=vm-vp-quantal-i386-24::dhcp root=/dev/ram0 user=lkp 
job=/lkp/scheduled/vm-vp-quantal-i386-24/boot-1-quantal-core-i386.cgz-ca54678efb1a9e8b0ff83fb488175103d6616a81-20161016-56681-1pl9mhj-0.yaml
 ARCH=i386 kconfig=i386-randconfig-x0-10131534+CONFIG_DEBUG_INFO_REDUCED 
branch=linux-devel/devel-spot-201610131309 
commit=ca54678efb1a9e8b0ff83fb488175103d6616a81 
BOOT_IMAGE=/pkg/linux/i386-randconfig-x0-10131534+CONFIG_DEBUG_INFO_REDUCED/gcc-6/ca54678efb1a9e8b0ff83fb488175103d6616a81/vmlinuz-4.8.0-rc8-4-gca54678
 max_uptime=600 
RESULT_ROOT=/result/boot/1/vm-vp-quantal-i386/quantal-core-i386.cgz/i386-randconfig-x0-10131534+CONFIG_DEBUG_INFO_REDUCED/gcc-6/ca54678efb1a9e8b0ff83fb488175103d6616a81/0
 LKP_SERVER=inn debug apic=debug sysrq_always_enabled 
rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 printk.devkmsg=on panic=-1 
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 
prompt_ramdisk=0 systemd.log_level=err ignore_loglevel earlyprintk=ttyS0,115200 
console=ttyS0,115200 console=tty0 vga=normal rw drbd.minor_count=8






Thanks,
Kernel Test Robot
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.8.0-rc8 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
CONFIG_KERNEL_LZMA=y
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
CONFIG_IRQ_TIME_ACCOUNTING=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem

ca54678efb: BUG: kernel hang in boot stage

[kernel test robot]

FYI, we noticed the following commit:

https://github.com/0day-ci/linux 
Grzegorz-Andrejczuk/Enabling-Ring-3-MONITOR-MWAIT-feature-for-Knights-Landing/20161012-202414
commit ca54678efb1a9e8b0ff83fb488175103d6616a81 ("Add R3MWAIT to CPU features")

in testcase: boot

on test machine: qemu-system-i386 -enable-kvm -cpu Haswell,+smep,+smap -m 360M

caused below changes:


+-+++
| | d19ea2b4b4 | ca54678efb |
+-+++
| boot_successes  | 4  | 0  |
| boot_failures   | 2  | 30 |
| BUG:kernel_reboot-without-warning_in_test_stage | 2  ||
| BUG:kernel_hang_in_boot_stage   | 0  | 30 |
+-+++



Booting the kernel.

Elapsed time: 510
BUG: kernel hang in boot stage
Linux version 4.8.0-rc8-4-gca54678 #1
Command line: ip=vm-vp-quantal-i386-24::dhcp root=/dev/ram0 user=lkp 
job=/lkp/scheduled/vm-vp-quantal-i386-24/boot-1-quantal-core-i386.cgz-ca54678efb1a9e8b0ff83fb488175103d6616a81-20161016-56681-1pl9mhj-0.yaml
 ARCH=i386 kconfig=i386-randconfig-x0-10131534+CONFIG_DEBUG_INFO_REDUCED 
branch=linux-devel/devel-spot-201610131309 
commit=ca54678efb1a9e8b0ff83fb488175103d6616a81 
BOOT_IMAGE=/pkg/linux/i386-randconfig-x0-10131534+CONFIG_DEBUG_INFO_REDUCED/gcc-6/ca54678efb1a9e8b0ff83fb488175103d6616a81/vmlinuz-4.8.0-rc8-4-gca54678
 max_uptime=600 
RESULT_ROOT=/result/boot/1/vm-vp-quantal-i386/quantal-core-i386.cgz/i386-randconfig-x0-10131534+CONFIG_DEBUG_INFO_REDUCED/gcc-6/ca54678efb1a9e8b0ff83fb488175103d6616a81/0
 LKP_SERVER=inn debug apic=debug sysrq_always_enabled 
rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 printk.devkmsg=on panic=-1 
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 
prompt_ramdisk=0 systemd.log_level=err ignore_loglevel earlyprintk=ttyS0,115200 
console=ttyS0,115200 console=tty0 vga=normal rw drbd.minor_count=8






Thanks,
Kernel Test Robot
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.8.0-rc8 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEBUG_RODATA=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
CONFIG_KERNEL_LZMA=y
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
CONFIG_IRQ_TIME_ACCOUNTING=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem

arch/mips/kernel/mips-cpc.c:47: undefined reference to `mips_cpc_default_phys_base'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1001354ca34179f3db924eb66672442a173147dc
commit: eed0eabd12ef061821cbfa20d903476e07645320 MIPS: generic: Introduce 
generic DT-based board support
date:   9 days ago
config: mips-generic_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout eed0eabd12ef061821cbfa20d903476e07645320
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

   arch/mips/built-in.o: In function `mips_cpc_phys_base':
>> arch/mips/kernel/mips-cpc.c:47: undefined reference to 
>> `mips_cpc_default_phys_base'

vim +47 arch/mips/kernel/mips-cpc.c

8dedde6b2 Bjorn Helgaas   2015-07-12  31  static phys_addr_t 
mips_cpc_phys_base(void)
9c38cf447 Paul Burton 2014-01-15  32  {
391057d91 Markos Chandras 2015-07-09  33unsigned long cpc_base;
9c38cf447 Paul Burton 2014-01-15  34  
9c38cf447 Paul Burton 2014-01-15  35if (!mips_cm_present())
9c38cf447 Paul Burton 2014-01-15  36return 0;
9c38cf447 Paul Burton 2014-01-15  37  
9c38cf447 Paul Burton 2014-01-15  38if (!(read_gcr_cpc_status() & 
CM_GCR_CPC_STATUS_EX_MSK))
9c38cf447 Paul Burton 2014-01-15  39return 0;
9c38cf447 Paul Burton 2014-01-15  40  
9c38cf447 Paul Burton 2014-01-15  41/* If the CPC is already 
enabled, leave it so */
9c38cf447 Paul Burton 2014-01-15  42cpc_base = read_gcr_cpc_base();
9c38cf447 Paul Burton 2014-01-15  43if (cpc_base & 
CM_GCR_CPC_BASE_CPCEN_MSK)
9c38cf447 Paul Burton 2014-01-15  44return cpc_base & 
CM_GCR_CPC_BASE_CPCBASE_MSK;
9c38cf447 Paul Burton 2014-01-15  45  
9c38cf447 Paul Burton 2014-01-15  46/* Otherwise, give it the 
default address & enable it */
9c38cf447 Paul Burton 2014-01-15 @47cpc_base = 
mips_cpc_default_phys_base();
9c38cf447 Paul Burton 2014-01-15  48write_gcr_cpc_base(cpc_base | 
CM_GCR_CPC_BASE_CPCEN_MSK);
9c38cf447 Paul Burton 2014-01-15  49return cpc_base;
9c38cf447 Paul Burton 2014-01-15  50  }
9c38cf447 Paul Burton 2014-01-15  51  
9c38cf447 Paul Burton 2014-01-15  52  int mips_cpc_probe(void)
9c38cf447 Paul Burton 2014-01-15  53  {
15d45cce3 Ralf Baechle2014-11-22  54phys_addr_t addr;
6b89d22e7 Matt Redfearn   2016-09-07  55unsigned int cpu;

:: The code at line 47 was first introduced by commit
:: 9c38cf44712af95a5ec3937d63faaea9b43eab9a MIPS: Add CPC probe, access 
functions

:: TO: Paul Burton 
:: CC: Ralf Baechle 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

arch/mips/kernel/mips-cpc.c:47: undefined reference to `mips_cpc_default_phys_base'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1001354ca34179f3db924eb66672442a173147dc
commit: eed0eabd12ef061821cbfa20d903476e07645320 MIPS: generic: Introduce 
generic DT-based board support
date:   9 days ago
config: mips-generic_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout eed0eabd12ef061821cbfa20d903476e07645320
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

   arch/mips/built-in.o: In function `mips_cpc_phys_base':
>> arch/mips/kernel/mips-cpc.c:47: undefined reference to 
>> `mips_cpc_default_phys_base'

vim +47 arch/mips/kernel/mips-cpc.c

8dedde6b2 Bjorn Helgaas   2015-07-12  31  static phys_addr_t 
mips_cpc_phys_base(void)
9c38cf447 Paul Burton 2014-01-15  32  {
391057d91 Markos Chandras 2015-07-09  33unsigned long cpc_base;
9c38cf447 Paul Burton 2014-01-15  34  
9c38cf447 Paul Burton 2014-01-15  35if (!mips_cm_present())
9c38cf447 Paul Burton 2014-01-15  36return 0;
9c38cf447 Paul Burton 2014-01-15  37  
9c38cf447 Paul Burton 2014-01-15  38if (!(read_gcr_cpc_status() & 
CM_GCR_CPC_STATUS_EX_MSK))
9c38cf447 Paul Burton 2014-01-15  39return 0;
9c38cf447 Paul Burton 2014-01-15  40  
9c38cf447 Paul Burton 2014-01-15  41/* If the CPC is already 
enabled, leave it so */
9c38cf447 Paul Burton 2014-01-15  42cpc_base = read_gcr_cpc_base();
9c38cf447 Paul Burton 2014-01-15  43if (cpc_base & 
CM_GCR_CPC_BASE_CPCEN_MSK)
9c38cf447 Paul Burton 2014-01-15  44return cpc_base & 
CM_GCR_CPC_BASE_CPCBASE_MSK;
9c38cf447 Paul Burton 2014-01-15  45  
9c38cf447 Paul Burton 2014-01-15  46/* Otherwise, give it the 
default address & enable it */
9c38cf447 Paul Burton 2014-01-15 @47cpc_base = 
mips_cpc_default_phys_base();
9c38cf447 Paul Burton 2014-01-15  48write_gcr_cpc_base(cpc_base | 
CM_GCR_CPC_BASE_CPCEN_MSK);
9c38cf447 Paul Burton 2014-01-15  49return cpc_base;
9c38cf447 Paul Burton 2014-01-15  50  }
9c38cf447 Paul Burton 2014-01-15  51  
9c38cf447 Paul Burton 2014-01-15  52  int mips_cpc_probe(void)
9c38cf447 Paul Burton 2014-01-15  53  {
15d45cce3 Ralf Baechle2014-11-22  54phys_addr_t addr;
6b89d22e7 Matt Redfearn   2016-09-07  55unsigned int cpu;

:: The code at line 47 was first introduced by commit
:: 9c38cf44712af95a5ec3937d63faaea9b43eab9a MIPS: Add CPC probe, access 
functions

:: TO: Paul Burton 
:: CC: Ralf Baechle 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v2] r8169: set coherent DMA mask as well as streaming DMA mask

[David Miller]

From: Ard Biesheuvel 
Date: Fri, 14 Oct 2016 14:48:51 +0100

> 
>> On 14 Oct 2016, at 14:42, David Laight  wrote:
>> 
>> From: Of Ard Biesheuvel
>>> Sent: 14 October 2016 14:41
>>> PCI devices that are 64-bit DMA capable should set the coherent
>>> DMA mask as well as the streaming DMA mask. On some architectures,
>>> these are managed separately, and so the coherent DMA mask will be
>>> left at its default value of 32 if it is not set explicitly. This
>>> results in errors such as
>>> 
>>> r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
>>> hwdev DMA mask = 0x, dev_addr = 0x0080fbfff000
>>> swiotlb: coherent allocation failed for device :02:00.0 size=4096
>>> CPU: 0 PID: 1062 Comm: systemd-udevd Not tainted 4.8.0+ #35
>>> Hardware name: AMD Seattle/Seattle, BIOS 10:53:24 Oct 13 2016
>>> 
>>> on systems without memory that is 32-bit addressable by PCI devices.
>>> 
>>> Signed-off-by: Ard Biesheuvel 
>>> ---
>>> v2: dropped the hunk that sets the coherent DMA mask to DMA_BIT_MASK(32),
>>>which is unnecessary given that it is the default
>>> 
>>> drivers/net/ethernet/realtek/r8169.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/drivers/net/ethernet/realtek/r8169.c 
>>> b/drivers/net/ethernet/realtek/r8169.c
>>> index e55638c7505a..bf000d819a21 100644
>>> --- a/drivers/net/ethernet/realtek/r8169.c
>>> +++ b/drivers/net/ethernet/realtek/r8169.c
>>> @@ -8273,7 +8273,8 @@ static int rtl_init_one(struct pci_dev *pdev, const 
>>> struct pci_device_id *ent)
>>>if ((sizeof(dma_addr_t) > 4) &&
>>>(use_dac == 1 || (use_dac == -1 && pci_is_pcie(pdev) &&
>>>  tp->mac_version >= RTL_GIGA_MAC_VER_18)) &&
>>> -!pci_set_dma_mask(pdev, DMA_BIT_MASK(64))) {
>>> +!pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) &&
>>> +!pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64))) {
>> 
>> Isn't there a dma_set_mask_and_coherent() function ?
>> 
> 
> Not of the pci_xxx variety afaik

You can often use the "dev_*" variants intechangably with the pci_*()
ones.

In fact you'll find that for several architectures pci_*() is
implemented via calls to dev_*().

Re: [PATCH v2] r8169: set coherent DMA mask as well as streaming DMA mask

[David Miller]

From: Ard Biesheuvel 
Date: Fri, 14 Oct 2016 14:48:51 +0100

> 
>> On 14 Oct 2016, at 14:42, David Laight  wrote:
>> 
>> From: Of Ard Biesheuvel
>>> Sent: 14 October 2016 14:41
>>> PCI devices that are 64-bit DMA capable should set the coherent
>>> DMA mask as well as the streaming DMA mask. On some architectures,
>>> these are managed separately, and so the coherent DMA mask will be
>>> left at its default value of 32 if it is not set explicitly. This
>>> results in errors such as
>>> 
>>> r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
>>> hwdev DMA mask = 0x, dev_addr = 0x0080fbfff000
>>> swiotlb: coherent allocation failed for device :02:00.0 size=4096
>>> CPU: 0 PID: 1062 Comm: systemd-udevd Not tainted 4.8.0+ #35
>>> Hardware name: AMD Seattle/Seattle, BIOS 10:53:24 Oct 13 2016
>>> 
>>> on systems without memory that is 32-bit addressable by PCI devices.
>>> 
>>> Signed-off-by: Ard Biesheuvel 
>>> ---
>>> v2: dropped the hunk that sets the coherent DMA mask to DMA_BIT_MASK(32),
>>>which is unnecessary given that it is the default
>>> 
>>> drivers/net/ethernet/realtek/r8169.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/drivers/net/ethernet/realtek/r8169.c 
>>> b/drivers/net/ethernet/realtek/r8169.c
>>> index e55638c7505a..bf000d819a21 100644
>>> --- a/drivers/net/ethernet/realtek/r8169.c
>>> +++ b/drivers/net/ethernet/realtek/r8169.c
>>> @@ -8273,7 +8273,8 @@ static int rtl_init_one(struct pci_dev *pdev, const 
>>> struct pci_device_id *ent)
>>>if ((sizeof(dma_addr_t) > 4) &&
>>>(use_dac == 1 || (use_dac == -1 && pci_is_pcie(pdev) &&
>>>  tp->mac_version >= RTL_GIGA_MAC_VER_18)) &&
>>> -!pci_set_dma_mask(pdev, DMA_BIT_MASK(64))) {
>>> +!pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) &&
>>> +!pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64))) {
>> 
>> Isn't there a dma_set_mask_and_coherent() function ?
>> 
> 
> Not of the pci_xxx variety afaik

You can often use the "dev_*" variants intechangably with the pci_*()
ones.

In fact you'll find that for several architectures pci_*() is
implemented via calls to dev_*().

Re: [PATCH v2] r8169: set coherent DMA mask as well as streaming DMA mask

[David Miller]

From: Ard Biesheuvel 
Date: Fri, 14 Oct 2016 14:40:33 +0100

> PCI devices that are 64-bit DMA capable should set the coherent
> DMA mask as well as the streaming DMA mask. On some architectures,
> these are managed separately, and so the coherent DMA mask will be
> left at its default value of 32 if it is not set explicitly. This
> results in errors such as
> 
>  r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
>  hwdev DMA mask = 0x, dev_addr = 0x0080fbfff000
>  swiotlb: coherent allocation failed for device :02:00.0 size=4096
>  CPU: 0 PID: 1062 Comm: systemd-udevd Not tainted 4.8.0+ #35
>  Hardware name: AMD Seattle/Seattle, BIOS 10:53:24 Oct 13 2016
> 
> on systems without memory that is 32-bit addressable by PCI devices.
> 
> Signed-off-by: Ard Biesheuvel 

Applied.

Re: [PATCH v2] r8169: set coherent DMA mask as well as streaming DMA mask

[David Miller]

From: Ard Biesheuvel 
Date: Fri, 14 Oct 2016 14:40:33 +0100

> PCI devices that are 64-bit DMA capable should set the coherent
> DMA mask as well as the streaming DMA mask. On some architectures,
> these are managed separately, and so the coherent DMA mask will be
> left at its default value of 32 if it is not set explicitly. This
> results in errors such as
> 
>  r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
>  hwdev DMA mask = 0x, dev_addr = 0x0080fbfff000
>  swiotlb: coherent allocation failed for device :02:00.0 size=4096
>  CPU: 0 PID: 1062 Comm: systemd-udevd Not tainted 4.8.0+ #35
>  Hardware name: AMD Seattle/Seattle, BIOS 10:53:24 Oct 13 2016
> 
> on systems without memory that is 32-bit addressable by PCI devices.
> 
> Signed-off-by: Ard Biesheuvel 

Applied.

Re:Private Donation To You(Reply)

[Mrs Julie Leach]

Dear Beneficiary,

I am Julie Leach, 50 years old lucky woman from Three Rivers, Michigan who won 
$310.5 Million Dollars Powerball Jackpot on September 30, 2015. I wish to 
inform you that your email was randomly selected via Google & Facebook 
sponsored email-draws as one of our beneficiaries to receive my donation grant 
of $500,000.00 USD which will be given to five(5)lucky winners each and also to 
ten(10)charity organization, as part of my contributions to humanity all over 
the world. Kindly view the  News Link below for more info;

http://www.nbcnews.com/news/us-news/julie-leach-fiberglass-factory-employee-wins-310-5-million-powerball-n439331

Please write back with your *Full Names:..,*Tel:...*Age:& *Country:... and 
Remember to be a blessing to your family and the society at large as soon as 
this donation gets to you.

Mrs Julie Leach.
Copyright 2016 Julie Leach Donation Project(JLDP)All Rights Reserved

Re:Private Donation To You(Reply)

[Mrs Julie Leach]

Dear Beneficiary,

I am Julie Leach, 50 years old lucky woman from Three Rivers, Michigan who won 
$310.5 Million Dollars Powerball Jackpot on September 30, 2015. I wish to 
inform you that your email was randomly selected via Google & Facebook 
sponsored email-draws as one of our beneficiaries to receive my donation grant 
of $500,000.00 USD which will be given to five(5)lucky winners each and also to 
ten(10)charity organization, as part of my contributions to humanity all over 
the world. Kindly view the  News Link below for more info;

http://www.nbcnews.com/news/us-news/julie-leach-fiberglass-factory-employee-wins-310-5-million-powerball-n439331

Please write back with your *Full Names:..,*Tel:...*Age:& *Country:... and 
Remember to be a blessing to your family and the society at large as soon as 
this donation gets to you.

Mrs Julie Leach.
Copyright 2016 Julie Leach Donation Project(JLDP)All Rights Reserved

Re: [PATCH v2 0/4] PXA cpufreq conversion to clock API

[Robert Jarzmik]

Russell King - ARM Linux  writes:

> On Sat, Oct 15, 2016 at 09:57:26PM +0200, Robert Jarzmik wrote:
>> Hi,
>> 
>> This serie is a preparation to shift the cpufreq of pxa2xx platforms to 
>> clocks
>> API.
>> 
>> The first 3 patches are review and merge material :
>>  - patch 1/4 for Viresh and Rafael
>>  - patches 2/4 and 3/4 for me
>> 
>> The 4th on is for review but not merge, as the clock changes must be fully
>> reviewed and go in first as a prequisite
>
> Have you tested whether this patch set results in functional cpufreq
> support - looking at drivers/clk/pxa, the CPU clock is read-only -
> it can't be used to change the clock rate.  So, I very much doubt this
> has been functionally tested.

Oh yes I did, on lubbock and mainstone ... but this requires another patchset
under review, here :
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1247123.html

> Don't forget that changing the CPU clock rate needs other changes
> (like the memory clock rate) so all that code you're removing in
> patch 4 (which does the actual clock change) needs to go somewhere.
Sure, here :
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1247130.html

I would have been wiser to quote these URLs instead of speaking of "clock
changes must be fully review and go in first as a prequisite".

Cheers.

-- 
Robert

Re: [PATCH v2 0/4] PXA cpufreq conversion to clock API

[Robert Jarzmik]

Russell King - ARM Linux  writes:

> On Sat, Oct 15, 2016 at 09:57:26PM +0200, Robert Jarzmik wrote:
>> Hi,
>> 
>> This serie is a preparation to shift the cpufreq of pxa2xx platforms to 
>> clocks
>> API.
>> 
>> The first 3 patches are review and merge material :
>>  - patch 1/4 for Viresh and Rafael
>>  - patches 2/4 and 3/4 for me
>> 
>> The 4th on is for review but not merge, as the clock changes must be fully
>> reviewed and go in first as a prequisite
>
> Have you tested whether this patch set results in functional cpufreq
> support - looking at drivers/clk/pxa, the CPU clock is read-only -
> it can't be used to change the clock rate.  So, I very much doubt this
> has been functionally tested.

Oh yes I did, on lubbock and mainstone ... but this requires another patchset
under review, here :
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1247123.html

> Don't forget that changing the CPU clock rate needs other changes
> (like the memory clock rate) so all that code you're removing in
> patch 4 (which does the actual clock change) needs to go somewhere.
Sure, here :
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1247130.html

I would have been wiser to quote these URLs instead of speaking of "clock
changes must be fully review and go in first as a prequisite".

Cheers.

-- 
Robert

linux-next: manual merge of the net tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net tree got a conflict in:

  drivers/net/ethernet/qlogic/Kconfig

between commit:

  2e0cbc4dd077 ("qedr: Add RoCE driver framework")

from Linus' tree and commit:

  0189efb8f4f8 ("qed*: Fix Kconfig dependencies with INFINIBAND_QEDR")

from the net tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

I also added this merge fix patch:

From: Stephen Rothwell 
Date: Sun, 16 Oct 2016 08:09:42 +1100
Subject: [PATCH] qed*: merge fix for CONFIG_INFINIBAND_QEDR Kconfig move

Signed-off-by: Stephen Rothwell 
---
 drivers/infiniband/hw/qedr/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/infiniband/hw/qedr/Kconfig 
b/drivers/infiniband/hw/qedr/Kconfig
index 7c06d85568d4..6c9f3923e838 100644
--- a/drivers/infiniband/hw/qedr/Kconfig
+++ b/drivers/infiniband/hw/qedr/Kconfig
@@ -2,6 +2,7 @@ config INFINIBAND_QEDR
tristate "QLogic RoCE driver"
depends on 64BIT && QEDE
select QED_LL2
+   select QED_RDMA
---help---
  This driver provides low-level InfiniBand over Ethernet
  support for QLogic QED host channel adapters (HCAs).
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/ethernet/qlogic/Kconfig
index 1e8339a67f6e,77567727528a..
--- a/drivers/net/ethernet/qlogic/Kconfig
+++ b/drivers/net/ethernet/qlogic/Kconfig
@@@ -107,4 -107,19 +107,7 @@@ config QED
---help---
  This enables the support for ...
  
+ config QED_RDMA
+   bool
+ 
 -config INFINIBAND_QEDR
 -  tristate "QLogic qede RoCE sources [debug]"
 -  depends on QEDE && 64BIT
 -  select QED_LL2
 -  select QED_RDMA
 -  default n
 -  ---help---
 -This provides a temporary node that allows the compilation
 -and logical testing of the InfiniBand over Ethernet support
 -for QLogic QED. This would be replaced by the 'real' option
 -once the QEDR driver is added [+relocated].
 -
  endif # NET_VENDOR_QLOGIC

linux-next: manual merge of the net tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the net tree got a conflict in:

  drivers/net/ethernet/qlogic/Kconfig

between commit:

  2e0cbc4dd077 ("qedr: Add RoCE driver framework")

from Linus' tree and commit:

  0189efb8f4f8 ("qed*: Fix Kconfig dependencies with INFINIBAND_QEDR")

from the net tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

I also added this merge fix patch:

From: Stephen Rothwell 
Date: Sun, 16 Oct 2016 08:09:42 +1100
Subject: [PATCH] qed*: merge fix for CONFIG_INFINIBAND_QEDR Kconfig move

Signed-off-by: Stephen Rothwell 
---
 drivers/infiniband/hw/qedr/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/infiniband/hw/qedr/Kconfig 
b/drivers/infiniband/hw/qedr/Kconfig
index 7c06d85568d4..6c9f3923e838 100644
--- a/drivers/infiniband/hw/qedr/Kconfig
+++ b/drivers/infiniband/hw/qedr/Kconfig
@@ -2,6 +2,7 @@ config INFINIBAND_QEDR
tristate "QLogic RoCE driver"
depends on 64BIT && QEDE
select QED_LL2
+   select QED_RDMA
---help---
  This driver provides low-level InfiniBand over Ethernet
  support for QLogic QED host channel adapters (HCAs).
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/ethernet/qlogic/Kconfig
index 1e8339a67f6e,77567727528a..
--- a/drivers/net/ethernet/qlogic/Kconfig
+++ b/drivers/net/ethernet/qlogic/Kconfig
@@@ -107,4 -107,19 +107,7 @@@ config QED
---help---
  This enables the support for ...
  
+ config QED_RDMA
+   bool
+ 
 -config INFINIBAND_QEDR
 -  tristate "QLogic qede RoCE sources [debug]"
 -  depends on QEDE && 64BIT
 -  select QED_LL2
 -  select QED_RDMA
 -  default n
 -  ---help---
 -This provides a temporary node that allows the compilation
 -and logical testing of the InfiniBand over Ethernet support
 -for QLogic QED. This would be replaced by the 'real' option
 -once the QEDR driver is added [+relocated].
 -
  endif # NET_VENDOR_QLOGIC

Re: [PATCH v2 1/3] net: smc91x: isolate u16 writes alignment workaround

[Robert Jarzmik]

Sorry David, I just noticed you weren't in the "To:" of this serie, but I won't
forget you for the v3 I need to release anyway
(https://lkml.org/lkml/2016/10/15/104).

Robert Jarzmik  writes:
> + lp->half_word_align4 =
> + machine_is_mainstone() || machine_is_stargate2() ||
> + machine_is_pxa_idp();

Bah this one is not good enough.

First, machine_is_*() is not defined if CONFIG_ARM=n, and this part is not under
a #ifdef CONFIG_ARM.

Moreover, I think it is a good occasion to go further, and :
 - enhance smc91x_platdata and add a pxa_u16_align4 boolean
 - transform this statement into :
lp->half_word_align4 = lp->cfg.pxa_u16_align4

This will remove the machine_*() calls from the smc91x driver, which looks a
good move, doesn't it ?

Cheers.

--
Robert

Re: [PATCH v2 1/3] net: smc91x: isolate u16 writes alignment workaround

[Robert Jarzmik]

Sorry David, I just noticed you weren't in the "To:" of this serie, but I won't
forget you for the v3 I need to release anyway
(https://lkml.org/lkml/2016/10/15/104).

Robert Jarzmik  writes:
> + lp->half_word_align4 =
> + machine_is_mainstone() || machine_is_stargate2() ||
> + machine_is_pxa_idp();

Bah this one is not good enough.

First, machine_is_*() is not defined if CONFIG_ARM=n, and this part is not under
a #ifdef CONFIG_ARM.

Moreover, I think it is a good occasion to go further, and :
 - enhance smc91x_platdata and add a pxa_u16_align4 boolean
 - transform this statement into :
lp->half_word_align4 = lp->cfg.pxa_u16_align4

This will remove the machine_*() calls from the smc91x driver, which looks a
good move, doesn't it ?

Cheers.

--
Robert

[PATCH] sunrpc & nfs: Add and use dprintk_cont macros

[Joe Perches]

Allow line continuations to work properly with KERN_CONT.

Signed-off-by: Joe Perches 
---
 fs/nfs/write.c   |  6 ++---
 include/linux/sunrpc/debug.h | 57 ++--
 2 files changed, 42 insertions(+), 21 deletions(-)

diff --git a/fs/nfs/write.c b/fs/nfs/write.c
index 53211838f72a..508efa813475 100644
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -1788,7 +1788,7 @@ static void nfs_commit_release_pages(struct 
nfs_commit_data *data)
if (status < 0) {
nfs_context_set_write_error(req->wb_context, status);
nfs_inode_remove_request(req);
-   dprintk(", error = %d\n", status);
+   dprintk_cont(", error = %d\n", status);
goto next;
}
 
@@ -1797,11 +1797,11 @@ static void nfs_commit_release_pages(struct 
nfs_commit_data *data)
if (!nfs_write_verifier_cmp(>wb_verf, 
>verf.verifier)) {
/* We have a match */
nfs_inode_remove_request(req);
-   dprintk(" OK\n");
+   dprintk_cont(" OK\n");
goto next;
}
/* We have a mismatch. Write the page again */
-   dprintk(" mismatch\n");
+   dprintk_cont(" mismatch\n");
nfs_mark_request_dirty(req);
set_bit(NFS_CONTEXT_RESEND_WRITES, >wb_context->flags);
next:
diff --git a/include/linux/sunrpc/debug.h b/include/linux/sunrpc/debug.h
index 59a7889e15db..a44c479b09e0 100644
--- a/include/linux/sunrpc/debug.h
+++ b/include/linux/sunrpc/debug.h
@@ -20,33 +20,54 @@ extern unsigned int nfsd_debug;
 extern unsigned intnlm_debug;
 #endif
 
-#define dprintk(args...)   dfprintk(FACILITY, ## args)
-#define dprintk_rcu(args...)   dfprintk_rcu(FACILITY, ## args)
+#define dprintk(fmt, ...)  \
+   dfprintk(FACILITY, fmt, ##__VA_ARGS__)
+#define dprintk_cont(fmt, ...) \
+   dfprintk_cont(FACILITY, fmt, ##__VA_ARGS__)
+#define dprintk_rcu(fmt, ...)  \
+   dfprintk_rcu(FACILITY, fmt, ##__VA_ARGS__)
+#define dprintk_rcu_cont(fmt, ...) \
+   dfprintk_rcu_cont(FACILITY, fmt, ##__VA_ARGS__)
 
 #undef ifdebug
 #if IS_ENABLED(CONFIG_SUNRPC_DEBUG)
 # define ifdebug(fac)  if (unlikely(rpc_debug & RPCDBG_##fac))
 
-# define dfprintk(fac, args...)\
-   do { \
-   ifdebug(fac) \
-   printk(KERN_DEFAULT args); \
-   } while (0)
-
-# define dfprintk_rcu(fac, args...)\
-   do { \
-   ifdebug(fac) { \
-   rcu_read_lock(); \
-   printk(KERN_DEFAULT args); \
-   rcu_read_unlock(); \
-   } \
-   } while (0)
+# define dfprintk(fac, fmt, ...)   \
+do {   \
+   ifdebug(fac)\
+   printk(KERN_DEFAULT fmt, ##__VA_ARGS__);\
+} while (0)
+
+# define dfprintk_cont(fac, fmt, ...)  \
+do {   \
+   ifdebug(fac)\
+   printk(KERN_CONT fmt, ##__VA_ARGS__);   \
+} while (0)
+
+# define dfprintk_rcu(fac, fmt, ...)   \
+do {   \
+   ifdebug(fac) {  \
+   rcu_read_lock();\
+   printk(KERN_DEFAULT fmt, ##__VA_ARGS__);\
+   rcu_read_unlock();  \
+   }   \
+} while (0)
+
+# define dfprintk_rcu_cont(fac, fmt, ...)  \
+do {   \
+   ifdebug(fac) {  \
+   rcu_read_lock();\
+   printk(KERN_CONT fmt, ##__VA_ARGS__);   \
+   rcu_read_unlock();  \
+   }   \
+} while (0)
 
 # define RPC_IFDEBUG(x)x
 #else
 # define ifdebug(fac)  if (0)
-# define dfprintk(fac, args...)do {} while (0)
-# define dfprintk_rcu(fac, args...)do {} while (0)
+# define dfprintk(fac, fmt, ...)   do {} while (0)
+# define dfprintk_rcu(fac, fmt, 

[PATCH] sunrpc & nfs: Add and use dprintk_cont macros

[Joe Perches]

Allow line continuations to work properly with KERN_CONT.

Signed-off-by: Joe Perches 
---
 fs/nfs/write.c   |  6 ++---
 include/linux/sunrpc/debug.h | 57 ++--
 2 files changed, 42 insertions(+), 21 deletions(-)

diff --git a/fs/nfs/write.c b/fs/nfs/write.c
index 53211838f72a..508efa813475 100644
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -1788,7 +1788,7 @@ static void nfs_commit_release_pages(struct 
nfs_commit_data *data)
if (status < 0) {
nfs_context_set_write_error(req->wb_context, status);
nfs_inode_remove_request(req);
-   dprintk(", error = %d\n", status);
+   dprintk_cont(", error = %d\n", status);
goto next;
}
 
@@ -1797,11 +1797,11 @@ static void nfs_commit_release_pages(struct 
nfs_commit_data *data)
if (!nfs_write_verifier_cmp(>wb_verf, 
>verf.verifier)) {
/* We have a match */
nfs_inode_remove_request(req);
-   dprintk(" OK\n");
+   dprintk_cont(" OK\n");
goto next;
}
/* We have a mismatch. Write the page again */
-   dprintk(" mismatch\n");
+   dprintk_cont(" mismatch\n");
nfs_mark_request_dirty(req);
set_bit(NFS_CONTEXT_RESEND_WRITES, >wb_context->flags);
next:
diff --git a/include/linux/sunrpc/debug.h b/include/linux/sunrpc/debug.h
index 59a7889e15db..a44c479b09e0 100644
--- a/include/linux/sunrpc/debug.h
+++ b/include/linux/sunrpc/debug.h
@@ -20,33 +20,54 @@ extern unsigned int nfsd_debug;
 extern unsigned intnlm_debug;
 #endif
 
-#define dprintk(args...)   dfprintk(FACILITY, ## args)
-#define dprintk_rcu(args...)   dfprintk_rcu(FACILITY, ## args)
+#define dprintk(fmt, ...)  \
+   dfprintk(FACILITY, fmt, ##__VA_ARGS__)
+#define dprintk_cont(fmt, ...) \
+   dfprintk_cont(FACILITY, fmt, ##__VA_ARGS__)
+#define dprintk_rcu(fmt, ...)  \
+   dfprintk_rcu(FACILITY, fmt, ##__VA_ARGS__)
+#define dprintk_rcu_cont(fmt, ...) \
+   dfprintk_rcu_cont(FACILITY, fmt, ##__VA_ARGS__)
 
 #undef ifdebug
 #if IS_ENABLED(CONFIG_SUNRPC_DEBUG)
 # define ifdebug(fac)  if (unlikely(rpc_debug & RPCDBG_##fac))
 
-# define dfprintk(fac, args...)\
-   do { \
-   ifdebug(fac) \
-   printk(KERN_DEFAULT args); \
-   } while (0)
-
-# define dfprintk_rcu(fac, args...)\
-   do { \
-   ifdebug(fac) { \
-   rcu_read_lock(); \
-   printk(KERN_DEFAULT args); \
-   rcu_read_unlock(); \
-   } \
-   } while (0)
+# define dfprintk(fac, fmt, ...)   \
+do {   \
+   ifdebug(fac)\
+   printk(KERN_DEFAULT fmt, ##__VA_ARGS__);\
+} while (0)
+
+# define dfprintk_cont(fac, fmt, ...)  \
+do {   \
+   ifdebug(fac)\
+   printk(KERN_CONT fmt, ##__VA_ARGS__);   \
+} while (0)
+
+# define dfprintk_rcu(fac, fmt, ...)   \
+do {   \
+   ifdebug(fac) {  \
+   rcu_read_lock();\
+   printk(KERN_DEFAULT fmt, ##__VA_ARGS__);\
+   rcu_read_unlock();  \
+   }   \
+} while (0)
+
+# define dfprintk_rcu_cont(fac, fmt, ...)  \
+do {   \
+   ifdebug(fac) {  \
+   rcu_read_lock();\
+   printk(KERN_CONT fmt, ##__VA_ARGS__);   \
+   rcu_read_unlock();  \
+   }   \
+} while (0)
 
 # define RPC_IFDEBUG(x)x
 #else
 # define ifdebug(fac)  if (0)
-# define dfprintk(fac, args...)do {} while (0)
-# define dfprintk_rcu(fac, args...)do {} while (0)
+# define dfprintk(fac, fmt, ...)   do {} while (0)
+# define dfprintk_rcu(fac, fmt, ...)   do {} while 

Re: [PATCH] perf: Fix typo "No enough" to "Not enough"

[Alexander Alemayhu]

On Fri, Oct 14, 2016 at 12:46:04PM -0300, Arnaldo Carvalho de Melo wrote:
> 
> Thanks, applied, but please next time add to the CC list people that
> last touched this code, like Wang, that I'm CC'ing here and in the patch
> I just applied.
>

Sorry, will do that next time.

-- 
Mit freundlichen Grüßen

Alexander Alemayhu

[PATCH 3/3] ARM-OMAP2+: pm-debug: Use seq_putc() in two functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 15 Oct 2016 22:30:44 +0200

A single character (line break) should be put into a sequence at the end.
Thus use the corresponding function "seq_putc".

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 arch/arm/mach-omap2/pm-debug.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 0b33986..003a6cb 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -114,8 +114,7 @@ static int pwrdm_dbg_show_counter(struct powerdomain 
*pwrdm, void *user)
seq_printf(s, ",RET-MEMBANK%d-OFF:%d", i + 1,
pwrdm->ret_mem_off_counter[i]);
 
-   seq_printf(s, "\n");
-
+   seq_putc(s, '\n');
return 0;
 }
 
@@ -138,7 +137,7 @@ static int pwrdm_dbg_show_timer(struct powerdomain *pwrdm, 
void *user)
seq_printf(s, ",%s:%lld", pwrdm_state_names[i],
pwrdm->state_timer[i]);
 
-   seq_printf(s, "\n");
+   seq_putc(s, '\n');
return 0;
 }
 
-- 
2.10.1

[PATCH 3/3] ARM-OMAP2+: pm-debug: Use seq_putc() in two functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 15 Oct 2016 22:30:44 +0200

A single character (line break) should be put into a sequence at the end.
Thus use the corresponding function "seq_putc".

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 arch/arm/mach-omap2/pm-debug.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 0b33986..003a6cb 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -114,8 +114,7 @@ static int pwrdm_dbg_show_counter(struct powerdomain 
*pwrdm, void *user)
seq_printf(s, ",RET-MEMBANK%d-OFF:%d", i + 1,
pwrdm->ret_mem_off_counter[i]);
 
-   seq_printf(s, "\n");
-
+   seq_putc(s, '\n');
return 0;
 }
 
@@ -138,7 +137,7 @@ static int pwrdm_dbg_show_timer(struct powerdomain *pwrdm, 
void *user)
seq_printf(s, ",%s:%lld", pwrdm_state_names[i],
pwrdm->state_timer[i]);
 
-   seq_printf(s, "\n");
+   seq_putc(s, '\n');
return 0;
 }
 
-- 
2.10.1

Re: [PATCH] perf: Fix typo "No enough" to "Not enough"

[Alexander Alemayhu]

On Fri, Oct 14, 2016 at 12:46:04PM -0300, Arnaldo Carvalho de Melo wrote:
> 
> Thanks, applied, but please next time add to the CC list people that
> last touched this code, like Wang, that I'm CC'ing here and in the patch
> I just applied.
>

Sorry, will do that next time.

-- 
Mit freundlichen Grüßen

Alexander Alemayhu

Re: [PATCH v2 02/31] cinergyT2-core: don't do DMA on stack

[Johannes Stezenbach]

On Tue, Oct 11, 2016 at 07:09:17AM -0300, Mauro Carvalho Chehab wrote:
> --- a/drivers/media/usb/dvb-usb/cinergyT2-core.c
> +++ b/drivers/media/usb/dvb-usb/cinergyT2-core.c
> @@ -41,6 +41,8 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
>  
>  struct cinergyt2_state {
>   u8 rc_counter;
> + unsigned char data[64];
> + struct mutex data_mutex;
>  };

Sometimes my thinking is slow but it just occured to me
that this creates a potential issue with cache line sharing.
On an architecture which manages cache coherence in software
(ARM, MIPS etc.) a write to e.g. rc_counter in this example
would dirty the cache line, and a later writeback from the
cache could overwrite parts of data[] which was received via DMA.
In contrast, if the DMA buffer is allocated seperately via
kmalloc it is guaranteed to be safe wrt cache line sharing.
(see bottom of Documentation/DMA-API-HOWTO.txt).

But of course DMA on stack also had the same issue
and no one ever noticed so it's apparently not critical...


Johannes

Re: [PATCH v2 02/31] cinergyT2-core: don't do DMA on stack

[Johannes Stezenbach]

On Tue, Oct 11, 2016 at 07:09:17AM -0300, Mauro Carvalho Chehab wrote:
> --- a/drivers/media/usb/dvb-usb/cinergyT2-core.c
> +++ b/drivers/media/usb/dvb-usb/cinergyT2-core.c
> @@ -41,6 +41,8 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
>  
>  struct cinergyt2_state {
>   u8 rc_counter;
> + unsigned char data[64];
> + struct mutex data_mutex;
>  };

Sometimes my thinking is slow but it just occured to me
that this creates a potential issue with cache line sharing.
On an architecture which manages cache coherence in software
(ARM, MIPS etc.) a write to e.g. rc_counter in this example
would dirty the cache line, and a later writeback from the
cache could overwrite parts of data[] which was received via DMA.
In contrast, if the DMA buffer is allocated seperately via
kmalloc it is guaranteed to be safe wrt cache line sharing.
(see bottom of Documentation/DMA-API-HOWTO.txt).

But of course DMA on stack also had the same issue
and no one ever noticed so it's apparently not critical...


Johannes

[PATCH 2/3] ARM-OMAP2+: mux: Use seq_putc() in omap_mux_dbg_signal_show()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 15 Oct 2016 22:24:29 +0200

A single character (line break) should be put into a sequence.
Thus use the corresponding function "seq_putc".

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 arch/arm/mach-omap2/mux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 4bdfa3d..e1fa39e 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -661,7 +661,7 @@ static int omap_mux_dbg_signal_show(struct seq_file *s, 
void *unused)
m->balls[1] ? m->balls[1] : none);
seq_puts(s, "mode: ");
omap_mux_decode(s, val);
-   seq_printf(s, "\n");
+   seq_putc(s, '\n');
seq_printf(s, "signals: %s | %s | %s | %s | %s | %s | %s | %s\n",
m->muxnames[0] ? m->muxnames[0] : none,
m->muxnames[1] ? m->muxnames[1] : none,
-- 
2.10.1

[PATCH 2/3] ARM-OMAP2+: mux: Use seq_putc() in omap_mux_dbg_signal_show()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 15 Oct 2016 22:24:29 +0200

A single character (line break) should be put into a sequence.
Thus use the corresponding function "seq_putc".

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 arch/arm/mach-omap2/mux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 4bdfa3d..e1fa39e 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -661,7 +661,7 @@ static int omap_mux_dbg_signal_show(struct seq_file *s, 
void *unused)
m->balls[1] ? m->balls[1] : none);
seq_puts(s, "mode: ");
omap_mux_decode(s, val);
-   seq_printf(s, "\n");
+   seq_putc(s, '\n');
seq_printf(s, "signals: %s | %s | %s | %s | %s | %s | %s | %s\n",
m->muxnames[0] ? m->muxnames[0] : none,
m->muxnames[1] ? m->muxnames[1] : none,
-- 
2.10.1

[PATCH 1/3] ARM-OMAP2+: mux: Replace three seq_printf() calls by seq_puts()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 15 Oct 2016 22:22:09 +0200

Strings which did not contain data format specification should be put into
a sequence. Thus use the corresponding function "seq_puts".

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 arch/arm/mach-omap2/mux.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 176eef6..4bdfa3d 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -561,7 +561,7 @@ static inline void omap_mux_decode(struct seq_file *s, u16 
val)
do {
seq_printf(s, "%s", flags[i]);
if (i > 0)
-   seq_printf(s, " | ");
+   seq_puts(s, " | ");
} while (i-- > 0);
 }
 
@@ -602,7 +602,7 @@ static int omap_mux_dbg_board_show(struct seq_file *s, void 
*unused)
 */
seq_printf(s, "OMAP%d_MUX(%s, ", omap_gen, m0_def);
omap_mux_decode(s, val);
-   seq_printf(s, "),\n");
+   seq_puts(s, "),\n");
}
 
return 0;
@@ -659,7 +659,7 @@ static int omap_mux_dbg_signal_show(struct seq_file *s, 
void *unused)
partition->phys + m->reg_offset, m->reg_offset, val,
m->balls[0] ? m->balls[0] : none,
m->balls[1] ? m->balls[1] : none);
-   seq_printf(s, "mode: ");
+   seq_puts(s, "mode: ");
omap_mux_decode(s, val);
seq_printf(s, "\n");
seq_printf(s, "signals: %s | %s | %s | %s | %s | %s | %s | %s\n",
-- 
2.10.1

[PATCH 1/3] ARM-OMAP2+: mux: Replace three seq_printf() calls by seq_puts()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 15 Oct 2016 22:22:09 +0200

Strings which did not contain data format specification should be put into
a sequence. Thus use the corresponding function "seq_puts".

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 arch/arm/mach-omap2/mux.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 176eef6..4bdfa3d 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -561,7 +561,7 @@ static inline void omap_mux_decode(struct seq_file *s, u16 
val)
do {
seq_printf(s, "%s", flags[i]);
if (i > 0)
-   seq_printf(s, " | ");
+   seq_puts(s, " | ");
} while (i-- > 0);
 }
 
@@ -602,7 +602,7 @@ static int omap_mux_dbg_board_show(struct seq_file *s, void 
*unused)
 */
seq_printf(s, "OMAP%d_MUX(%s, ", omap_gen, m0_def);
omap_mux_decode(s, val);
-   seq_printf(s, "),\n");
+   seq_puts(s, "),\n");
}
 
return 0;
@@ -659,7 +659,7 @@ static int omap_mux_dbg_signal_show(struct seq_file *s, 
void *unused)
partition->phys + m->reg_offset, m->reg_offset, val,
m->balls[0] ? m->balls[0] : none,
m->balls[1] ? m->balls[1] : none);
-   seq_printf(s, "mode: ");
+   seq_puts(s, "mode: ");
omap_mux_decode(s, val);
seq_printf(s, "\n");
seq_printf(s, "signals: %s | %s | %s | %s | %s | %s | %s | %s\n",
-- 
2.10.1

[PATCH 0/3] ARM-OMAP2+: Fine-tuning for five function implementations

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 15 Oct 2016 22:44:22 +0200

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (3):
  mux: Replace three seq_printf() calls by seq_puts()
  mux: Use seq_putc() in omap_mux_dbg_signal_show()
  pm-debug: Use seq_putc() in two functions

 arch/arm/mach-omap2/mux.c  | 8 
 arch/arm/mach-omap2/pm-debug.c | 5 ++---
 2 files changed, 6 insertions(+), 7 deletions(-)

-- 
2.10.1

[PATCH 0/3] ARM-OMAP2+: Fine-tuning for five function implementations

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 15 Oct 2016 22:44:22 +0200

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (3):
  mux: Replace three seq_printf() calls by seq_puts()
  mux: Use seq_putc() in omap_mux_dbg_signal_show()
  pm-debug: Use seq_putc() in two functions

 arch/arm/mach-omap2/mux.c  | 8 
 arch/arm/mach-omap2/pm-debug.c | 5 ++---
 2 files changed, 6 insertions(+), 7 deletions(-)

-- 
2.10.1

Re: [PATCH v2 0/4] PXA cpufreq conversion to clock API

[Russell King - ARM Linux]

On Sat, Oct 15, 2016 at 09:57:26PM +0200, Robert Jarzmik wrote:
> Hi,
> 
> This serie is a preparation to shift the cpufreq of pxa2xx platforms to clocks
> API.
> 
> The first 3 patches are review and merge material :
>  - patch 1/4 for Viresh and Rafael
>  - patches 2/4 and 3/4 for me
> 
> The 4th on is for review but not merge, as the clock changes must be fully
> reviewed and go in first as a prequisite

Have you tested whether this patch set results in functional cpufreq
support - looking at drivers/clk/pxa, the CPU clock is read-only -
it can't be used to change the clock rate.  So, I very much doubt this
has been functionally tested.

Don't forget that changing the CPU clock rate needs other changes
(like the memory clock rate) so all that code you're removing in
patch 4 (which does the actual clock change) needs to go somewhere.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v2 0/4] PXA cpufreq conversion to clock API

[Russell King - ARM Linux]

On Sat, Oct 15, 2016 at 09:57:26PM +0200, Robert Jarzmik wrote:
> Hi,
> 
> This serie is a preparation to shift the cpufreq of pxa2xx platforms to clocks
> API.
> 
> The first 3 patches are review and merge material :
>  - patch 1/4 for Viresh and Rafael
>  - patches 2/4 and 3/4 for me
> 
> The 4th on is for review but not merge, as the clock changes must be fully
> reviewed and go in first as a prequisite

Have you tested whether this patch set results in functional cpufreq
support - looking at drivers/clk/pxa, the CPU clock is read-only -
it can't be used to change the clock rate.  So, I very much doubt this
has been functionally tested.

Don't forget that changing the CPU clock rate needs other changes
(like the memory clock rate) so all that code you're removing in
patch 4 (which does the actual clock change) needs to go somewhere.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH v2 4/4] cpufreq: pxa: convert to clock API

[Robert Jarzmik]

As the clock settings have been introduced into the clock pxa drivers,
which are now available to change the CPU clock by themselves, remove
the clock handling from this driver, and rely on pxa clock drivers.

Signed-off-by: Robert Jarzmik 
---
Since v1: added !OF Kconfig dependency
---
 drivers/cpufreq/Kconfig.arm  |   2 +-
 drivers/cpufreq/pxa2xx-cpufreq.c | 191 ---
 2 files changed, 40 insertions(+), 153 deletions(-)

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index d89b8afe23b6..1a4f04351f98 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -236,7 +236,7 @@ config ARM_TEGRA124_CPUFREQ
 
 config ARM_PXA2xx_CPUFREQ
tristate "Intel PXA2xx CPUfreq driver"
-   depends on PXA27x || PXA25x
+   depends on (PXA27x || PXA25x) && !OF
help
  This add the CPUFreq driver support for Intel PXA2xx SOCs.
 
diff --git a/drivers/cpufreq/pxa2xx-cpufreq.c b/drivers/cpufreq/pxa2xx-cpufreq.c
index ce345bf34d5d..06b024a3e474 100644
--- a/drivers/cpufreq/pxa2xx-cpufreq.c
+++ b/drivers/cpufreq/pxa2xx-cpufreq.c
@@ -58,56 +58,40 @@ module_param(pxa27x_maxfreq, uint, 0);
 MODULE_PARM_DESC(pxa27x_maxfreq, "Set the pxa27x maxfreq in MHz"
 "(typically 624=>pxa270, 416=>pxa271, 520=>pxa272)");
 
+struct pxa_cpufreq_data {
+   struct clk *clk_core;
+};
+static struct pxa_cpufreq_data  pxa_cpufreq_data;
+
 struct pxa_freqs {
unsigned int khz;
-   unsigned int membus;
-   unsigned int cccr;
-   unsigned int div2;
-   unsigned int cclkcfg;
int vmin;
int vmax;
 };
 
-/* Define the refresh period in mSec for the SDRAM and the number of rows */
-#define SDRAM_TREF 64  /* standard 64ms SDRAM */
-static unsigned int sdram_rows;
-
-#define CCLKCFG_TURBO  0x1
-#define CCLKCFG_FCS0x2
-#define CCLKCFG_HALFTURBO  0x4
-#define CCLKCFG_FASTBUS0x8
-#define MDREFR_DB2_MASK(MDREFR_K2DB2 | MDREFR_K1DB2)
-#define MDREFR_DRI_MASK0xFFF
-
-#define MDCNFG_DRAC2(mdcnfg) (((mdcnfg) >> 21) & 0x3)
-#define MDCNFG_DRAC0(mdcnfg) (((mdcnfg) >> 5) & 0x3)
-
 /*
  * PXA255 definitions
  */
-/* Use the run mode frequencies for the CPUFREQ_POLICY_PERFORMANCE policy */
-#define CCLKCFGCCLKCFG_TURBO | CCLKCFG_FCS
-
 static const struct pxa_freqs pxa255_run_freqs[] =
 {
-   /* CPU   MEMBUS  CCCR  DIV2 CCLKCFGrun  turbo PXbus 
SDRAM */
-   { 99500,  99500, 0x121, 1,  CCLKCFG, -1, -1},   /*  99,   99,   50,   
50  */
-   {132700, 132700, 0x123, 1,  CCLKCFG, -1, -1},   /* 133,  133,   66,   
66  */
-   {199100,  99500, 0x141, 0,  CCLKCFG, -1, -1},   /* 199,  199,   99,   
99  */
-   {265400, 132700, 0x143, 1,  CCLKCFG, -1, -1},   /* 265,  265,  133,   
66  */
-   {331800, 165900, 0x145, 1,  CCLKCFG, -1, -1},   /* 331,  331,  166,   
83  */
-   {398100,  99500, 0x161, 0,  CCLKCFG, -1, -1},   /* 398,  398,  196,   
99  */
+   /* CPU   MEMBUSrun  turbo PXbus SDRAM */
+   { 99500, -1, -1},   /*  99,   99,   50,   50  */
+   {132700, -1, -1},   /* 133,  133,   66,   66  */
+   {199100, -1, -1},   /* 199,  199,   99,   99  */
+   {265400, -1, -1},   /* 265,  265,  133,   66  */
+   {331800, -1, -1},   /* 331,  331,  166,   83  */
+   {398100, -1, -1},   /* 398,  398,  196,   99  */
 };
 
 /* Use the turbo mode frequencies for the CPUFREQ_POLICY_POWERSAVE policy */
 static const struct pxa_freqs pxa255_turbo_freqs[] =
 {
-   /* CPU   MEMBUS  CCCR  DIV2 CCLKCFGrun  turbo PXbus SDRAM */
-   { 99500, 99500,  0x121, 1,  CCLKCFG, -1, -1},   /*  99,   99,   50,   
50  */
-   {199100, 99500,  0x221, 0,  CCLKCFG, -1, -1},   /*  99,  199,   50,   
99  */
-   {298500, 99500,  0x321, 0,  CCLKCFG, -1, -1},   /*  99,  287,   50,   
99  */
-   {298600, 99500,  0x1c1, 0,  CCLKCFG, -1, -1},   /* 199,  287,   99,   
99  */
-   {398100, 99500,  0x241, 0,  CCLKCFG, -1, -1},   /* 199,  398,   99,   
99  */
+   /* CPU run  turbo PXbus SDRAM */
+   { 99500, -1, -1},   /*  99,   99,   50,   50  */
+   {199100, -1, -1},   /*  99,  199,   50,   99  */
+   {298500, -1, -1},   /*  99,  287,   50,   99  */
+   {298600, -1, -1},   /* 199,  287,   99,   99  */
+   {398100, -1, -1},   /* 199,  398,   99,   99  */
 };
 
 #define NUM_PXA25x_RUN_FREQS ARRAY_SIZE(pxa255_run_freqs)
@@ -122,47 +106,14 @@ static unsigned int pxa255_turbo_table;
 module_param(pxa255_turbo_table, uint, 0);
 MODULE_PARM_DESC(pxa255_turbo_table, "Selects the frequency table (0 = run 
table, !0 = turbo table)");
 
-/*
- * PXA270 definitions
- *
- * For the PXA27x:
- * Control variables are A, L, 2N for CCCR; B, HT, T for CLKCFG.
- *
- * A = 0 => memory controller clock from table 3-7,
- * A = 1 => memory controller clock = system 

[PATCH v2 4/4] cpufreq: pxa: convert to clock API

[Robert Jarzmik]

As the clock settings have been introduced into the clock pxa drivers,
which are now available to change the CPU clock by themselves, remove
the clock handling from this driver, and rely on pxa clock drivers.

Signed-off-by: Robert Jarzmik 
---
Since v1: added !OF Kconfig dependency
---
 drivers/cpufreq/Kconfig.arm  |   2 +-
 drivers/cpufreq/pxa2xx-cpufreq.c | 191 ---
 2 files changed, 40 insertions(+), 153 deletions(-)

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index d89b8afe23b6..1a4f04351f98 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -236,7 +236,7 @@ config ARM_TEGRA124_CPUFREQ
 
 config ARM_PXA2xx_CPUFREQ
tristate "Intel PXA2xx CPUfreq driver"
-   depends on PXA27x || PXA25x
+   depends on (PXA27x || PXA25x) && !OF
help
  This add the CPUFreq driver support for Intel PXA2xx SOCs.
 
diff --git a/drivers/cpufreq/pxa2xx-cpufreq.c b/drivers/cpufreq/pxa2xx-cpufreq.c
index ce345bf34d5d..06b024a3e474 100644
--- a/drivers/cpufreq/pxa2xx-cpufreq.c
+++ b/drivers/cpufreq/pxa2xx-cpufreq.c
@@ -58,56 +58,40 @@ module_param(pxa27x_maxfreq, uint, 0);
 MODULE_PARM_DESC(pxa27x_maxfreq, "Set the pxa27x maxfreq in MHz"
 "(typically 624=>pxa270, 416=>pxa271, 520=>pxa272)");
 
+struct pxa_cpufreq_data {
+   struct clk *clk_core;
+};
+static struct pxa_cpufreq_data  pxa_cpufreq_data;
+
 struct pxa_freqs {
unsigned int khz;
-   unsigned int membus;
-   unsigned int cccr;
-   unsigned int div2;
-   unsigned int cclkcfg;
int vmin;
int vmax;
 };
 
-/* Define the refresh period in mSec for the SDRAM and the number of rows */
-#define SDRAM_TREF 64  /* standard 64ms SDRAM */
-static unsigned int sdram_rows;
-
-#define CCLKCFG_TURBO  0x1
-#define CCLKCFG_FCS0x2
-#define CCLKCFG_HALFTURBO  0x4
-#define CCLKCFG_FASTBUS0x8
-#define MDREFR_DB2_MASK(MDREFR_K2DB2 | MDREFR_K1DB2)
-#define MDREFR_DRI_MASK0xFFF
-
-#define MDCNFG_DRAC2(mdcnfg) (((mdcnfg) >> 21) & 0x3)
-#define MDCNFG_DRAC0(mdcnfg) (((mdcnfg) >> 5) & 0x3)
-
 /*
  * PXA255 definitions
  */
-/* Use the run mode frequencies for the CPUFREQ_POLICY_PERFORMANCE policy */
-#define CCLKCFGCCLKCFG_TURBO | CCLKCFG_FCS
-
 static const struct pxa_freqs pxa255_run_freqs[] =
 {
-   /* CPU   MEMBUS  CCCR  DIV2 CCLKCFGrun  turbo PXbus 
SDRAM */
-   { 99500,  99500, 0x121, 1,  CCLKCFG, -1, -1},   /*  99,   99,   50,   
50  */
-   {132700, 132700, 0x123, 1,  CCLKCFG, -1, -1},   /* 133,  133,   66,   
66  */
-   {199100,  99500, 0x141, 0,  CCLKCFG, -1, -1},   /* 199,  199,   99,   
99  */
-   {265400, 132700, 0x143, 1,  CCLKCFG, -1, -1},   /* 265,  265,  133,   
66  */
-   {331800, 165900, 0x145, 1,  CCLKCFG, -1, -1},   /* 331,  331,  166,   
83  */
-   {398100,  99500, 0x161, 0,  CCLKCFG, -1, -1},   /* 398,  398,  196,   
99  */
+   /* CPU   MEMBUSrun  turbo PXbus SDRAM */
+   { 99500, -1, -1},   /*  99,   99,   50,   50  */
+   {132700, -1, -1},   /* 133,  133,   66,   66  */
+   {199100, -1, -1},   /* 199,  199,   99,   99  */
+   {265400, -1, -1},   /* 265,  265,  133,   66  */
+   {331800, -1, -1},   /* 331,  331,  166,   83  */
+   {398100, -1, -1},   /* 398,  398,  196,   99  */
 };
 
 /* Use the turbo mode frequencies for the CPUFREQ_POLICY_POWERSAVE policy */
 static const struct pxa_freqs pxa255_turbo_freqs[] =
 {
-   /* CPU   MEMBUS  CCCR  DIV2 CCLKCFGrun  turbo PXbus SDRAM */
-   { 99500, 99500,  0x121, 1,  CCLKCFG, -1, -1},   /*  99,   99,   50,   
50  */
-   {199100, 99500,  0x221, 0,  CCLKCFG, -1, -1},   /*  99,  199,   50,   
99  */
-   {298500, 99500,  0x321, 0,  CCLKCFG, -1, -1},   /*  99,  287,   50,   
99  */
-   {298600, 99500,  0x1c1, 0,  CCLKCFG, -1, -1},   /* 199,  287,   99,   
99  */
-   {398100, 99500,  0x241, 0,  CCLKCFG, -1, -1},   /* 199,  398,   99,   
99  */
+   /* CPU run  turbo PXbus SDRAM */
+   { 99500, -1, -1},   /*  99,   99,   50,   50  */
+   {199100, -1, -1},   /*  99,  199,   50,   99  */
+   {298500, -1, -1},   /*  99,  287,   50,   99  */
+   {298600, -1, -1},   /* 199,  287,   99,   99  */
+   {398100, -1, -1},   /* 199,  398,   99,   99  */
 };
 
 #define NUM_PXA25x_RUN_FREQS ARRAY_SIZE(pxa255_run_freqs)
@@ -122,47 +106,14 @@ static unsigned int pxa255_turbo_table;
 module_param(pxa255_turbo_table, uint, 0);
 MODULE_PARM_DESC(pxa255_turbo_table, "Selects the frequency table (0 = run 
table, !0 = turbo table)");
 
-/*
- * PXA270 definitions
- *
- * For the PXA27x:
- * Control variables are A, L, 2N for CCCR; B, HT, T for CLKCFG.
- *
- * A = 0 => memory controller clock from table 3-7,
- * A = 1 => memory controller clock = system bus clock
- * Run mode