Re: [PATCH V2 Resend 4/4] timer: Migrate running timer

[Viresh Kumar]

On 4 October 2013 18:09, Sebastian Andrzej Siewior
 wrote:
> tglx, could you please take a look at this patch / thread?

Thomas, Ping!!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 03/14] perf script: Make perf_script a local variable

[David Ahern]

On 10/22/13 8:34 AM, Adrian Hunter wrote:

-static int __cmd_script(struct perf_session *session)
+static int __cmd_script(struct perf_script *scr)


for naming consistency that should be *script.


  {
int ret;

signal(SIGINT, sig_handler);

-   ret = perf_session__process_events(session, _script);
+   ret = perf_session__process_events(scr->session, >tool);

if (debug_mode)
pr_err("Misordered timestamps: %" PRIu64 "\n", nr_unordered);
@@ -1273,6 +1264,21 @@ int cmd_script(int argc, const char **argv, const char 
*prefix __maybe_unused)
char *script_path = NULL;
const char **__argv;
int i, j, err;
+   struct perf_script perf_script = {


Ditto: struct perf_script script;


Otherwise the change looks fine to me.

Acked-by: David Ahern 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: Ensure get_unmapped_area() returns higher addressthan mmap_min_addr

[Akira Takeuchi]

Hi,

On Wed, 23 Oct 2013 00:26:05 -0400
Naoya Horiguchi  wrote:

> Hi,
> 
> On Wed, Oct 23, 2013 at 11:46:53AM +0900, Akira Takeuchi wrote:
> > This patch fixes the problem that get_unmapped_area() can return illegal
> > address and result in failing mmap(2) etc.
> > 
> > In case that the address higher than PAGE_SIZE is set to
> > /proc/sys/vm/mmap_min_addr, the address lower than mmap_min_addr can be
> > returned by get_unmapped_area(), even if you do not pass any virtual
> > address hint (i.e. the second argument).
> > 
> > This is because the current get_unmapped_area() code does not take into
> > account mmap_min_addr.
> > 
> > This leads to two actual problems as follows:
> > 
> > 1. mmap(2) can fail with EPERM on the process without CAP_SYS_RAWIO,
> >although any illegal parameter is not passed.
> > 
> > 2. The bottom-up search path after the top-down search might not work in
> >arch_get_unmapped_area_topdown().
> > 
> > [How to reproduce]
> > 
> > --- test.c -
> > #include 
> > #include 
> > #include 
> > #include 
> > 
> > int main(int argc, char *argv[])
> > {
> > void *ret = NULL, *last_map;
> > size_t pagesize = sysconf(_SC_PAGESIZE);
> > 
> > do {
> > last_map = ret;
> > ret = mmap(0, pagesize, PROT_NONE,
> > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
> > //  printf("ret=%p\n", ret);
> > } while (ret != MAP_FAILED);
> > 
> > if (errno != ENOMEM) {
> > printf("ERR: unexpected errno: %d (last map=%p)\n",
> > errno, last_map);
> > }
> > 
> > return 0;
> > }
> > ---
> > 
> > $ gcc -m32 -o test test.c
> > $ sudo sysctl -w vm.mmap_min_addr=65536
> > vm.mmap_min_addr = 65536
> > $ ./test  (run as non-priviledge user)
> > ERR: unexpected errno: 1 (last map=0x1)
> > 
> > Signed-off-by: Akira Takeuchi 
> > Signed-off-by: Kiyoshi Owada 
> > ---
> >  mm/mmap.c |   10 +-
> >  1 files changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/mm/mmap.c b/mm/mmap.c
> > index 9d54851..362e5f1 100644
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -1856,7 +1856,7 @@ arch_get_unmapped_area(struct file *filp, unsigned 
> > long addr,
> > struct vm_area_struct *vma;
> > struct vm_unmapped_area_info info;
> >  
> > -   if (len > TASK_SIZE)
> > +   if (len > TASK_SIZE - mmap_min_addr)
> > return -ENOMEM;
> >  
> > if (flags & MAP_FIXED)
> 
> I feel that it looks clearer to fix this in round_hint_to_min(),
> with doing mmap_min_addr check in hint == NULL case.
> Does it work for you?

The current round_hint_to_min() code checks and adjusts just for
the hint address, not for "len". Also, it returns no error.

Do you mean adding "len" to the argument of round_hint_to_min()
and making round_hint_to_min() return any error ?


Regards,
Akira Takeuchi

> Thanks,
> Naoya Horiguchi
> 
> > @@ -1865,7 +1865,7 @@ arch_get_unmapped_area(struct file *filp, unsigned 
> > long addr,
> > if (addr) {
> > addr = PAGE_ALIGN(addr);
> > vma = find_vma(mm, addr);
> > -   if (TASK_SIZE - len >= addr &&
> > +   if (TASK_SIZE - len >= addr && addr >= mmap_min_addr &&
> > (!vma || addr + len <= vma->vm_start))
> > return addr;
> > }
> > @@ -1895,7 +1895,7 @@ arch_get_unmapped_area_topdown(struct file *filp, 
> > const unsigned long addr0,
> > struct vm_unmapped_area_info info;
> >  
> > /* requested length too big for entire address space */
> > -   if (len > TASK_SIZE)
> > +   if (len > TASK_SIZE - mmap_min_addr)
> > return -ENOMEM;
> >  
> > if (flags & MAP_FIXED)
> > @@ -1905,14 +1905,14 @@ arch_get_unmapped_area_topdown(struct file *filp, 
> > const unsigned long addr0,
> > if (addr) {
> > addr = PAGE_ALIGN(addr);
> > vma = find_vma(mm, addr);
> > -   if (TASK_SIZE - len >= addr &&
> > +   if (TASK_SIZE - len >= addr && addr >= mmap_min_addr &&
> > (!vma || addr + len <= vma->vm_start))
> > return addr;
> > }
> >  
> > info.flags = VM_UNMAPPED_AREA_TOPDOWN;
> > info.length = len;
> > -   info.low_limit = PAGE_SIZE;
> > +   info.low_limit = max(PAGE_SIZE, mmap_min_addr);
> > info.high_limit = mm->mmap_base;
> > info.align_mask = 0;
> > addr = vm_unmapped_area();
> > -- 
> > 1.7.0.4
> > 
> > 
> > -- 
> > Akira Takeuchi 
> > 
> > --
> > To unsubscribe, send a message with 'unsubscribe linux-mm' in
> > the body to majord...@kvack.org.  For more info on Linux MM,
> > see: http://www.linux-mm.org/ .
> > Don't email: mailto:"d...@kvack.org;> em...@kvack.org 
> > 

-- 
Akira Takeuchi 

--
To unsubscribe from this list: 

Re: [PATCH, RFC] what's the point of mtd_inodefs?

[Richard Weinberger]

On Tue, Oct 22, 2013 at 5:33 PM, Christoph Hellwig  wrote:
> I've been looking at mtdchar as part of a bigger series touching all
> kidns of places and really wonder what the point of mtd_inodefs is.

As far I can tell it was introduced because of that issue:
http://lists.infradead.org/pipermail/linux-mtd/2010-April/029593.html

> We use it to make the file->f_mapping of the mtdchar device point to
> the mapping of it's inodes, but there's nothing special happening with
> mtd_inodefs inodes.  It seems to me like simply switching the
> backing_dev_info to the mtd one, similarly to what we do for /dev/mem
> and friends would be enough for mtdchar.
>
> If this works for the intended use case I'd love to add this series
> to my to be posted series as it would simplify it greatly.
>
>
> diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
> index 684bfa3..a7c9f37 100644
> --- a/drivers/mtd/mtdchar.c
> +++ b/drivers/mtd/mtdchar.c
> @@ -48,7 +48,6 @@ static DEFINE_MUTEX(mtd_mutex);
>   */
>  struct mtd_file_info {
> struct mtd_info *mtd;
> -   struct inode *ino;
> enum mtd_file_modes mode;
>  };
>
> @@ -58,10 +57,6 @@ static loff_t mtdchar_lseek(struct file *file, loff_t 
> offset, int orig)
> return fixed_size_llseek(file, offset, orig, mfi->mtd->size);
>  }
>
> -static int count;
> -static struct vfsmount *mnt;
> -static struct file_system_type mtd_inodefs_type;
> -
>  static int mtdchar_open(struct inode *inode, struct file *file)
>  {
> int minor = iminor(inode);
> @@ -69,7 +64,6 @@ static int mtdchar_open(struct inode *inode, struct file 
> *file)
> int ret = 0;
> struct mtd_info *mtd;
> struct mtd_file_info *mfi;
> -   struct inode *mtd_ino;
>
> pr_debug("MTD_open\n");
>
> @@ -77,60 +71,42 @@ static int mtdchar_open(struct inode *inode, struct file 
> *file)
> if ((file->f_mode & FMODE_WRITE) && (minor & 1))
> return -EACCES;
>
> -   ret = simple_pin_fs(_inodefs_type, , );
> -   if (ret)
> -   return ret;
> -
> mutex_lock(_mutex);
> -   mtd = get_mtd_device(NULL, devnum);
>
> +   mtd = get_mtd_device(NULL, devnum);
> if (IS_ERR(mtd)) {
> ret = PTR_ERR(mtd);
> -   goto out;
> +   goto out_unlock;
> }
>
> if (mtd->type == MTD_ABSENT) {
> ret = -ENODEV;
> -   goto out1;
> -   }
> -
> -   mtd_ino = iget_locked(mnt->mnt_sb, devnum);
> -   if (!mtd_ino) {
> -   ret = -ENOMEM;
> -   goto out1;
> +   goto out_put_device;
> }
> -   if (mtd_ino->i_state & I_NEW) {
> -   mtd_ino->i_private = mtd;
> -   mtd_ino->i_mode = S_IFCHR;
> -   mtd_ino->i_data.backing_dev_info = mtd->backing_dev_info;
> -   unlock_new_inode(mtd_ino);
> -   }
> -   file->f_mapping = mtd_ino->i_mapping;
>
> /* You can't open it RW if it's not a writeable device */
> if ((file->f_mode & FMODE_WRITE) && !(mtd->flags & MTD_WRITEABLE)) {
> ret = -EACCES;
> -   goto out2;
> +   goto out_put_device;
> }
>
> mfi = kzalloc(sizeof(*mfi), GFP_KERNEL);
> if (!mfi) {
> ret = -ENOMEM;
> -   goto out2;
> +   goto out_put_device;
> }
> -   mfi->ino = mtd_ino;
> mfi->mtd = mtd;
> +
> file->private_data = mfi;
> +   file->f_mapping->backing_dev_info = mtd->backing_dev_info;
> +
> mutex_unlock(_mutex);
> return 0;
>
> -out2:
> -   iput(mtd_ino);
> -out1:
> +out_put_device:
> put_mtd_device(mtd);
> -out:
> +out_unlock:
> mutex_unlock(_mutex);
> -   simple_release_fs(, );
> return ret;
>  } /* mtdchar_open */
>
> @@ -147,12 +123,9 @@ static int mtdchar_close(struct inode *inode, struct 
> file *file)
> if ((file->f_mode & FMODE_WRITE))
> mtd_sync(mtd);
>
> -   iput(mfi->ino);
> -
> put_mtd_device(mtd);
> file->private_data = NULL;
> kfree(mfi);
> -   simple_release_fs(, );
>
> return 0;
>  } /* mtdchar_close */
> @@ -1147,24 +1120,6 @@ static const struct file_operations mtd_fops = {
>  #endif
>  };
>
> -static const struct super_operations mtd_ops = {
> -   .drop_inode = generic_delete_inode,
> -   .statfs = simple_statfs,
> -};
> -
> -static struct dentry *mtd_inodefs_mount(struct file_system_type *fs_type,
> -   int flags, const char *dev_name, void *data)
> -{
> -   return mount_pseudo(fs_type, "mtd_inode:", _ops, NULL, 
> MTD_INODE_FS_MAGIC);
> -}
> -
> -static struct file_system_type mtd_inodefs_type = {
> -   .name = "mtd_inodefs",
> -   .mount = mtd_inodefs_mount,
> -   .kill_sb = kill_anon_super,
> -};
> -MODULE_ALIAS_FS("mtd_inodefs");
> -
>  int __init init_mtdchar(void)
>  {
> int ret;
> @@ 

Re: [PATCH 3.12] cfg80211: fix ibss wext chandef creation

[Dirk Gouders]

Simon Wunderlich  writes:

> The wext internal chandefs for ibss should be created using the
> cfg80211_chandef_create() functions. Otherwise the center_freq1 field
> will not be set and cfg80211_chandef_valid() will spit a warning and
> report the chandef as invalid when it should be used.

Thanks a lot, Simon, I don't see anymore traces here.

Tested-by: Dirk Gouders 

> Reported-by: Dirk Gouders 
> Signed-off-by: Simon Wunderlich 
> Cc: Johannes Berg 
> ---
>  net/wireless/ibss.c |   15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/net/wireless/ibss.c b/net/wireless/ibss.c
> index 39bff7d..a710019 100644
> --- a/net/wireless/ibss.c
> +++ b/net/wireless/ibss.c
> @@ -246,7 +246,7 @@ int cfg80211_ibss_wext_join(struct 
> cfg80211_registered_device *rdev,
>  
>   /* try to find an IBSS channel if none requested ... */
>   if (!wdev->wext.ibss.chandef.chan) {
> - wdev->wext.ibss.chandef.width = NL80211_CHAN_WIDTH_20_NOHT;
> + struct ieee80211_channel *new_chan = NULL;
>  
>   for (band = 0; band < IEEE80211_NUM_BANDS; band++) {
>   struct ieee80211_supported_band *sband;
> @@ -262,16 +262,19 @@ int cfg80211_ibss_wext_join(struct 
> cfg80211_registered_device *rdev,
>   continue;
>   if (chan->flags & IEEE80211_CHAN_DISABLED)
>   continue;
> - wdev->wext.ibss.chandef.chan = chan;
> + new_chan = chan;
>   break;
>   }
>  
> - if (wdev->wext.ibss.chandef.chan)
> + if (new_chan)
>   break;
>   }
>  
> - if (!wdev->wext.ibss.chandef.chan)
> + if (!new_chan)
>   return -EINVAL;
> +
> + cfg80211_chandef_create(>wext.ibss.chandef, new_chan,
> + NL80211_CHAN_NO_HT);
>   }
>  
>   /* don't join -- SSID is not there */
> @@ -345,8 +348,8 @@ int cfg80211_ibss_wext_siwfreq(struct net_device *dev,
>   return err;
>  
>   if (chan) {
> - wdev->wext.ibss.chandef.chan = chan;
> - wdev->wext.ibss.chandef.width = NL80211_CHAN_WIDTH_20_NOHT;
> + cfg80211_chandef_create(>wext.ibss.chandef, chan,
> + NL80211_CHAN_NO_HT);
>   wdev->wext.ibss.channel_fixed = true;
>   } else {
>   /* cfg80211_ibss_wext_join will pick one if needed */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG bisected] WARNING: CPU: 0 PID: 1550 at net/wireless/chan.c:373 cfg80211_chandef_usable+0x30/0x15f()

[Dirk Gouders]

Hi Simon,

Simon Wunderlich  writes:

> Hey Dirk,
>
>> No need for censorship, I did some quick tests and stripped down my
>> wpa_supplicant.conf to a single entry.  With this configuration I get a
>> lot of traces:
>> 
>> ctrl_interface=/var/run/wpa_supplicant
>> eapol_version=1
>> ap_scan=1
>> fast_reauth=1
>> 
>> network={
>>  frequency=2412
>>  group=TKIP
>>  key_mgmt=NONE
>>  mode=1
>>  pairwise=NONE
>>  ssid="Nokia_n9"
>> }
>> 
>> I will also attach a dmesg output of my tests.
>> 
>> >  * your wpa_supplicant command line parameters when running
>> 
>> It is running with a wpa_cli like this:
>> 
>> /usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf \
>> -W -B -i wlp4s0 -P /var/run/wpa_supplicant-wlp4s0.pid
>> /usr/bin/wpa_cli -a /etc/wpa_supplicant/wpa_cli.sh \
>> -p /var/run/wpa_supplicant -i wlp4s0 -P /var/run/wpa_cli-wlp4s0.pid -B
>> 
>
> Thanks a lot for this, I could reproduce the issue and fix it, will send the 
> fix 
> in a minute - please try and report back. 

thanks a lot, will send my test result immediately.

> Just two notes on your setup in case you are interested:

Yes, I am interested - I was just afraid to ask, because I didn't want
to cause too much noise with probably trivial problems ;-)

>  * Your wpa-supplicant setup looks a little like an old WPA-NONE setup, but 
> this is not supported anymore and will not encrypt your messages. Please have 
> a look at IBSS/RSN if you want encryption.

Yes, I very rarely use that connection and always have in mind that it
is unencrypted.  I will have a look at this but expect the mobile phone
side to be the hard one to get it to offer reliable encryption.

>  * Your wpa_supplicant uses the old wext interface to the kernel. This is 
> deprecated, it would better to use the (not so) new nl80211 interface 
> instead. 
> You will also get goodies such as 802.11n rates in ad-hoc mode if your 
> hardware supports it. :)

Thats good to know, I will change my setup accordingly.

Thanks again for your help,

Dirk

> Thanks again for reporting,
>Simon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 00/16] CPUIdle: Minor cleanups for 3.13

[Viresh Kumar]

On 3 October 2013 21:26, Viresh Kumar  wrote:
> These are V2 of my CPUIdle cleanup series.. Few patches are dropped as they
> required further modifications. Last one is rewritten as suggested by Daniel.
> Most of them are already Acked by Daniel.
>
> Viresh Kumar (16):
>   cpuidle: fix indentation of cpumask
>   cpuidle: Fix comments in cpuidle core
>   cpuidle: make __cpuidle_get_cpu_driver() inline
>   cpuidle: make __cpuidle_device_init() return void
>   cpuidle: make __cpuidle_driver_init() return void
>   cpuidle: rearrange code in __cpuidle_driver_init()
>   cpuidle: rearrange __cpuidle_register_device() to keep minimal exit
> points
>   cpuidle: merge two if() statements for checking error cases
>   cpuidle: reduce code duplication inside cpuidle_idle_call()
>   cpuidle: replace multiline statements with single line in
> cpuidle_idle_call()
>   cpuidle: call cpuidle_get_driver() from after taking
> cpuidle_driver_lock
>   cpuidle: use drv instead of cpuidle_driver in show_current_driver()
>   cpuidle: free all state kobjects from cpuidle_free_state_kobj()
>   cpuidle: don't calculate time-diff if entered_state < 0
>   cpuidle: don't call poll_idle_init() for every cpu
>   cpuidle: remove cpuidle_unregister_governor()

Hi Rafael,

Any chance this can get in 3.13 ??
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: lz4hc compression in UBIFS?

[Brent Taylor]

Konstantin,
   I did my testing with data from /dev/urandom (which I now realize
wasn't the best choice of data source), but if I use /dev/zero (which
actually causes data compression to occur), the decompressor fails.  I
don't know the internal workings of the lz4hc compressor or the lz4
decompressor.  I couldn't find any examples of any code in the kernel
actually using the compressor.  I've cc'ed the maintainers of the
lz4hc_compress.c to see if they my have some more insight to the
issue.

-- Brent

On Tue, Oct 22, 2013 at 5:10 AM, Konstantin Tokarev  wrote:
>
>
> 22.10.2013, 07:43, "Brent Taylor" :
>> On Mon, Oct 21, 2013 at 10:59 AM, Konstantin Tokarev  
>> wrote:
>>
>>>  04.10.2013, 07:09, "Brent Taylor" :
  Here is a patch based on linux-3.12-rc3.  I haven't performed any
  performance testing UBIFS using lz4hc, but I can mount UBIFS volumes
  and haven't seen any problems yet.  The only think I know that isn't
  correct about the patch is the description for the Kconfig element for
  select lz4hc as a compression option.  I only copied the description
  from the lzo description.
>>>  Hi Brent,
>>>
>>>  I'm testing your patch on my SH4 device. When I create new partition
>>>  with lz4hc compressor, it works fine: I can copy file into it, and
>>>  md5sums of original and copy match. However, after reboot I cannot
>>>  read the file anymore:
>>>
>>>  UBIFS error (pid 1101): ubifs_decompress: cannot decompress 934 bytes, 
>>> compressor lz4hc, error -22
>>>  UBIFS error (pid 1101): read_block: bad data node (block 1, inode 65)
>>>  UBIFS error (pid 1101): do_readpage: cannot read page 1 of inode 65, error 
>>> -22
>>>
>>>  The same error appears if I use lz4hc-compressed ubifs image to flash 
>>> rootfs
>>>  (using patched mkfs.ubifs).
>>>
>>>  Decompression error occurs in lz4_uncompress() function 
>>> (lib/lz4/lz4_decompress.c),
>>>  on the line 101:
>>>
>>>  /* Error: offset create reference outside destination buffer */
>>>  if (unlikely(ref < (BYTE *const) dest))
>>>  goto _output_error;
>>>
>>>  Brent: are you able to read data from lz4hc volume on your device?
>>>  Anyone: any ideas what may happen here?
>>>
>>>  --
>>>  Regards,
>>>  Konstantin
>>
>> Konstantin,
>>I haven't seen anything like that on my at91sam9m10g45-ek
>> development board.  I haven't used a flash image from mkfs.ubifs yet.
>> Is it possible the file system was not umounted cleanly before the
>> reboot and UBIFS went through a recovery procedure?  Maybe something
>> breaks with lz4hc when UBIFS does a recovery?  That's just a guess.
>
> Could you save attached file on lz4hc volume, umount it and mount again?
> I get aforementioned error when doing `cat set11.cfg`
>
> --
> Regards,
> Konstantin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 3/3] Documentation regarding perf/sdt

[Hemant Kumar]

This patch adds documentation for perf support to SDT notes/markers.

Signed-off-by: Hemant Kumar Shaw 
---
 tools/perf/Documentation/perf-probe.txt |   17 +++
 tools/perf/Documentation/sdt-probes.txt |  184 +++
 2 files changed, 199 insertions(+), 2 deletions(-)
 create mode 100644 tools/perf/Documentation/sdt-probes.txt

diff --git a/tools/perf/Documentation/perf-probe.txt 
b/tools/perf/Documentation/perf-probe.txt
index b715cb7..f0169d9 100644
--- a/tools/perf/Documentation/perf-probe.txt
+++ b/tools/perf/Documentation/perf-probe.txt
@@ -99,10 +99,15 @@ OPTIONS
 --max-probes::
Set the maximum number of probe points for an event. Default is 128.
 
+-M::
+--markers::
+   View the SDT markers present in a user space application/library.
+
 -x::
 --exec=PATH::
Specify path to the executable or shared library file for user
-   space tracing. Can also be used with --funcs option.
+   space tracing. Can also be used with --funcs option and must be used
+   with --markers/-M option.
 
 In absence of -m/-x options, perf probe checks if the first argument after
 the options is an absolute path name. If its an absolute path, perf probe
@@ -121,11 +126,15 @@ Probe points are defined by following syntax.
 3) Define event based on source file with lazy pattern
  [EVENT=]SRC;PTN [ARG ...]
 
+4) Define event based on SDT marker
+ [[EVENT=]%PROVIDER:MARKER
+
 
-'EVENT' specifies the name of new event, if omitted, it will be set the name 
of the probed function. Currently, event group name is set as 'probe'.
+'EVENT' specifies the name of new event, if omitted, it will be set the name 
of the probed function. Currently, event group name is set as 'probe' except in 
case of SDT markers where it is set to provider name.
 'FUNC' specifies a probed function name, and it may have one of the following 
options; '+OFFS' is the offset from function entry address in bytes, ':RLN' is 
the relative-line number from function entry line, and '%return' means that it 
probes function return. And ';PTN' means lazy matching pattern (see LAZY 
MATCHING). Note that ';PTN' must be the end of the probe point definition.  In 
addition, '@SRC' specifies a source file which has that function.
 It is also possible to specify a probe point by the source line number or lazy 
matching by using 'SRC:ALN' or 'SRC;PTN' syntax, where 'SRC' is the source file 
path, ':ALN' is the line number and ';PTN' is the lazy matching pattern.
 'ARG' specifies the arguments of this probe point, (see PROBE ARGUMENT).
+'%PROVIDER:MARKER' is the syntax of SDT markers present in an ELF.
 
 PROBE ARGUMENT
 --
@@ -200,6 +209,10 @@ Add probes at malloc() function on libc
 
  ./perf probe -x /lib/libc.so.6 malloc or ./perf probe /lib/libc.so.6 malloc
 
+Add probes at longjmp SDT marker on libc
+
+ ./perf probe -x /lib64/libc.so.6 %libc:longjmp
+
 SEE ALSO
 
 linkperf:perf-trace[1], linkperf:perf-record[1]
diff --git a/tools/perf/Documentation/sdt-probes.txt 
b/tools/perf/Documentation/sdt-probes.txt
new file mode 100644
index 000..d5556b7
--- /dev/null
+++ b/tools/perf/Documentation/sdt-probes.txt
@@ -0,0 +1,184 @@
+Perf probing on SDT markers:
+
+Goal:
+Probe dtrace style markers(SDT) present in user space applications.
+
+Scope:
+Put probe points at SDT markers in user space applications and libraries
+and also probe them using perf.
+
+Why supprt SDT markers? :
+We have lots of applications which use SDT markers today like:
+Postgresql, MySql, Mozilla, Perl, Python, Java, Ruby, libvirt, QEMU, glib
+
+These markers are placed at important places by the developers. Now, these
+markers have a negligible overhead when not enabled. We can enable them
+and probe at these places and find some important information like the
+arguments' values, etc.
+
+How to add SDT markers into user applications:
+We need to have this header sys/sdt.h present.
+sys/sdt.h used is version 3.
+If not present, install systemtap-sdt-devel package.
+
+A very simple example:
+
+$ cat user_app.c
+
+#include 
+
+void main () {
+   /* ... */
+   /* 
+* user_app is the provider name
+   * test_probe is the marker name
+   */
+   STAP_PROBE(user_app, test_mark);
+   /* ... */
+}
+
+$ gcc user_app.c
+$ perf probe -M -x ./a.out
+%user_app:test_mark
+
+A different example to show the same:
+- Create a file with .d extension and mention the probe names in it with
+provider name and marker name.
+
+$ cat probes.d
+provider user_app {
+ probe foo_start();
+ probe fun_start();
+};
+
+- Now create the probes.h and probes.o file :
+$ dtrace -C -h -s probes.d -o probes.h
+$ dtrace -C -G -s probes.d -o probes.o
+
+- A program using the markers:
+
+$ cat user_app.c
+
+#include 
+#include "probes.h"
+
+void foo(void)
+{
+USER_APP_FOO_START();
+printf("This is foo\n");
+}
+
+void fun(void)
+{
+USER_APP_FUN_START();
+printf("Inside fun\n");

[PATCH v4 2/3] Support for perf to probe into SDT markers:

[Hemant Kumar]

This allows perf to probe into the sdt markers/notes present in
the libraries and executables. We try to find the associated location
and handle prelinking (since, stapsdt notes section is not allocated
during runtime). Prelinking is handled with the help of base
section which is allocated during runtime. This address can be compared
with the address retrieved from the notes' description. If its different,
we can take this difference and then add to the note's location.

We can use existing '-a/--add' option to add events for sdt markers.
Also, we can add multiple events at once using the same '-a' option.

Usage:
perf probe -x /lib64/libc.so.6 -a 'my_event=%libc:setjmp'

Output:
Added new event:
  libc:my_event(on 0x35981)

You can now use it in all perf tools, such as:

perf record -e libc:my_event -aR sleep 1


Signed-off-by: Hemant Kumar Shaw 
---
 tools/perf/builtin-probe.c|4 ++
 tools/perf/util/probe-event.c |  102 +
 tools/perf/util/probe-event.h |2 +
 tools/perf/util/symbol-elf.c  |   84 ++
 tools/perf/util/symbol.h  |5 ++
 5 files changed, 187 insertions(+), 10 deletions(-)

diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index 2450613..8f0dd48 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -494,6 +494,10 @@ int cmd_probe(int argc, const char **argv, const char 
*prefix __maybe_unused)
}
 
if (params.nevents) {
+   if (params.events->sdt && !params.target && !params.exec) {
+   pr_err("SDT markers can be probed only with --exec.\n");
+   usage_with_options(probe_usage, options);
+   }
ret = add_perf_probe_events(params.events, params.nevents,
params.max_probe_points,
params.target,
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 19182f7..508c7a2 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -816,6 +816,40 @@ static int parse_perf_probe_point(char *arg, struct 
perf_probe_event *pev)
pev->group = NULL;
arg = tmp;
}
+   /* Check for SDT marker */
+   if (*arg == '%') {
+   ptr = strchr(++arg, ':');
+   if (!ptr) {
+   semantic_error("Provider name must follow an event "
+  "name\n");
+   return -EINVAL;
+   }
+   *ptr++ = '\0';
+   tmp = strdup(arg);
+   if (!tmp)
+   return -ENOMEM;
+
+   pev->point.note = (struct sdt_note *)
+   zalloc(sizeof(struct sdt_note));
+   if (!pev->point.note) {
+   free(tmp);
+   return -ENOMEM;
+   }
+   pev->point.note->provider = tmp;
+
+   tmp = strdup(ptr);
+   if (!tmp) {
+   free(pev->point.note->provider);
+   free(pev->point.note);
+   return -ENOMEM;
+   }
+   pev->point.note->name = tmp;
+   pev->group = pev->point.note->provider;
+   if (!pev->event)
+   pev->event = pev->point.note->name;
+   pev->sdt = true;
+   return 0;
+   }
 
ptr = strpbrk(arg, ";:+@%");
if (ptr) {
@@ -1238,6 +1272,7 @@ static char *synthesize_perf_probe_point(struct 
perf_probe_point *pp)
char *buf, *tmp;
char offs[32] = "", line[32] = "", file[32] = "";
int ret, len;
+   unsigned long long addr;
 
buf = zalloc(MAX_CMDLEN);
if (buf == NULL) {
@@ -1266,12 +1301,16 @@ static char *synthesize_perf_probe_point(struct 
perf_probe_point *pp)
goto error;
}
 
-   if (pp->function)
+   if (pp->function) {
ret = e_snprintf(buf, MAX_CMDLEN, "%s%s%s%s%s", pp->function,
 offs, pp->retprobe ? "%return" : "", line,
 file);
-   else
+   } else if (pp->note) {
+   addr = get_sdt_note_addr(pp->note);
+   ret = e_snprintf(buf, MAX_CMDLEN, "0x%llx", addr);
+   } else {
ret = e_snprintf(buf, MAX_CMDLEN, "%s%s", file, line);
+   }
if (ret <= 0)
goto error;
 
@@ -1909,6 +1948,26 @@ static int __add_probe_trace_events(struct 
perf_probe_event *pev,
return ret;
 }
 
+static int try_to_find_sdt_notes(struct perf_probe_event *pev,
+const char *target)
+{
+   struct sdt_note *note = pev->point.note;
+   int ret;
+
+   ret = search_sdt_note(note, target);
+   if (!ret) {
+   if (note->bit32 && 

[PATCH v4 1/3] SDT markers listing by perf:

[Hemant Kumar]

This patch will enable perf to list all the sdt markers present
in an elf file. The markers are present in the .note.stapsdt section
of the elf. We can traverse through this section and collect the
required info about the markers.
We can use '-M/--markers' with perf to view the SDT notes.

Currently, the sdt notes which have their semaphores enabled, are being
ignored silently. But, they will be supported soon.

Wrapping this inside #ifdef LIBELF_SUPPORT pair is not required,
because, if NO_LIBELF = 1, then 'probe' command of perf is itself disabled.

Usage:
perf probe --markers -x /lib64/libc.so.6

Output :
%libc:setjmp
%libc:longjmp
%libc:longjmp_target
%libc:lll_futex_wake
%libc:lll_lock_wait_private
%libc:longjmp
%libc:longjmp_target
%libc:lll_futex_wake

Signed-off-by: Hemant Kumar Shaw 
---
 tools/perf/builtin-probe.c|   41 +++
 tools/perf/util/probe-event.c |   23 
 tools/perf/util/probe-event.h |1 
 tools/perf/util/symbol-elf.c  |  225 +
 tools/perf/util/symbol.h  |   19 +++
 5 files changed, 307 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-probe.c b/tools/perf/builtin-probe.c
index 89acc17..2450613 100644
--- a/tools/perf/builtin-probe.c
+++ b/tools/perf/builtin-probe.c
@@ -55,6 +55,8 @@ static struct {
bool show_funcs;
bool mod_events;
bool uprobes;
+   bool exec;
+   bool sdt;
int nevents;
struct perf_probe_event events[MAX_PROBES];
struct strlist *dellist;
@@ -171,8 +173,10 @@ static int opt_set_target(const struct option *opt, const 
char *str,
int ret = -ENOENT;
 
if  (str && !params.target) {
-   if (!strcmp(opt->long_name, "exec"))
+   if (!strcmp(opt->long_name, "exec")) {
params.uprobes = true;
+   params.exec = true;
+   }
 #ifdef HAVE_DWARF_SUPPORT
else if (!strcmp(opt->long_name, "module"))
params.uprobes = false;
@@ -325,6 +329,7 @@ int cmd_probe(int argc, const char **argv, const char 
*prefix __maybe_unused)
 opt_set_filter),
OPT_CALLBACK('x', "exec", NULL, "executable|path",
"target executable name or path", opt_set_target),
+   OPT_BOOLEAN('M', "markers", , "Show proba-able sdt notes"),
OPT_END()
};
int ret;
@@ -347,7 +352,7 @@ int cmd_probe(int argc, const char **argv, const char 
*prefix __maybe_unused)
params.max_probe_points = MAX_PROBES;
 
if ((!params.nevents && !params.dellist && !params.list_events &&
-!params.show_lines && !params.show_funcs))
+!params.show_lines && !params.show_funcs && !params.sdt))
usage_with_options(probe_usage, options);
 
/*
@@ -355,6 +360,38 @@ int cmd_probe(int argc, const char **argv, const char 
*prefix __maybe_unused)
 */
symbol_conf.try_vmlinux_path = (symbol_conf.vmlinux_name == NULL);
 
+   if (params.sdt) {
+   if (params.show_lines) {
+   pr_err("Error: Don't use --markers with --lines.\n");
+   usage_with_options(probe_usage, options);
+   }
+   if (params.show_vars) {
+   pr_err("Error: Don't use --markers with --vars.\n");
+   usage_with_options(probe_usage, options);
+   }
+   if (params.show_funcs) {
+   pr_err("Error: Don't use --markers with --funcs.\n");
+   usage_with_options(probe_usage, options);
+   }
+   if (params.mod_events) {
+   pr_err("Error: Don't use --markers with 
--add/--del.\n");
+   usage_with_options(probe_usage, options);
+   }
+   if (!params.exec) {
+   pr_err("Error: Always use --exec with --markers.\n");
+   usage_with_options(probe_usage, options);
+   }
+   if (!params.target) {
+   pr_err("Error: Please specify a target binary!\n");
+   usage_with_options(probe_usage, options);
+   }
+   ret = show_sdt_notes(params.target);
+   if (ret < 0) {
+   pr_err("  Error : Failed to find SDT markers in %s !"
+  " (%d)\n", params.target, ret);
+   }
+   return ret;
+   }
if (params.list_events) {
if (params.mod_events) {
pr_err("  Error: Don't use --list with --add/--del.\n");
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 779b2da..19182f7 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -2372,3 +2372,26 @@ out:
free(name);
return ret;
 }
+
+static void 

[PATCH v4 0/3] perf support to SDT markers

[Hemant Kumar]

This patchset helps in probing dtrace style markers(SDT) present in user space
applications through perf. Notes/markers are placed at important places by the
developers. They have a negligible overhead when not enabled. We can enable
them and probe at these places and find some important information like the
arguments' values, etc.

How to add SDT markers into user applications:
We need to have this header sys/sdt.h present.
sys/sdt.h used is version 3.
If not present, install systemtap-sdt-devel package (for fedora-18).

A very simple example to show this :
$ cat user_app.c

#include 

void main () {
   /* ... */
   /*
* user_app is the provider name
* test_probe is the marker name
*/
   STAP_PROBE(user_app, test_mark);
   /* ... */
}

$ gcc user_app.c
$ perf probe -M -x ./a.out
%user_app:test_mark

A different example to show the same :
- Create a file with .d extension and mention the probe names in it with
provider name and marker name.

$ cat probes.d
provider user_app {
 probe foo_start();
 probe fun_start();
};

- Now create the probes.h and probes.o file :
$ dtrace -C -h -s probes.d -o probes.h
$ dtrace -C -G -s probes.d -o probes.o

- A program using the markers:

$ cat user_app.c

#include 
#include "probes.h"

void foo(void)
{
USER_APP_FOO_START();
printf("This is foo\n");
}

void fun(void)
{
USER_APP_FUN_START();
printf("Inside fun\n");
}
int main(void)
{
printf("In main\n");
foo();
fun();
return 0;
}

- Compile it and also provide probes.o file to linker:
$ gcc user_app.c probes.o -o user_app

- Now use perf to list the markers in the app:
# perf probe --markers -x ./user_app

%user_app:foo_start
%user_app:fun_start

- And  then use perf probe to add a probe point :

# perf probe -x ./user_app -a '%user_app:foo_start'

Added new event :
event = foo_start  (on 0x530)

You can now use it on all perf tools such as :

 perf record -e user_app:foo_start -aR sleep 1

# perf record -e user_app:foo_start -aR ./user_app
In main
This is foo
Inside fun
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.235 MB perf.data (~10279 samples) ]

- Then use perf tools to analyze it.
# perf report --stdio

# 
# captured on: Tue Sep  3 16:19:55 2013
# hostname : hemant-fedora
# os release : 3.11.0-rc3+
# perf version : 3.9.4-200.fc18.x86_64
# arch : x86_64
# nrcpus online : 2
# nrcpus avail : 2
# cpudesc : QEMU Virtual CPU version 1.2.2
# cpuid : GenuineIntel,6,2,3
# total memory : 2051912 kBIf these are not enabled, they are present in the \
ELF as nop.

# cmdline : /usr/bin/perf record -e probe_user:foo_start -aR ./user_app
# event : name = probe_user:foo_start, type = 2, config = 0x38e, config1
= 0x0, config2 = 0x0, excl_usr = 0, excl_kern = 0, excl_host = 0,
excl_guest = 1, precise_ip = 0
# HEADER_CPU_TOPOLOGY info available, use -I to display
# HEADER_NUMA_TOPOLOGY info available, use -I to display
# pmu mappings: software = 1, tracepoint = 2, breakpoint = 5
# 
#
# Samples: 1  of event 'probe_user:foo_start'
# Event count (approx.): 1
#
# Overhead   Command  Shared Object   Symbol
#     .  ...
#
   100.00%  user_app  user_app   [.] foo


#
# (For a higher level overview, try: perf report --sort comm,dso)
#

We can see and probe the existing markers in libc (if present) :
$ perf probe --markers -x /lib64/libc.so.6

%libc:setjmp
%libc:longjmp
%libc:longjmp_target
%libc:lll_futex_wake
%libc:lll_lock_wait_private
%libc:longjmp
%libc:longjmp_target
%libc:lll_futex_wake

This link shows an example of marker probing with Systemtap:
https://sourceware.org/systemtap/wiki/AddingUserSpaceProbingToApps

Also, this link provides important info regarding SDT notes:
http://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation

- Markers in binaries :
These SDT markers are present in the ELF in the section named
".note.stapsdt".
Here, the name of the marker, its provider, type, location, base
address, semaphore address.
We can retrieve these values using the members name_off and desc_off in
Nhdr structure. If these are not enabled, they are present in the ELF as nop.

All the above info is moved in sdt-probes.txt file present in the Documentation
directory in tools/perf/.

Changes since last version:
- The interface search_sdt_note() has been changed and 'list' argument has been
  removed.
- list_empty() check is now done in print_sdt_note_info() and
  cleanup_sdt_note_info().
- Some small improvements have been made.

TODO:
- Recognizing arguments and support to probe on them.
---

Hemant Kumar (3):
  SDT markers listing by perf:
  Support for perf to probe into SDT markers:
  Documentation regarding perf/sdt


 tools/perf/Documentation/perf-probe.txt |   17 ++
 tools/perf/Documentation/sdt-probes.txt |  184 ++
 tools/perf/builtin-probe.c  |   45 -
 

[PATCH] x86, procfs: remove condition for show_cpuinfo_core()

[HATAYAMA Daisuke]

show_cpuinfo_core() has displayed cpu core information only if the
number of threads per a whole cores is strictly larger than 1. But
this condition doesn't care about the number of sockets. This doesn't
cover, for example, the system with two logical cpus consisting of two
sockets and a single core on each socket.

However, this information is useful even if there's only 1 thread. So,
how to fix it here is to simply remove the condition, instead of
fixing the condition.

Signed-off-by: HATAYAMA Daisuke 
---
 arch/x86/kernel/cpu/proc.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
index aee6317..06fe3ed 100644
--- a/arch/x86/kernel/cpu/proc.c
+++ b/arch/x86/kernel/cpu/proc.c
@@ -11,15 +11,12 @@ static void show_cpuinfo_core(struct seq_file *m, struct 
cpuinfo_x86 *c,
  unsigned int cpu)
 {
 #ifdef CONFIG_SMP
-   if (c->x86_max_cores * smp_num_siblings > 1) {
-   seq_printf(m, "physical id\t: %d\n", c->phys_proc_id);
-   seq_printf(m, "siblings\t: %d\n",
-  cpumask_weight(cpu_core_mask(cpu)));
-   seq_printf(m, "core id\t\t: %d\n", c->cpu_core_id);
-   seq_printf(m, "cpu cores\t: %d\n", c->booted_cores);
-   seq_printf(m, "apicid\t\t: %d\n", c->apicid);
-   seq_printf(m, "initial apicid\t: %d\n", c->initial_apicid);
-   }
+   seq_printf(m, "physical id\t: %d\n", c->phys_proc_id);
+   seq_printf(m, "siblings\t: %d\n", cpumask_weight(cpu_core_mask(cpu)));
+   seq_printf(m, "core id\t\t: %d\n", c->cpu_core_id);
+   seq_printf(m, "cpu cores\t: %d\n", c->booted_cores);
+   seq_printf(m, "apicid\t\t: %d\n", c->apicid);
+   seq_printf(m, "initial apicid\t: %d\n", c->initial_apicid);
 #endif
 }
 
-- 
1.8.3.1


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] f2fs: use bool for booleans

[Haicheng Li]

Signed-off-by: Haicheng Li 
---
 fs/f2fs/checkpoint.c |4 ++--
 fs/f2fs/f2fs.h   |4 ++--
 fs/f2fs/node.c   |4 ++--
 fs/f2fs/recovery.c   |8 
 fs/f2fs/super.c  |2 +-
 5 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 8d16071..bd0aa9c 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -279,7 +279,7 @@ int recover_orphan_inodes(struct f2fs_sb_info *sbi)
if (!is_set_ckpt_flags(F2FS_CKPT(sbi), CP_ORPHAN_PRESENT_FLAG))
return 0;
 
-   sbi->por_doing = 1;
+   sbi->por_doing = true;
start_blk = __start_cp_addr(sbi) + 1;
orphan_blkaddr = __start_sum_addr(sbi) - 1;
 
@@ -296,7 +296,7 @@ int recover_orphan_inodes(struct f2fs_sb_info *sbi)
}
/* clear Orphan Flag */
clear_ckpt_flags(F2FS_CKPT(sbi), CP_ORPHAN_PRESENT_FLAG);
-   sbi->por_doing = 0;
+   sbi->por_doing = false;
return 0;
 }
 
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 171c52f..2b163f8 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -360,8 +360,8 @@ struct f2fs_sb_info {
struct rw_semaphore cp_rwsem;   /* blocking FS operations */
struct mutex node_write;/* locking node writes */
struct mutex writepages;/* mutex for writepages() */
-   int por_doing;  /* recovery is doing or not */
-   int on_build_free_nids; /* build_free_nids is doing */
+   bool por_doing; /* recovery is doing or not */
+   bool on_build_free_nids;/* build_free_nids is doing */
struct task_struct *cp_task;/* checkpoint task */
 
/* for orphan inode management */
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index ef80f79..f90485b 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1444,9 +1444,9 @@ retry:
 
/* Let's scan nat pages and its caches to get free nids */
mutex_lock(_i->build_lock);
-   sbi->on_build_free_nids = 1;
+   sbi->on_build_free_nids = true;
build_free_nids(sbi);
-   sbi->on_build_free_nids = 0;
+   sbi->on_build_free_nids = false;
mutex_unlock(_i->build_lock);
goto retry;
 }
diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
index 353cf4f..b278c68 100644
--- a/fs/f2fs/recovery.c
+++ b/fs/f2fs/recovery.c
@@ -425,7 +425,7 @@ int recover_fsync_data(struct f2fs_sb_info *sbi)
 {
struct list_head inode_list;
int err;
-   int need_writecp = 0;
+   bool need_writecp = false;
 
fsync_entry_slab = f2fs_kmem_cache_create("f2fs_fsync_inode_entry",
sizeof(struct fsync_inode_entry), NULL);
@@ -435,7 +435,7 @@ int recover_fsync_data(struct f2fs_sb_info *sbi)
INIT_LIST_HEAD(_list);
 
/* step #1: find fsynced inode numbers */
-   sbi->por_doing = 1;
+   sbi->por_doing = true;
err = find_fsync_dnodes(sbi, _list);
if (err)
goto out;
@@ -443,7 +443,7 @@ int recover_fsync_data(struct f2fs_sb_info *sbi)
if (list_empty(_list))
goto out;
 
-   need_writecp = 1;
+   need_writecp = true;
 
/* step #2: recover data */
err = recover_data(sbi, _list, CURSEG_WARM_NODE);
@@ -451,7 +451,7 @@ int recover_fsync_data(struct f2fs_sb_info *sbi)
 out:
destroy_fsync_dnodes(_list);
kmem_cache_destroy(fsync_entry_slab);
-   sbi->por_doing = 0;
+   sbi->por_doing = false;
if (!err && need_writecp)
write_checkpoint(sbi, false);
return err;
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 692f35f..9a09459 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -850,7 +850,7 @@ static int f2fs_fill_super(struct super_block *sb, void 
*data, int silent)
mutex_init(>writepages);
mutex_init(>cp_mutex);
mutex_init(>node_write);
-   sbi->por_doing = 0;
+   sbi->por_doing = false;
spin_lock_init(>stat_lock);
init_rwsem(>bio_sem);
init_rwsem(>cp_rwsem);
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: -27% netperf TCP_STREAM regression by "tcp_memcontrol: Kill struct tcp_memcontrol"

[Eric W. Biederman]

David Miller  writes:

> From: fengguang...@intel.com
> Date: Tue, 22 Oct 2013 22:41:29 +0100
>
>> We noticed big netperf throughput regressions
>> 
>> a4fe34bf902b8f709c63  2e685cad57906e19add7  
>>     
>>   707.40   -40.7%   419.60  
>> lkp-nex04/micro/netperf/120s-200%-TCP_STREAM
>>  2775.60   -23.7%  2116.40  
>> lkp-sb03/micro/netperf/120s-200%-TCP_STREAM
>>  3483.00   -27.2%  2536.00  TOTAL 
>> netperf.Throughput_Mbps
>> 
>> and bisected it to
>> 
>> commit 2e685cad57906e19add7189b5ff49dfb6aaa21d3
>> Author: Eric W. Biederman 
>> Date:   Sat Oct 19 16:26:19 2013 -0700
>> 
>> tcp_memcontrol: Kill struct tcp_memcontrol
>
> Eric please look into this, I'd rather have a fix to apply than revert your
> work.

Will do I expect some ordering changed, and that changed the cache line
behavior.

If I can't find anything we can revert this one particular patch without
affecting anything else, but it would be nice to keep the data structure
smaller.

Fengguag what would I need to do to reproduce this?

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 Resend 13/34] cpufreq: ia64: Convert to light weight ->target_index() routine

[Viresh Kumar]

On 22 October 2013 22:02, Luck, Tony  wrote:
>> This patch converts existing .target() to newly defined light weight
>> .target_index() routine for this driver.
>>
>> CPUFreq core will call cpufreq_frequency_table_target() before calling this
>> routine and will pass index to it.
>>
>> Cc: Tony Luck 
>> Signed-off-by: Viresh Kumar 
>
> Tested-by: Tony Luck 

Thanks Tony..

@Rafael: Count this Tested-by for 1/34 and 31/34 as he actually
tested both :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: Ensure get_unmapped_area() returns higher addressthan mmap_min_addr

[Naoya Horiguchi]

Hi,

On Wed, Oct 23, 2013 at 11:46:53AM +0900, Akira Takeuchi wrote:
> This patch fixes the problem that get_unmapped_area() can return illegal
> address and result in failing mmap(2) etc.
> 
> In case that the address higher than PAGE_SIZE is set to
> /proc/sys/vm/mmap_min_addr, the address lower than mmap_min_addr can be
> returned by get_unmapped_area(), even if you do not pass any virtual
> address hint (i.e. the second argument).
> 
> This is because the current get_unmapped_area() code does not take into
> account mmap_min_addr.
> 
> This leads to two actual problems as follows:
> 
> 1. mmap(2) can fail with EPERM on the process without CAP_SYS_RAWIO,
>although any illegal parameter is not passed.
> 
> 2. The bottom-up search path after the top-down search might not work in
>arch_get_unmapped_area_topdown().
> 
> [How to reproduce]
> 
>   --- test.c -
>   #include 
>   #include 
>   #include 
>   #include 
> 
>   int main(int argc, char *argv[])
>   {
>   void *ret = NULL, *last_map;
>   size_t pagesize = sysconf(_SC_PAGESIZE);
> 
>   do {
>   last_map = ret;
>   ret = mmap(0, pagesize, PROT_NONE,
>   MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
>   //  printf("ret=%p\n", ret);
>   } while (ret != MAP_FAILED);
> 
>   if (errno != ENOMEM) {
>   printf("ERR: unexpected errno: %d (last map=%p)\n",
>   errno, last_map);
>   }
> 
>   return 0;
>   }
>   ---
> 
>   $ gcc -m32 -o test test.c
>   $ sudo sysctl -w vm.mmap_min_addr=65536
>   vm.mmap_min_addr = 65536
>   $ ./test  (run as non-priviledge user)
>   ERR: unexpected errno: 1 (last map=0x1)
> 
> Signed-off-by: Akira Takeuchi 
> Signed-off-by: Kiyoshi Owada 
> ---
>  mm/mmap.c |   10 +-
>  1 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 9d54851..362e5f1 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1856,7 +1856,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long 
> addr,
>   struct vm_area_struct *vma;
>   struct vm_unmapped_area_info info;
>  
> - if (len > TASK_SIZE)
> + if (len > TASK_SIZE - mmap_min_addr)
>   return -ENOMEM;
>  
>   if (flags & MAP_FIXED)

I feel that it looks clearer to fix this in round_hint_to_min(),
with doing mmap_min_addr check in hint == NULL case.
Does it work for you?

Thanks,
Naoya Horiguchi

> @@ -1865,7 +1865,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long 
> addr,
>   if (addr) {
>   addr = PAGE_ALIGN(addr);
>   vma = find_vma(mm, addr);
> - if (TASK_SIZE - len >= addr &&
> + if (TASK_SIZE - len >= addr && addr >= mmap_min_addr &&
>   (!vma || addr + len <= vma->vm_start))
>   return addr;
>   }
> @@ -1895,7 +1895,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const 
> unsigned long addr0,
>   struct vm_unmapped_area_info info;
>  
>   /* requested length too big for entire address space */
> - if (len > TASK_SIZE)
> + if (len > TASK_SIZE - mmap_min_addr)
>   return -ENOMEM;
>  
>   if (flags & MAP_FIXED)
> @@ -1905,14 +1905,14 @@ arch_get_unmapped_area_topdown(struct file *filp, 
> const unsigned long addr0,
>   if (addr) {
>   addr = PAGE_ALIGN(addr);
>   vma = find_vma(mm, addr);
> - if (TASK_SIZE - len >= addr &&
> + if (TASK_SIZE - len >= addr && addr >= mmap_min_addr &&
>   (!vma || addr + len <= vma->vm_start))
>   return addr;
>   }
>  
>   info.flags = VM_UNMAPPED_AREA_TOPDOWN;
>   info.length = len;
> - info.low_limit = PAGE_SIZE;
> + info.low_limit = max(PAGE_SIZE, mmap_min_addr);
>   info.high_limit = mm->mmap_base;
>   info.align_mask = 0;
>   addr = vm_unmapped_area();
> -- 
> 1.7.0.4
> 
> 
> -- 
> Akira Takeuchi 
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] sched: Fix nohz_kick_needed to consider the nr_busy of the parent domain's group

[Preeti U Murthy]

On 10/23/2013 09:30 AM, Preeti U Murthy wrote:
> Hi Peter,
> 
> On 10/23/2013 03:41 AM, Peter Zijlstra wrote:
>> On Mon, Oct 21, 2013 at 05:14:42PM +0530, Vaidyanathan Srinivasan wrote:
>>>  kernel/sched/fair.c |   19 +--
>>>  1 file changed, 13 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>>> index 7c70201..12f0eab 100644
>>> --- a/kernel/sched/fair.c
>>> +++ b/kernel/sched/fair.c
>>> @@ -5807,12 +5807,19 @@ static inline int nohz_kick_needed(struct rq *rq, 
>>> int cpu)
>>>  
>>> rcu_read_lock();
>>> for_each_domain(cpu, sd) {
>>> +   struct sched_domain *sd_parent = sd->parent;
>>> +   struct sched_group *sg;
>>> +   struct sched_group_power *sgp;
>>> +   int nr_busy;
>>> +
>>> +   if (sd_parent) {
>>> +   sg = sd_parent->groups;
>>> +   sgp = sg->sgp;
>>> +   nr_busy = atomic_read(>nr_busy_cpus);
>>> +
>>> +   if (sd->flags & SD_SHARE_PKG_RESOURCES && nr_busy > 1)
>>> +   goto need_kick_unlock;
>>> +   }
>>>  
>>> if (sd->flags & SD_ASYM_PACKING && nr_busy != sg->group_weight
>>> && (cpumask_first_and(nohz.idle_cpus_mask,
>>>
>>
>> Almost I'd say; what happens on !sd_parent && SD_ASYM_PACKING ?
> 
> You are right, sorry about this. The idea was to correct the nr_busy
> computation before the patch that would remove its usage in the second
> patch. But that would mean the condition nr_busy != sg->group_weight
> would be invalid with this patch. The second patch needs to go first to
> avoid this confusion.
> 
>>
>> Also, this made me look at the nr_busy stuff again, and somehow that
>> entire thing makes me a little sad.
>>
>> Can't we do something like the below and cut that nr_busy sd iteration
>> short?
> 
> We can surely cut the nr_busy sd iteration but not like what is done
> with this patch. You stop the nr_busy computation at the sched domain
> that has the flag SD_SHARE_PKG_RESOURCES set. But nohz_kick_needed()
> would want to know the nr_busy for one level above this.
>Consider a core. Assume it is the highest domain with this flag set.
> The nr_busy of its groups, which are logical threads are set to 1/0
> each. But nohz_kick_needed() would like to know the sum of the nr_busy
> parameter of all the groups, i.e. the threads in a core before it
> decides if it can kick nohz_idle balancing. The information about the
> individual group's nr_busy is of no relevance here.
> 
> Thats why the above patch tries to get the
> sd->parent->groups->sgp->nr_busy_cpus. This will translate rightly to
> the core's busy cpus in this example. But the below patch stops before
> updating this parameter at the sd->parent level, where sd is the highest
> level sched domain with the SD_SHARE_PKG_RESOURCES flag set.
> 
> But we can get around all this confusion if we can move the nr_busy
> parameter to be included in the sched_domain structure rather than the
> sched_groups_power structure. Anyway the only place where nr_busy is
> used, that is at nohz_kick_needed(), is done to know the total number of
> busy cpus at a sched domain level which has the SD_SHARE_PKG_RESOURCES
> set and not at a sched group level.
> 
> So why not move nr_busy to struct sched_domain  and having the below
> patch which just updates this parameter for the sched domain, sd_busy ?

Oh this can't be done :( Domain structures are per cpu!

Regards
Preeti U Murthy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/4] CPUFreq stats: Bug fixes

[Viresh Kumar]

On 23 October 2013 02:36, Nicolas Pitre  wrote:
> My testing of those patches took a long and winding path but finally I
> was able to do it today.
>
> So for the 4 patches:
>
> Tested-by: Nicolas Pitre 
> Acked-by: Nicolas Pitre 

Ahh.. Thanks Nico.. that would be pretty helpful :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] firmware, fix request_firmware_nowait() freeze with no uevent

[Ming Lei]

On Wed, Oct 23, 2013 at 7:15 AM, Prarit Bhargava  wrote:
> On 10/21/2013 10:35 PM, Ming Lei wrote:
>>
>> That is why NOHOTPLUG isn't encouraged to be taken, actually
>> I don't suggest you to do that too, :-)
> Okay ... I can certainly switch to HOTPLUG.

OK, that should be the right approach.

>
>>
>> You need to make sure your approach won't break micro-code
>> update application in current/previous distributions.
>
> I've tested the following distributions today on a Dell PE 1850:  Ubuntu, 
> SuSe,
> Linux Mint, and of course Fedora.  I do not see any issues with either the
> microcode update or the dell_rbu driver.  Unfortunately I do not have access 
> to

Actually I am wondering if your tests are enough because kernel
can't break user-space, which means lots of previous old version
distributions should surely be covered, :-)

If you keep HOTPLUG, only change to request_firmware_nowait(),
that should be OK since the loading protocol between userspace and
kernel won't change wrt. microcode updating.

> a system that uses the lattice-ecp3-config, however, from code inspection it
> looks like the driver looks at a specific place for the FW update and then
> applies it via the call function in request_firmware_nowait() so it looks like
> it is solid too.
>
> I think maybe this patchset should be split into two separate submits, one for
> the microcode and the second to figure out if the code really should wait
> indefinitely.  AFAICT neither use case in the kernel expects an indefinite 
> wait.

If you switch to HOTPLUG, you needn't worry about waiting indefinitely,
need you?

Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] sched: Fix nohz_kick_needed to consider the nr_busy of the parent domain's group

[Preeti U Murthy]

Hi Peter,

On 10/23/2013 03:41 AM, Peter Zijlstra wrote:
> On Mon, Oct 21, 2013 at 05:14:42PM +0530, Vaidyanathan Srinivasan wrote:
>>  kernel/sched/fair.c |   19 +--
>>  1 file changed, 13 insertions(+), 6 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 7c70201..12f0eab 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -5807,12 +5807,19 @@ static inline int nohz_kick_needed(struct rq *rq, 
>> int cpu)
>>  
>>  rcu_read_lock();
>>  for_each_domain(cpu, sd) {
>> +struct sched_domain *sd_parent = sd->parent;
>> +struct sched_group *sg;
>> +struct sched_group_power *sgp;
>> +int nr_busy;
>> +
>> +if (sd_parent) {
>> +sg = sd_parent->groups;
>> +sgp = sg->sgp;
>> +nr_busy = atomic_read(>nr_busy_cpus);
>> +
>> +if (sd->flags & SD_SHARE_PKG_RESOURCES && nr_busy > 1)
>> +goto need_kick_unlock;
>> +}
>>  
>>  if (sd->flags & SD_ASYM_PACKING && nr_busy != sg->group_weight
>>  && (cpumask_first_and(nohz.idle_cpus_mask,
>>
> 
> Almost I'd say; what happens on !sd_parent && SD_ASYM_PACKING ?

You are right, sorry about this. The idea was to correct the nr_busy
computation before the patch that would remove its usage in the second
patch. But that would mean the condition nr_busy != sg->group_weight
would be invalid with this patch. The second patch needs to go first to
avoid this confusion.

> 
> Also, this made me look at the nr_busy stuff again, and somehow that
> entire thing makes me a little sad.
> 
> Can't we do something like the below and cut that nr_busy sd iteration
> short?

We can surely cut the nr_busy sd iteration but not like what is done
with this patch. You stop the nr_busy computation at the sched domain
that has the flag SD_SHARE_PKG_RESOURCES set. But nohz_kick_needed()
would want to know the nr_busy for one level above this.
   Consider a core. Assume it is the highest domain with this flag set.
The nr_busy of its groups, which are logical threads are set to 1/0
each. But nohz_kick_needed() would like to know the sum of the nr_busy
parameter of all the groups, i.e. the threads in a core before it
decides if it can kick nohz_idle balancing. The information about the
individual group's nr_busy is of no relevance here.

Thats why the above patch tries to get the
sd->parent->groups->sgp->nr_busy_cpus. This will translate rightly to
the core's busy cpus in this example. But the below patch stops before
updating this parameter at the sd->parent level, where sd is the highest
level sched domain with the SD_SHARE_PKG_RESOURCES flag set.

But we can get around all this confusion if we can move the nr_busy
parameter to be included in the sched_domain structure rather than the
sched_groups_power structure. Anyway the only place where nr_busy is
used, that is at nohz_kick_needed(), is done to know the total number of
busy cpus at a sched domain level which has the SD_SHARE_PKG_RESOURCES
set and not at a sched group level.

So why not move nr_busy to struct sched_domain  and having the below
patch which just updates this parameter for the sched domain, sd_busy ?
This will avoid iterating through all the levels of sched domains and
should resolve the scalability issue. We also don't need to get to
sd->parent to get the nr_busy parameter for the sake of nohz_kick_needed().

What do you think?

Regards
Preeti U Murthy
> 
> This nohz stuff really needs to be re-thought and made more scalable --
> its a royal pain :/
> 
> 
>  kernel/sched/core.c  |  4 
>  kernel/sched/fair.c  | 21 +++--
>  kernel/sched/sched.h |  5 ++---
>  3 files changed, 21 insertions(+), 9 deletions(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index c06b8d3..89db8dc 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -5271,6 +5271,7 @@ DEFINE_PER_CPU(struct sched_domain *, sd_llc);
>  DEFINE_PER_CPU(int, sd_llc_size);
>  DEFINE_PER_CPU(int, sd_llc_id);
>  DEFINE_PER_CPU(struct sched_domain *, sd_numa);
> +DEFINE_PER_CPU(struct sched_domain *, sd_busy);
> 
>  static void update_top_cache_domain(int cpu)
>  {
> @@ -5290,6 +5291,9 @@ static void update_top_cache_domain(int cpu)
> 
>   sd = lowest_flag_domain(cpu, SD_NUMA);
>   rcu_assign_pointer(per_cpu(sd_numa, cpu), sd);
> +
> + sd = highest_flag_domain(cpu, SD_SHARE_PKG_RESOURCES | SD_ASYM_PACKING);
> + rcu_assign_pointer(per_cpu(sd_busy, cpu), sd);
>  }
> 
>  /*
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 813dd61..3d5141e 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -6512,19 +6512,23 @@ static inline void nohz_balance_exit_idle(int cpu)
>   }
>  }
> 
> -static inline void set_cpu_sd_state_busy(void)
> +static inline void set_cpu_sd_state_busy(int cpu)
>  {
>   struct sched_domain *sd;
> +  

RE: [PATCH v2] mmc:sdhci-pci: Add Support of O2Mirco/BayHubTech SD Host

[Peter Guo]

Hi Chris,

Do you have any comments on this patch?

Thanks,
Peter.Guo

-Original Message-
From: Adam Lee [mailto:adam@canonical.com] 
Sent: Wednesday, October 16, 2013 4:16 PM
To: Peter Guo; Chris Ball
Cc: Adrian Hunter; Greg Kroah-Hartman; Bill Pemberton; Guennadi Liakhovetski; 
linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Samuel Guan; Xiaoguang 
Yu; Shirley Her; Yuxiang Wan
Subject: Re: [PATCH v2] mmc:sdhci-pci: Add Support of O2Mirco/BayHubTech SD Host

On Wed, Oct 16, 2013 at 07:26:23AM +, Peter Guo wrote:
> Add O2Micro/BayHubTech SD Host DeviceId 8520 support and specified Init.
> Apply SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 for SD Host Controller.
> Apply SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC for SD Host Controller.
> 
> Signed-off-by: peter.guo 
> ---
>  drivers/mmc/host/sdhci-pci.c |  208 
> ++
>  1 file changed, 208 insertions(+)

I'm enabling "O2 Micro, Inc. Device [1217:8520]" on some laptops, it works 
after this patch applied.

Chris, please take a look? Thanks.

Tested-by: Adam Lee 

--
Adam Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [3.11.4] Thunderbolt/PCI unplug oops in pci_pme_list_scan

[Bjorn Helgaas]

[+cc Yinghai]

On Thu, Oct 17, 2013 at 7:59 AM, Andreas Noever
 wrote:
> On Wed, Oct 16, 2013 at 10:21 PM, Bjorn Helgaas  wrote:
>> On Tue, Oct 15, 2013 at 03:44:52AM +0100, Matthew Garrett wrote:
>>> On Mon, Oct 14, 2013 at 05:50:38PM -0600, Bjorn Helgaas wrote:
>>> > [+cc Rafael, Mika, Kirill, linux-pci]
>>> >
>>> > On Mon, Oct 14, 2013 at 4:47 PM, Andreas Noever
>>> >  wrote:
>>> > > When I unplug the Thunderbolt ethernet adapter on my MacBookPro Linux
>>> > > crashes a few seconds later. Using
>>> > > echo 1 > /sys/bus/pci/devices/:08:00.0/remove
>>> > > to remove a bridge two levels above the device triggers the fault 
>>> > > immediately:
>>> >
>>> > There have been significant changes in acpiphp related to Thunderbolt
>>> > since v3.11.
>>>
>>> Apple don't expose Thunderbolt via ACPI, so it appears as native PCIe.
>>> I'd be surprised if acpiphp makes a difference here.
>>
>> Yeah, you're right; I wasn't paying attention.
>>
>> We save a pci_dev pointer in the pci_pme_list, which of course has a
>> longer lifetime than the pci_dev itself, but we don't acquire a reference
>> on it, so I suspect the pci_dev got released before we got around to
>> doing the pci_pme_list_scan().
>>
>> Andreas, can you try the patch below?  It's against v3.12-rc2, but it
>> should apply to v3.11, too.
>
> I have tested your patch against 3.11 where it solves the problem. Thanks!
>
> Unfortunately I could not reproduce the problem in 3.12-rc5. I only
> get the following warning (and no crash):
>
> tg3 :0a:00.0: PME# disabled
> pcieport :09:00.0: PME# disabled
> pciehp :09:00.0:pcie24: unloading service driver pciehp
> pci_bus :0a: dev 00, dec refcount to 0
> pci_bus :0a: dev 00, released physical slot 9
> [ cut here ]
> WARNING: CPU: 0 PID: 122 at drivers/pci/pci.c:1430
> pci_disable_device+0x84/0x90()
> Device pcieport
> disabling already-disabled device
> Modules linked in:
>  btusb bluetooth joydev hid_apple bcm5974 nls_utf8 nls_cp437 hfsplus
> vfat fat snd_hda_codec_hdmi x86_pkg_temp_thermal intel_powerclamp
> coretemp kvm_intel kvm cfg80211 uvcvideo crc32_pclmul crc32c_intel
> videobuf2_vmalloc ghash_clmulni_intel aesni_intel videobuf2_memops
> aes_x86_64 glue_helper videobuf2_core tg3 videodev lrw gf128mul
> ablk_helper iTCO_wdt hid_generic iTCO_vendor_support cryptd media
> applesmc input_polldev usbhid ptp microcode snd_hda_codec_cirrus hid
> pps_core libphy rfkill i2c_i801 pcspkr snd_hda_intel apple_gmux
> lib80211 snd_hda_codec acpi_cpufreq snd_hwdep snd_pcm snd_page_alloc
> snd_timer mei_me snd mei processor soundcore lpc_ich evdev mfd_core
> apple_bl ac battery ext4 crc16 mbcache jbd2 sd_mod ahci libahci libata
> xhci_hcd ehci_pci sdhci_pci ehci_hcd sdhci scsi_mod mmc_core
>  usbcore usb_common nouveau mxm_wmi wmi ttm i915 video button
> i2c_algo_bit intel_agp intel_gtt drm_kms_helper drm i2c_core
> CPU: 0 PID: 122 Comm: kworker/u16:5 Not tainted 3.12.0-1-dirty #30
> Hardware name: Apple Inc. MacBookPro10,1/Mac-C3EC7CD22292981F, BIOS
> MBP101.88Z.00EE.B03.1212211437 12/21/2012
> Workqueue: sysfsd sysfs_schedule_callback_work
>  0009 88044c021c00 814c4288 88044c021c48
>  88044c021c38 81061b7d 880458a5c000 8187c5c0
>  880458a5c000 880458a5b098  88044c021c98
> Call Trace:
>  [] dump_stack+0x54/0x8d
>  [] warn_slowpath_common+0x7d/0xa0
>  [] warn_slowpath_fmt+0x4c/0x50
>  [] ? do_pci_disable_device+0x52/0x60
>  [] ? acpi_pci_irq_disable+0x4c/0x8d
>  [] pci_disable_device+0x84/0x90
>  [] pcie_portdrv_remove+0x1a/0x20
>  [] pci_device_remove+0x3b/0xb0
>  [] __device_release_driver+0x7f/0xf0
>  [] device_release_driver+0x23/0x30
>  [] bus_remove_device+0x108/0x180
>  [] device_del+0x135/0x1d0
>  [] pci_stop_bus_device+0x94/0xa0
>  [] pci_stop_bus_device+0x3b/0xa0
>  [] pci_stop_and_remove_bus_device+0x12/0x20
>  [] remove_callback+0x25/0x40
>  [] sysfs_schedule_callback_work+0x14/0x80
>  [] process_one_work+0x178/0x470
>  [] worker_thread+0x121/0x3a0
>  [] ? manage_workers.isra.21+0x2b0/0x2b0
>  [] kthread+0xc0/0xd0
>  [] ? kthread_create_on_node+0x120/0x120
>  [] ret_from_fork+0x7c/0xb0
>  [] ? kthread_create_on_node+0x120/0x120
> ---[ end trace b39a15fa94fbb2a2 ]---
>
>
> Bisection points to 928bea964827d7824b548c1f8e06eccbbc4d0d7d .

This is "PCI: Delay enabling bridges until they're needed" by Yinghai.

Yinghai, please comment.

> From this commit on the pci_pme_list_scan crash disappears and the
> warning appears.
>
> Since this commit seems to just mask the problem I went ahead and
> tested your patch on 3.12-rc5 as well. It seems to work (not crash)
> but the warning is still there.
>
> The above warning was triggered by removing the 08 bridge via sysfs.
> The same warning can be triggered by unplugging the adapter (dmesg
> below). The ethernet card is removed immediately. The bridges follow
> 15 seconds later together with the warning. The topology is:
> 06:03.0 -- 08 -- 09 -- 0a 

Re: [PATCH v4 2/2] blk-throttle: trim tokens generated for an idle tree

[Hong zhi guo]

Hi, Vivek,

Sorry I don't have time to test them carefully this week. I'll do it
in this weekend.

The updating of nr_queued_tree level by level only happens once for
each bio. We have already the computing(and maybe queue operation)
level by level for every bio, even it's passed through without being
queued on the tree.  And the computing(and queue operation) on each
level is much bigger than updating one counter (nr_queued_tree).

So updating of nr_queued_tree doesn't introduce notable overhead
compared to existing overhead of blk-throttle.

Zhiguo

On Wed, Oct 23, 2013 at 5:02 AM, Vivek Goyal  wrote:
> On Sun, Oct 20, 2013 at 08:11:12PM +0800, Hong Zhiguo wrote:
>> From: Hong Zhiguo 
>>
>> Why
>> 
>> Pointed out by Vivek: Tokens generated during idle period should
>> be trimmed. Otherwise a huge bio may be permited immediately.
>> Overlimit behaviour may be observed during short I/O throughput
>> test.
>>
>> Vivek also pointed out: We should not over-trim for hierarchical
>> groups. Suppose a subtree of groups are idle when a big bio comes.
>> The token of the child group is trimmed and not enough. So the bio is
>> queued on the child group. After some jiffies the child group reserved
>> enough tokens and the bio climbs up. If we trim the parent group at
>> this time again, this bio will wait too much time than expected.
>>
>> Analysis
>> 
>> When the bio is queued on child group, all it's ancestor groups
>> becomes non-idle. They should start to reserve tokens for that
>> bio from this moment. And their reserved tokens before should be
>> trimmed at this moment.
>>
>> How
>> 
>> service_queue now has a new member nr_queued_tree[2], to represent
>> the the number of bios waiting on the subtree rooted by this sq.
>>
>> When a bio is queued on the hierarchy first time, nr_queued_tree
>> of all ancestors and the child group itself are increased. When a
>> bio climbs up, nr_queued_tree of the child group is decreased.
>>
>> When nr_queued_tree turns from zero to one, the tokens reserved
>> before are trimmed. And after this switch, this group will never
>> be trimmed to reserve tokens for the bio waiting on it's descendant
>> group.
>>
>
> Hi Hong,
>
> This approach looks good in general. Only downside I can think of
> updation of nr_requests throughout the hierarchy. So deeper the
> hierarchy, higher the overhead.
>
> I am not sure if that's a concern or not. I will have a closer look
> a the patches tomorrow and do some testing too.
>
> Thanks
> Vivek



-- 
best regards
Hong Zhiguo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [f2fs-dev] [PATCH] f2fs: check all ones or zeros bitmap with integer data type for better mount performance

[Chao Yu]

Hi, Kim:

> -Original Message-
> From: Jaegeuk Kim [mailto:jaegeuk@samsung.com]
> Sent: Tuesday, October 22, 2013 8:24 PM
> To: Chao Yu
> Cc: linux-f2fs-de...@lists.sourceforge.net; linux-fsde...@vger.kernel.org;
> linux-kernel@vger.kernel.org; 谭姝
> Subject: Re: [f2fs-dev] [PATCH] f2fs: check all ones or zeros bitmap with 
> integer
> data type for better mount performance
> 
> Hi,
> 
> 2013-10-22 (화), 17:28 +0800, Chao Yu:
> > Previously, check_block_count check valid_map with bit data type in
> > common scenario that sit has all ones or zeros bitmap, it makes low
> > mount performance.
> > So let's check the special bitmap with integer data type instead of
> > the bit one.
> >
> > Signed-off-by: Tan Shu 
> > Signed-off-by: Yu Chao 
> > ---
> >  fs/f2fs/segment.h |   13 +
> >  1 file changed, 13 insertions(+)
> >
> > diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h index
> > 7f94d78..d43ab9f 100644
> > --- a/fs/f2fs/segment.h
> > +++ b/fs/f2fs/segment.h
> > @@ -543,6 +543,7 @@ static inline void check_block_count(struct
> > f2fs_sb_info *sbi,  {
> > struct f2fs_sm_info *sm_info = SM_I(sbi);
> > unsigned int end_segno = sm_info->segment_count - 1;
> > +   int *valid_map = (int *)raw_sit->valid_map;
> > int valid_blocks = 0;
> > int i;
> >
> > @@ -552,6 +553,19 @@ static inline void check_block_count(struct
> > f2fs_sb_info *sbi,
> > /* check boundary of a given segment number */
> > BUG_ON(segno > end_segno);
> >
> > +   /* check all ones or zeros valid_map */
> > +   if (GET_SIT_VBLOCKS(raw_sit) == 0) {
> > +   for (i = 0; i < SIT_VBLOCK_MAP_SIZE / sizeof(int); i++)
> 
> We cannot guarantee all the time that SIT_VBLOCK_MAP_SIZE is multiple of
> sizeof(int).
Well, It's really large changes for f2fs if SIT_VBLOCK_MAP_SIZE value is being 
modified.

> How about using memcmp() with __u8?
Do you mean that we can alloc all zeros or ones memory in SIT_VBLOCK_MAP_SIZE 
size,
then memcmp() it with sit bitmap by __u8?

> 
> > +   if (unlikely(valid_map[i] != 0))
> > +   BUG();
> > +   return;
> > +   } else if (GET_SIT_VBLOCKS(raw_sit) == sbi->blocks_per_seg) {
> > +   for (i = 0; i < SIT_VBLOCK_MAP_SIZE / sizeof(int); i++)
> > +   if (unlikely(valid_map[i] != -1))
> > +   BUG();
> > +   return;
> > +   }
> > +
> > /* check bitmap with valid block count */
> > for (i = 0; i < sbi->blocks_per_seg; i++)
> > if (f2fs_test_bit(i, raw_sit->valid_map))
> > ---
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-fsdevel" in the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> --
> Jaegeuk Kim
> Samsung

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] mn10300/PCI: Remove useless pcibios_last_bus

[Bjorn Helgaas]

pcibios_last_bus was apparently copied from x86.  On mn10300, it is
statically initialized to -1 and may be set with the "pci=lastbus="
boot option, but it is never tested.  This patch removes everything
related to pcibios_last_bus.

Signed-off-by: Bjorn Helgaas 
---
 arch/mn10300/unit-asb2305/pci-asb2305.h |1 -
 arch/mn10300/unit-asb2305/pci.c |5 -
 2 files changed, 6 deletions(-)

diff --git a/arch/mn10300/unit-asb2305/pci-asb2305.h 
b/arch/mn10300/unit-asb2305/pci-asb2305.h
index 7fa66a0..9e17aca 100644
--- a/arch/mn10300/unit-asb2305/pci-asb2305.h
+++ b/arch/mn10300/unit-asb2305/pci-asb2305.h
@@ -35,7 +35,6 @@ extern void pcibios_resource_survey(void);
 
 /* pci.c */
 
-extern int pcibios_last_bus;
 extern struct pci_ops *pci_root_ops;
 
 extern struct irq_routing_table *pcibios_get_irq_routing_table(void);
diff --git a/arch/mn10300/unit-asb2305/pci.c b/arch/mn10300/unit-asb2305/pci.c
index e37fac0..6b4339f 100644
--- a/arch/mn10300/unit-asb2305/pci.c
+++ b/arch/mn10300/unit-asb2305/pci.c
@@ -24,7 +24,6 @@
 
 unsigned int pci_probe = 1;
 
-int pcibios_last_bus = -1;
 struct pci_ops *pci_root_ops;
 
 /*
@@ -392,10 +391,6 @@ char *__init pcibios_setup(char *str)
if (!strcmp(str, "off")) {
pci_probe = 0;
return NULL;
-
-   } else if (!strncmp(str, "lastbus=", 8)) {
-   pcibios_last_bus = simple_strtol(str+8, NULL, 0);
-   return NULL;
}
 
return str;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] frv/PCI: Remove pcibios_last_bus

[Bjorn Helgaas]

pcibios_last_bus was apparently copied from x86.  On FR-V, it is
statically initialized to -1 and never changed unless the user boots
with "pci=lastbus=".  I doubt that option is used on FR-V, so this
patch removes all the code related to pcibios_last_bus.

Signed-off-by: Bjorn Helgaas 
---
 arch/frv/mb93090-mb00/pci-frv.h |1 -
 arch/frv/mb93090-mb00/pci-vdk.c |   36 
 2 files changed, 37 deletions(-)

diff --git a/arch/frv/mb93090-mb00/pci-frv.h b/arch/frv/mb93090-mb00/pci-frv.h
index 76c4e73..a7e487fe 100644
--- a/arch/frv/mb93090-mb00/pci-frv.h
+++ b/arch/frv/mb93090-mb00/pci-frv.h
@@ -30,7 +30,6 @@ void pcibios_resource_survey(void);
 
 /* pci-vdk.c */
 
-extern int __nongpreldata pcibios_last_bus;
 extern struct pci_ops *__nongpreldata pci_root_ops;
 
 /* pci-irq.c */
diff --git a/arch/frv/mb93090-mb00/pci-vdk.c b/arch/frv/mb93090-mb00/pci-vdk.c
index deb6784..efa5d65 100644
--- a/arch/frv/mb93090-mb00/pci-vdk.c
+++ b/arch/frv/mb93090-mb00/pci-vdk.c
@@ -25,7 +25,6 @@
 
 unsigned int __nongpreldata pci_probe = 1;
 
-int  __nongpreldata pcibios_last_bus = -1;
 struct pci_ops *__nongpreldata pci_root_ops;
 
 /*
@@ -220,37 +219,6 @@ static struct pci_ops * __init pci_check_direct(void)
 }
 
 /*
- * Discover remaining PCI buses in case there are peer host bridges.
- * We use the number of last PCI bus provided by the PCI BIOS.
- */
-static void __init pcibios_fixup_peer_bridges(void)
-{
-   struct pci_bus bus;
-   struct pci_dev dev;
-   int n;
-   u16 l;
-
-   if (pcibios_last_bus <= 0 || pcibios_last_bus >= 0xff)
-   return;
-   printk("PCI: Peer bridge fixup\n");
-   for (n=0; n <= pcibios_last_bus; n++) {
-   if (pci_find_bus(0, n))
-   continue;
-   bus.number = n;
-   bus.ops = pci_root_ops;
-   dev.bus = 
-   for(dev.devfn=0; dev.devfn<256; dev.devfn += 8)
-   if (!pci_read_config_word(, PCI_VENDOR_ID, ) &&
-   l != 0x && l != 0x) {
-   printk("Found device at %02x:%02x [%04x]\n", n, 
dev.devfn, l);
-   printk("PCI: Discovered peer bus %02x\n", n);
-   pci_scan_bus(n, pci_root_ops, NULL);
-   break;
-   }
-   }
-}
-
-/*
  * Exceptions for specific devices. Usually work-arounds for fatal design 
flaws.
  */
 
@@ -418,7 +386,6 @@ int __init pcibios_init(void)
pci_scan_root_bus(NULL, 0, pci_root_ops, NULL, );
 
pcibios_irq_init();
-   pcibios_fixup_peer_bridges();
pcibios_fixup_irqs();
pcibios_resource_survey();
 
@@ -432,9 +399,6 @@ char * __init pcibios_setup(char *str)
if (!strcmp(str, "off")) {
pci_probe = 0;
return NULL;
-   } else if (!strncmp(str, "lastbus=", 8)) {
-   pcibios_last_bus = simple_strtol(str+8, NULL, 0);
-   return NULL;
}
return str;
 }

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/2] Remove pcibios_last_bus stuff

[Bjorn Helgaas]

pcibios_last_bus is an x86 thing that has gotten copied into mn10300
and FR-V.  On mn10300, it is clearly useless because it is set but
never tested.

On FR-V, I suspect it is also useless, but it is possible that people
boot with "pci=lastbus=".  Please speak up if you think it should
be kept for FR-V.

---

Bjorn Helgaas (2):
  frv/PCI: Remove pcibios_last_bus
  mn10300/PCI: Remove useless pcibios_last_bus


 arch/frv/mb93090-mb00/pci-frv.h |1 -
 arch/frv/mb93090-mb00/pci-vdk.c |   36 ---
 arch/mn10300/unit-asb2305/pci-asb2305.h |1 -
 arch/mn10300/unit-asb2305/pci.c |5 
 4 files changed, 43 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH] kernel/kallsyms.c: only show legal kernel symbol

[Ming Lei]

Address of non-module kernel symbol should always be located
from CONFIG_PAGE_OFFSET on, so only show these legal kernel
symbols in /proc/kallsyms.

On ARM, some symbols(see below) may drop in relocatable code, so
perf can't parse kernel symbols any more from /proc/kallsyms, this
patch fixes the problem.

 t __vectors_start
0020 A cpu_v7_suspend_size
1000 t __stubs_start
1004 t vector_rst
1020 t vector_irq
10a0 t vector_dabt
1120 t vector_pabt
11a0 t vector_und
1220 t vector_addrexcptn
1224 t vector_fiq
1224 T vector_fiq_offset

The issue can be fixed in scripts/kallsyms.c too, but looks this
approach is easier.

Cc: Russell King 
Cc: linux-arm-ker...@lists.infradead.org
Cc: Rusty Russell 
Cc: Chen Gang 
Signed-off-by: Ming Lei 
---
 kernel/kallsyms.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 3127ad5..184f271 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -543,7 +543,7 @@ static int s_show(struct seq_file *m, void *p)
tolower(iter->type);
seq_printf(m, "%pK %c %s\t[%s]\n", (void *)iter->value,
   type, iter->name, iter->module_name);
-   } else
+   } else if (iter->value >= CONFIG_PAGE_OFFSET)
seq_printf(m, "%pK %c %s\n", (void *)iter->value,
   iter->type, iter->name);
return 0;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[BUG] pstore: failed to load 76 record(s) from 'efi'

[Madper Xie]

Hi folks,
  after mount pstore with efi as backend there are only 11 entries in
  pstore dir. Although I have about 80 pstore entries in my nvram.
  I can reproduce it 100% on my DELL XPS. And will try it on one more
  vendor.

  my kernel version is 3.12-rc4. Please let me know if it's not a kernel
  bug but a buggy firmware. :-)
  
  Here is my dmesg out put:
  [   17.076222] IPv6: ADDRCONF(NETDEV_CHANGE): p3p1: link becomes ready
  [  104.749604] pstore: failed to load 76 record(s) from 'efi'  <-- this line 
appear when I mount pstore.
  [  104.749610] SELinux: initialized (dev pstore, type pstore), not configured 
for labeling

  Here is the output of `ls /sys/firmware/efi/vars`:
AcpiGlobalVariable-af9ffd67-ec10-488a-9dfc-6cbf5ee22c2e
AMITSESetup-c811fa38-42c8-4579-a9bb-60e94eddfb34
Boot-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0002-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0003-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0004-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0005-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c
CmosError-ceab3323-daab-92ee-c112-abee5a6ebe2c
ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConOutChild1-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConOutChildNumber-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
db-d719b2cb-3d3a-4596-a3bc-dad00e67656f
dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f
DebuggerSerialPortsEnabledVar-97ca1a5b-b760-4d1f-a54b-d19092032c90
DefaultConOutChild-8be4df61-93ca-11d2-aa0d-00e098032b8c
DefaultFBOSetDevOrder-0c923ca9-df73-4ac8-b6d2-98ddc30d99fc
DefaultFBOSetDevOrderUEFI-0c923ca9-df73-4ac8-b6d2-98ddc30d99fc
DELLDIAG_EEPROM-86fd3e21-8683-4f2e-bcc1-2c52493bd1f6
del_var
DriverHealthCount-7459a7d4-6533-4480-bba7-79e25a4443c9
DriverHlthEnable-0885f288-418c-4be1-a6af-8bad61da08fe
dump-type0-10-1-1379387013-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-10-1-1380015708-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-10-1-1380016446-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-10-1-1380441690-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-10-1-1380448560-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-10-1-1380460890-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-10-1-1380467798-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-10-1-1382496073-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-11-1-1379387013-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-11-1-1380015708-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-11-1-1380016446-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-11-1-1380441691-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-11-1-1380448560-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-11-1-1382496074-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-1-1379387012-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-1-1380015706-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-1-1380016444-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-1-1380441689-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-1-1380448559-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-1-1380460875-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-1-1380467797-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-1-1380524664-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-1-1380526061-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-1-1380527153-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-1-1382496055-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-2-1-1379387012-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-2-1-1380015706-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-2-1-1380016445-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-2-1-1380441689-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-2-1-1380448559-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-2-1-1380460888-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-2-1-1380467797-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-2-1-1380524664-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-2-1-1380526061-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-2-1-1382496055-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-3-1-1379387012-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-3-1-1380015706-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-3-1-1380016445-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-3-1-1380441689-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-3-1-1380448559-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-3-1-1380460889-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-3-1-1380467797-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-3-1-1380524664-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-3-1-1382496055-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-4-1-1379387012-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-4-1-1380015707-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0

Re: [Suggestion] arc: compiler: bug: about an arc compiler's bug which is not in gcc main source code.

[Chen Gang]

On 10/23/2013 10:51 AM, Francois Bedard wrote:
> Our sources are on github at 
> https://github.com/foss-for-synopsys-dwc-arc-processors  and you can report 
> problems by opening "Issues" with command lines and log outputs below against 
> relevant toolchain component:
> 
> For GCC:  
> https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/issues?state=open
> For binutils: 
> https://github.com/foss-for-synopsys-dwc-arc-processors/binutils/issues?page=1=open
>  
> 
> Go ahead and officially file these and we'll take a look at them. 

I will/should go ahead, hope I can finish reporting them within this
week (2013-10-27)

Thanks.
-- 
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Suggestion] arc: compiler: bug: about an arc compiler's bug which is not in gcc main source code.

[Chen Gang]

On 10/23/2013 10:48 AM, Joern Rennecke wrote:
> On 23 October 2013 03:00, Chen Gang  wrote:
> 
>> Binutils (1 issue, ld and as information):
>>
>>   when calling panic(), printk(), or memset() with R_ARC_S21W_PCREL, it may 
>> be overflow (I guess it need be R_ARC_S25W_PCREL).
>>
>>   /usr/local/bin/arc-elf32-ld --build-id -X -o .tmp_vmlinux1 -T 
>> /android/public-kernel/linux-next/arch/arc/kernel/vmlinux.lds 
>> arch/arc/kernel/head.o init/built-in.o --start-group usr/built-in.o 
>> arch/arc/built-in.o arch/arc/boot/dts/built-in.o 
>> arch/arc/plat-arcfpga/built-in.o arch/arc/plat-tb10x/built-in.o 
>> kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o 
>> security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a 
>> arch/arc/lib/lib.a /usr/local/lib/gcc/arc-elf32/4.8.0/libgcc.a 
>> lib/built-in.o arch/arc/lib/built-in.o 
>> /usr/local/lib/gcc/arc-elf32/4.8.0/libgcc.a drivers/built-in.o 
>> sound/built-in.o firmware/built-in.o net/built-in.o --end-group
>>   /usr/local/bin/arc-elf32-ld: Error: Overflow detected in relocation value;
>>   /usr/local/bin/arc-elf32-ld: Relocation value should be between 1048575 
>> and -1048576 whereas it  2404264
>>   /usr/local/bin/arc-elf32-ld: Global symbol: "panic".
>>   /usr/local/bin/arc-elf32-ld:
>>   Relocation type is:R_ARC_S21W_PCREL
>>   FileName:arch/arc/built-in.o
>>   Section Name:.text
>>   Offset in Section:1716
>>   /usr/local/bin/arc-elf32-ld: final link failed: Bad value
>>   make: *** [vmlinux] Error 1
> 
> That just means that the image is too large to allow conditional
> pc-relative calls (tail/sibcalls) or otherwise.
> 
> You can avoid generating them for functions with out a relevant
> attribute with -mmedium-calls .
> 

OK, thanks, I will/should try (it should be OK).

BTW: after pass this, kernel may pass the whole cross compiling with
allmodconfig (the other 2 gcc issues, can reconstruct source code to
bypass).

> 
> 
>> GCC (2 issues, and gcc information):
>>
>> CC  drivers/rtc/systohc.o
>>   drivers/rtc/systohc.c: In function 'rtc_set_ntp_time':
>>   drivers/rtc/systohc.c:44:1: internal compiler error: in arc_ifcvt, at 
>> config/arc/arc.c:8315
>>}
>>^
>>   0x939c94 arc_ifcvt
>> ../../gcc/gcc/config/arc/arc.c:8315
>>   0x93a394 arc_reorg
>> ../../gcc/gcc/config/arc/arc.c:5985
>>   0x7517d9 rest_of_handle_machine_reorg
>> ../../gcc/gcc/reorg.c:3927
>>   Please submit a full bug report,
>>   with preprocessed source if appropriate.
>>   Please include the complete backtrace with any bug report.
>>   See  for instructions.
>>   make[2]: *** [drivers/rtc/systohc.o] Error 1
>>   make[1]: *** [drivers/rtc] Error 2
>>   make: *** [drivers] Error 2
>>
>>
>> CC [M]  drivers/target/target_core_pr.o
>>   drivers/target/target_core_pr.c: In function 'target_scsi3_emulate_pr_in':
>>   drivers/target/target_core_pr.c:4033:1: error: unrecognizable insn:
>>}
>>^
>>   (insn 846 194 196 12 (set (reg:QI 1 r1)
>>   (subreg:QI (mem/j/c:DI (plus:SI (reg/v/f:SI 2 r2 [orig:199 pr_reg 
>> ] [199])
>>   (const_int 576 [0x240])) [0 pr_reg_50->pr_res_key+0 S8 
>> A32]) 7)) drivers/target/target_core_pr.c:3677 -1
>>(nil))
>>   drivers/target/target_core_pr.c:4033:1: internal compiler error: in 
>> extract_insn, at recog.c:2151
>>   0x758fb5 _fatal_insn(char const*, rtx_def const*, char const*, int, char 
>> const*)
>> ../../gcc/gcc/rtl-error.c:109
>>   0x758fe9 _fatal_insn_not_found(rtx_def const*, char const*, int, char 
>> const*)
>> ../../gcc/gcc/rtl-error.c:117
>>   0x726e83 extract_insn(rtx_def*)
>> ../../gcc/gcc/recog.c:2151
>>   0x726ef4 extract_insn_cached(rtx_def*)
>> ../../gcc/gcc/recog.c:2054
>>   0x5fe026 cleanup_subreg_operands(rtx_def*)
>> ../../gcc/gcc/final.c:3305
>>   0x750c2e reload(rtx_def*, int)
>> ../../gcc/gcc/reload1.c:1240
>>   0x68e703 do_reload
>> ../../gcc/gcc/ira.c:4631
>>   0x68e703 rest_of_handle_reload
>> ../../gcc/gcc/ira.c:4731
>>   Please submit a full bug report,
>>   with preprocessed source if appropriate.
>>   Please include the complete backtrace with any bug report.
>>   See  for instructions.
>>   make[2]: *** [drivers/target/target_core_pr.o] Error 1
>>   make[1]: *** [drivers/target] Error 2
>>   make: *** [drivers] Error 2
> 
> Can these issues be reproduced with the lastest gcc version?  If so,
> can you provide preprocessed source of the testcases and the compiler
> flags to trigger the ICEs?
> 
> 

OK, thanks, I will/should try, hope I can finish within this month
(2013-10-31).

Thanks.
-- 
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Driver Design Question

[Guenter Roeck]

On 10/22/2013 12:02 AM, Johannes Thumshirn wrote:

Hi List,

I have a design question concerning a device driver. The device in question is
somewhere in between drivers/mfd/timberdale and drivers/ssb. It is mapped
connected via PCI and on PCI Bar 0 there is a table describing which
"sub-devices" are contained in the FPGA as well as where their Memory and IRQ
resources are.

Unlike the timberdale driver, there is no static configuration of the FPGA's
sub-devices, but their number and kind is variable. But luckily we have unique
device-ids for every sub-device, so it is possible to do a PCI/USB like
enumeration.

In my understanding the MFD API, which timberdale uses, isn't tailored to this
Plug'n'Play like behavior. Whereas the I think (virtual) bus concept used by


Not sure if that is true. There is no requirement to declare mfd cells
statically. As long as the devices don't change after mfd probe, an mfd based
solution would at least be implementable.

However, adding support for new sub-devices might be an issue, as you would
have to update the mfd driver to add support for each new device (to create its
mfd cell and platform data), in addition to writing the actual driver.


SSB is much more suited for this kind of devices. But would it be wise to add a
bus only suited to devices manufactured by one vendor, when there is already a
API for such kinds of multi function devices?


Assuming you refer to mfd, isn't that a contradiction ? You just stated that mfd
doesn't exactly meet your requirements. There is also an API for adding a new 
bus,
and it is used quite widely.

Question for me would be if the additional overhead for adding a bus outweighs 
its
benefits.


Long story short, which would be the preferred way to implement such a driver? 
At
the point I currently reached I could go in both directions.

I'd appreciate any advice I can get on this topic.



I'm adding Greg KH to the thread. Maybe he has some useful advice as the driver 
core
maintainer. I have struggled with the question if to add a bus myself, so maybe 
I can
get something useful out of it ;).

Thanks,
Guenter


Thanks in advance,

Johannes

P.S.: MFD and SSB maintainers are on CC as I'd really like to hear their opinion
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/






--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mm: Ensure get_unmapped_area() returns higher address than mmap_min_addr

[Akira Takeuchi]

This patch fixes the problem that get_unmapped_area() can return illegal
address and result in failing mmap(2) etc.

In case that the address higher than PAGE_SIZE is set to
/proc/sys/vm/mmap_min_addr, the address lower than mmap_min_addr can be
returned by get_unmapped_area(), even if you do not pass any virtual
address hint (i.e. the second argument).

This is because the current get_unmapped_area() code does not take into
account mmap_min_addr.

This leads to two actual problems as follows:

1. mmap(2) can fail with EPERM on the process without CAP_SYS_RAWIO,
   although any illegal parameter is not passed.

2. The bottom-up search path after the top-down search might not work in
   arch_get_unmapped_area_topdown().

[How to reproduce]

--- test.c -
#include 
#include 
#include 
#include 

int main(int argc, char *argv[])
{
void *ret = NULL, *last_map;
size_t pagesize = sysconf(_SC_PAGESIZE);

do {
last_map = ret;
ret = mmap(0, pagesize, PROT_NONE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
//  printf("ret=%p\n", ret);
} while (ret != MAP_FAILED);

if (errno != ENOMEM) {
printf("ERR: unexpected errno: %d (last map=%p)\n",
errno, last_map);
}

return 0;
}
---

$ gcc -m32 -o test test.c
$ sudo sysctl -w vm.mmap_min_addr=65536
vm.mmap_min_addr = 65536
$ ./test  (run as non-priviledge user)
ERR: unexpected errno: 1 (last map=0x1)

Signed-off-by: Akira Takeuchi 
Signed-off-by: Kiyoshi Owada 
---
 mm/mmap.c |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/mm/mmap.c b/mm/mmap.c
index 9d54851..362e5f1 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1856,7 +1856,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long 
addr,
struct vm_area_struct *vma;
struct vm_unmapped_area_info info;
 
-   if (len > TASK_SIZE)
+   if (len > TASK_SIZE - mmap_min_addr)
return -ENOMEM;
 
if (flags & MAP_FIXED)
@@ -1865,7 +1865,7 @@ arch_get_unmapped_area(struct file *filp, unsigned long 
addr,
if (addr) {
addr = PAGE_ALIGN(addr);
vma = find_vma(mm, addr);
-   if (TASK_SIZE - len >= addr &&
+   if (TASK_SIZE - len >= addr && addr >= mmap_min_addr &&
(!vma || addr + len <= vma->vm_start))
return addr;
}
@@ -1895,7 +1895,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const 
unsigned long addr0,
struct vm_unmapped_area_info info;
 
/* requested length too big for entire address space */
-   if (len > TASK_SIZE)
+   if (len > TASK_SIZE - mmap_min_addr)
return -ENOMEM;
 
if (flags & MAP_FIXED)
@@ -1905,14 +1905,14 @@ arch_get_unmapped_area_topdown(struct file *filp, const 
unsigned long addr0,
if (addr) {
addr = PAGE_ALIGN(addr);
vma = find_vma(mm, addr);
-   if (TASK_SIZE - len >= addr &&
+   if (TASK_SIZE - len >= addr && addr >= mmap_min_addr &&
(!vma || addr + len <= vma->vm_start))
return addr;
}
 
info.flags = VM_UNMAPPED_AREA_TOPDOWN;
info.length = len;
-   info.low_limit = PAGE_SIZE;
+   info.low_limit = max(PAGE_SIZE, mmap_min_addr);
info.high_limit = mm->mmap_base;
info.align_mask = 0;
addr = vm_unmapped_area();
-- 
1.7.0.4


-- 
Akira Takeuchi 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] arc: kernel: remove '__init' for get_hw_config_num_irq()

[Chen Gang]

get_hw_config_num_irq() may be called by normal iss_model_init_smp()
which is a function pointer for 'init_smp' which may be called by
first_lines_of_secondary() which also need be normal too.

The related warning (with allmodconfig):

MODPOST vmlinux.o
  WARNING: vmlinux.o(.text+0x5814): Section mismatch in reference from the 
function iss_model_init_smp() to the function .init.text:get_hw_config_num_irq()
  The function iss_model_init_smp() references
  the function __init get_hw_config_num_irq().
  This is often because iss_model_init_smp lacks a __init
  annotation or the annotation of get_hw_config_num_irq is wrong.


Signed-off-by: Chen Gang 
---
 arch/arc/include/asm/irq.h |2 +-
 arch/arc/kernel/irq.c  |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arc/include/asm/irq.h b/arch/arc/include/asm/irq.h
index 548207f..291a70d 100644
--- a/arch/arc/include/asm/irq.h
+++ b/arch/arc/include/asm/irq.h
@@ -19,7 +19,7 @@
 #include 
 
 extern void arc_init_IRQ(void);
-extern int __init get_hw_config_num_irq(void);
+extern int get_hw_config_num_irq(void);
 
 void arc_local_timer_setup(unsigned int cpu);
 
diff --git a/arch/arc/kernel/irq.c b/arch/arc/kernel/irq.c
index 5fc9245..e2bdfe5 100644
--- a/arch/arc/kernel/irq.c
+++ b/arch/arc/kernel/irq.c
@@ -146,7 +146,7 @@ void arch_do_IRQ(unsigned int irq, struct pt_regs *regs)
set_irq_regs(old_regs);
 }
 
-int __init get_hw_config_num_irq(void)
+int get_hw_config_num_irq(void)
 {
uint32_t val = read_aux_reg(ARC_REG_VECBASE_BCR);
 
-- 
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] sched: remove extra put_online_cpus() inside sched_setaffinity()

[Michael wang]

commit 6acce3ef84520537f8a09a12c9ddbe814a584dd2
sched: Remove get_online_cpus() usage

has left one extra put_online_cpus() inside sched_setaffinity(), remove it
to fix the WARN:

[3165] Watchdog is alive
[3159] Started watchdog thread 3165
[   58.695502] [ cut here ]
[   58.697835] WARNING: CPU: 0 PID: 3166 at kernel/cpu.c:84 
put_online_cpus+0x43/0x70()
[   58.702423] Modules linked in:
[   58.704404] CPU: 0 PID: 3166 Comm: trinity-child0 Not tainted 
3.12.0-rc5-01882-gf3db366 #1172
[   58.708530] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[   58.710992]   88000acfbe50 81a24643 

[   58.715410]  88000acfbe88 810c3e6b 810c3fef 

[   58.719826]   6ee0 0ffc 
88000acfbe98
[   58.724348] Call Trace:
[   58.726190]  [] dump_stack+0x4d/0x66
[   58.728531]  [] warn_slowpath_common+0x7f/0x98
[   58.731069]  [] ? put_online_cpus+0x43/0x70
[   58.733664]  [] warn_slowpath_null+0x1a/0x1c
[   58.736258]  [] put_online_cpus+0x43/0x70
[   58.738686]  [] sched_setaffinity+0x7d/0x1f9
[   58.741210]  [] ? sched_setaffinity+0x5/0x1f9
[   58.743775]  [] ? _raw_spin_unlock_irq+0x2c/0x3e
[   58.746417]  [] ? do_setitimer+0x194/0x1f5
[   58.748899]  [] SyS_sched_setaffinity+0x62/0x71
[   58.751481]  [] system_call_fastpath+0x16/0x1b
[   58.754070] ---[ end trace 034818a1f6f06868 ]---
[   58.757521] [ cut here ]

CC: Ingo Molnar 
CC: Peter Zijlstra 
Reported-by: Fengguang Wu 
Tested-by: Fengguang Wu 
Signed-off-by: Michael Wang 
---
 kernel/sched/core.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c06b8d3..7c61f31 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3716,7 +3716,6 @@ long sched_setaffinity(pid_t pid, const struct cpumask 
*in_mask)
p = find_process_by_pid(pid);
if (!p) {
rcu_read_unlock();
-   put_online_cpus();
return -ESRCH;
}

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] LSM: ModPin LSM for module loading restrictions

[Lucas De Marchi]

Hi Kees,

On Thu, Oct 3, 2013 at 6:36 PM, Kees Cook  wrote:
> On Fri, Oct 04, 2013 at 06:31:42AM +0900, Tetsuo Handa wrote:
>> Kees Cook wrote:
>> > +static int modpin_load_module(struct file *file)
>> > +{
>> > +   struct dentry *module_root;
>> > +
>> > +   if (!file) {
>> > +   if (!modpin_enforced) {
>> > +   report_load_module(NULL, "old-api-pinning-ignored");
>> > +   return 0;
>> > +   }
>> > +
>> > +   report_load_module(NULL, "old-api-denied");
>> > +   return -EPERM;
>> > +   }
>> > +
>> > +   module_root = file->f_path.mnt->mnt_root;
>> > +
>> > +   /* First loaded module defines the root for all others. */
>> > +   spin_lock(_root_spinlock);
>> > +   if (!pinned_root) {
>> > +   pinned_root = dget(module_root);
>> > +   /*
>> > +* Unlock now since it's only pinned_root we care about.
>> > +* In the worst case, we will (correctly) report pinning
>> > +* failures before we have announced that pinning is
>> > +* enabled. This would be purely cosmetic.
>> > +*/
>> > +   spin_unlock(_root_spinlock);
>> > +   check_pinning_enforcement();
>> > +   report_load_module(>f_path, "pinned");
>> > +   return 0;
>> > +   }
>> > +   spin_unlock(_root_spinlock);
>>
>> Firstly loaded module is usually in initramfs whereas subsequently loaded
>> modules are usually on a hard disk partition.
>>
>> This module is not meant for PC servers, is it?
>
> This LSM is what Chrome OS uses for the module pinning logic. We do not use
> an initramfs. This LSM could also be used for devices booting entirely from
> CDROM or other R/O media.
>
> I'm open to improvements, obviously. I imagine things like delayed
> activation, where the initramfs triggers pinning in some way once it is
> done loading modules from its filesystem, etc. But since I don't have any
> real life examples of this, I'm writing the LSM as it currently is, used
> without an initramfs. :)

The way you put now as well as the code are at least different from
what it's written in the commit message.  I was expecting that this
modpin would allow module loading only from a trusted partition.
Instead we are allowing to load modules from the same partition of the
first module that has been loaded, if the root is trusted. Why? What's
the relation with the root partition being trusted and the partition
where the modules reside?  What's the guarantee that the first module
to load is any more trustable than the others?

Lucas De Marchi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] x86: boot: support minigzip bzImage compression

[Guenter Roeck]

On 10/22/2013 05:26 PM, H. Peter Anvin wrote:

Wouldn't it be better to fix gzip than hacking around this in the kernel?


Or just change the build system to have /bin/gzip point to minigzip if so
desired. I have done the same to replace it with pigz.
Debian/Ubuntu provides the update-alternatives command for that
purpose. If that is not available, just hard-link it.

In general, I don't think it would be a good idea to add tool variant
dependencies like this one to the kernel configuration.

Guenter


Andrew Boie  wrote:

Android OTA system computes very efficient diffs of compressed files
if the deflate() algorithm it has access to is the same version as
used to create the original file. Here we add support for compressing
the kernel with 'minigzip' which uses the deflate() inside zlib.
This is much better than using 'gzip' as that tool has a very old
version of deflate() inside the gzip codebase instead of linking
against
zlib.

Signed-off-by: Andrew Boie 
---
arch/x86/Kconfig  |  1 +
arch/x86/boot/compressed/Makefile |  3 +++
arch/x86/boot/compressed/misc.c   |  2 +-
init/Kconfig  | 18 +-
scripts/Makefile.lib  |  7 +++
5 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f67e839..aa91cef 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -62,6 +62,7 @@ config X86
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_DMA_API_DEBUG
select HAVE_KERNEL_GZIP
+   select HAVE_KERNEL_MINIGZIP
select HAVE_KERNEL_BZIP2
select HAVE_KERNEL_LZMA
select HAVE_KERNEL_XZ
diff --git a/arch/x86/boot/compressed/Makefile
b/arch/x86/boot/compressed/Makefile
index dcd90df..f000791 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -56,6 +56,8 @@ vmlinux.bin.all-$(CONFIG_X86_NEED_RELOCS) +=
$(obj)/vmlinux.relocs

$(obj)/vmlinux.bin.gz: $(vmlinux.bin.all-y) FORCE
$(call if_changed,gzip)
+$(obj)/vmlinux.bin.mgz: $(vmlinux.bin.all-y) FORCE
+   $(call if_changed,minigzip)
$(obj)/vmlinux.bin.bz2: $(vmlinux.bin.all-y) FORCE
$(call if_changed,bzip2)
$(obj)/vmlinux.bin.lzma: $(vmlinux.bin.all-y) FORCE
@@ -68,6 +70,7 @@ $(obj)/vmlinux.bin.lz4: $(vmlinux.bin.all-y) FORCE
$(call if_changed,lz4)

suffix-$(CONFIG_KERNEL_GZIP):= gz
+suffix-$(CONFIG_KERNEL_MINIGZIP):= mgz
suffix-$(CONFIG_KERNEL_BZIP2)   := bz2
suffix-$(CONFIG_KERNEL_LZMA):= lzma
suffix-$(CONFIG_KERNEL_XZ)  := xz
diff --git a/arch/x86/boot/compressed/misc.c
b/arch/x86/boot/compressed/misc.c
index 434f077..4e55d32 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -125,7 +125,7 @@ static char *vidmem;
static int vidport;
static int lines, cols;

-#ifdef CONFIG_KERNEL_GZIP
+#if defined(CONFIG_KERNEL_GZIP) || defined(CONFIG_KERNEL_MINIGZIP)
#include "../../../../lib/decompress_inflate.c"
#endif

diff --git a/init/Kconfig b/init/Kconfig
index 3ecd8a1..818f225 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -100,6 +100,9 @@ config LOCALVERSION_AUTO
config HAVE_KERNEL_GZIP
bool

+config HAVE_KERNEL_MINIGZIP
+   bool
+
config HAVE_KERNEL_BZIP2
bool

@@ -118,7 +121,7 @@ config HAVE_KERNEL_LZ4
choice
prompt "Kernel compression mode"
default KERNEL_GZIP
-   depends on HAVE_KERNEL_GZIP || HAVE_KERNEL_BZIP2 || HAVE_KERNEL_LZMA
|| HAVE_KERNEL_XZ || HAVE_KERNEL_LZO || HAVE_KERNEL_LZ4
+   depends on HAVE_KERNEL_GZIP || HAVE_KERNEL_MINIGZIP ||
HAVE_KERNEL_BZIP2 || HAVE_KERNEL_LZMA || HAVE_KERNEL_XZ ||
HAVE_KERNEL_LZO || HAVE_KERNEL_LZ4
help
  The linux kernel is a kind of self-extracting executable.
  Several compression algorithms are available, which differ
@@ -144,6 +147,19 @@ config KERNEL_GZIP
  The old and tried gzip compression. It provides a good balance
  between compression ratio and decompression speed.

+config KERNEL_MINIGZIP
+   bool "Minigzip"
+   depends on HAVE_KERNEL_MINIGZIP
+   help
+ Use minigzip to compress the bzImage. This is very similar to gzip
+ but uses the zlib library to compress, rather than the very old
version
+ of zlib inside the gzip codebase. This is used for Android kernels
+ so that the same version of the deflate() algorithm is used when
+ building the kernel and constructing diffs with OTA applypatch,
which
+ uncompresses sections of files that it detects are gzipped before
computing
+ the diffs. If the versions of deflate() are out of alignment the
binary
+ diffs tend to be very large.
+
config KERNEL_BZIP2
bool "Bzip2"
depends on HAVE_KERNEL_BZIP2
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 49392ec..deb1bb8 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -240,6 +240,13 @@ quiet_cmd_gzip = GZIP$@
cmd_gzip = (cat $(filter-out FORCE,$^) | gzip -n -f -9 > 

RE: [Suggestion] arc: compiler: bug: about an arc compiler's bug which is not in gcc main source code.

[Francois Bedard]

Hi Chen,

Our sources are on github at 
https://github.com/foss-for-synopsys-dwc-arc-processors  and you can report 
problems by opening "Issues" with command lines and log outputs below against 
relevant toolchain component:

For GCC:  
https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/issues?state=open
For binutils: 
https://github.com/foss-for-synopsys-dwc-arc-processors/binutils/issues?page=1=open
 

Go ahead and officially file these and we'll take a look at them. 

Thanks,

Francois

-Original Message-
From: Chen Gang [mailto:gang.c...@asianux.com] 
Sent: Tuesday, October 22, 2013 7:00 PM
To: Vineet Gupta
Cc: jeremy.benn...@embecosm.com; linux-kernel@vger.kernel.org; Claudiu 
Zissulescu; Francois Bedard; joern Rennecke
Subject: Re: [Suggestion] arc: compiler: bug: about an arc compiler's bug which 
is not in gcc main source code.

On 09/23/2013 02:53 PM, Chen Gang wrote:
> On 09/23/2013 02:39 PM, Vineet Gupta wrote:
>> Hi Chen,
>>
...
>>
>> Jeremy, Claudiu, Joern maintain the gcc and rest of GNU toolchain 
>> ports for ARC so please add them to any future posting on toolchain issues.
>>


Firstly, sorry for so late to continue arc. Now I use latest tool-chain 
(content gcc-4.8.0) to compile kernel with allmodconfig, and find three tool 
chain issues (2 for gcc, 1 for binutils).

And also excuse me, I am still not quite sure where I should sent these 
information to, although you have mentioned some valuable information.

I just list the issue details below, if necessary, please provide more details 
where these information should be sent to (e.g. bugzilla), and I will/should 
follow and work with related tool chain guys. thanks.


-information begin

Operation:

  for Linux next-20130927 tree
  make ARCH=arc CROSS_COMPILE=/usr/local/bin/arc-elf32- allmodconfig
  make ARCH=arc CROSS_COMPILE=/usr/local/bin/arc-elf32-

Binutils (1 issue, ld and as information):

  when calling panic(), printk(), or memset() with R_ARC_S21W_PCREL, it may be 
overflow (I guess it need be R_ARC_S25W_PCREL).

  /usr/local/bin/arc-elf32-ld --build-id -X -o .tmp_vmlinux1 -T 
/android/public-kernel/linux-next/arch/arc/kernel/vmlinux.lds 
arch/arc/kernel/head.o init/built-in.o --start-group usr/built-in.o 
arch/arc/built-in.o arch/arc/boot/dts/built-in.o 
arch/arc/plat-arcfpga/built-in.o arch/arc/plat-tb10x/built-in.o 
kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o 
security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a 
arch/arc/lib/lib.a /usr/local/lib/gcc/arc-elf32/4.8.0/libgcc.a lib/built-in.o 
arch/arc/lib/built-in.o /usr/local/lib/gcc/arc-elf32/4.8.0/libgcc.a 
drivers/built-in.o sound/built-in.o firmware/built-in.o net/built-in.o 
--end-group
  /usr/local/bin/arc-elf32-ld: Error: Overflow detected in relocation value;
  /usr/local/bin/arc-elf32-ld: Relocation value should be between 1048575 and 
-1048576 whereas it  2404264
  /usr/local/bin/arc-elf32-ld: Global symbol: "panic".
  /usr/local/bin/arc-elf32-ld:
  Relocation type is:R_ARC_S21W_PCREL
  FileName:arch/arc/built-in.o
  Section Name:.text
  Offset in Section:1716
  /usr/local/bin/arc-elf32-ld: final link failed: Bad value
  make: *** [vmlinux] Error 1

  [root@gchenlinux binutils]# arc-elf32-ld -v
  GNU ld (GNU Binutils) 2.23.2

  [root@gchenlinux binutils]# arc-elf32-as -v
  GNU assembler version 2.23.2 (arc-elf32) using BFD version (GNU Binutils) 
2.23.2

GCC (2 issues, and gcc information):

CC  drivers/rtc/systohc.o
  drivers/rtc/systohc.c: In function 'rtc_set_ntp_time':
  drivers/rtc/systohc.c:44:1: internal compiler error: in arc_ifcvt, at 
config/arc/arc.c:8315
   }
   ^
  0x939c94 arc_ifcvt
../../gcc/gcc/config/arc/arc.c:8315
  0x93a394 arc_reorg
../../gcc/gcc/config/arc/arc.c:5985
  0x7517d9 rest_of_handle_machine_reorg
../../gcc/gcc/reorg.c:3927
  Please submit a full bug report,
  with preprocessed source if appropriate.
  Please include the complete backtrace with any bug report.
  See  for instructions.
  make[2]: *** [drivers/rtc/systohc.o] Error 1
  make[1]: *** [drivers/rtc] Error 2
  make: *** [drivers] Error 2
  
  
CC [M]  drivers/target/target_core_pr.o
  drivers/target/target_core_pr.c: In function 'target_scsi3_emulate_pr_in':
  drivers/target/target_core_pr.c:4033:1: error: unrecognizable insn:
   }
   ^
  (insn 846 194 196 12 (set (reg:QI 1 r1)
  (subreg:QI (mem/j/c:DI (plus:SI (reg/v/f:SI 2 r2 [orig:199 pr_reg ] 
[199])
  (const_int 576 [0x240])) [0 pr_reg_50->pr_res_key+0 S8 
A32]) 7)) drivers/target/target_core_pr.c:3677 -1
   (nil))
  drivers/target/target_core_pr.c:4033:1: internal compiler error: in 
extract_insn, at recog.c:2151
  0x758fb5 _fatal_insn(char const*, rtx_def const*, char const*, int, char 
const*)
../../gcc/gcc/rtl-error.c:109
  0x758fe9 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)

Re: [PATCH] x86: intel-mid: add Merrifield platform support

[David Cohen]

On 10/22/2013 05:49 PM, Yang, Fei wrote:

+   if (intel_mid_identify_cpu() ==
+   INTEL_MID_CPU_CHIP_TANGIER) {
+   if (!strncmp(pentry->name,
+   "r69001-ts-i2c", 13))
+   /* active low */
+   irq_attr.polarity = 1;
+   else if (!strncmp(pentry->name,
+   "synaptics_3202", 14))
+   /* active low */
+   irq_attr.polarity = 1;
+   else if (irq == 41)
+   /* fast_int_1 */
+   irq_attr.polarity = 1;

Do you really want to upstream these very hardware specific hacks? It's needed 
for
Saltbay, but might not be correct for other Merrifield based hardware, if any.


At this very initial moment we do want to support saltbay, which is the
main reference for Merrifield. So we can't run away from the ugly hack :)
Later, when we upstream the support to detect specific intel mid board
details, this code will be isolated for saltbay (and maybe other
required boards) and won't affect Merrifield in general.

Br, David Cohen

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [sched] WARNING: CPU: 0 PID: 3166 at kernel/cpu.c:84 put_online_cpus()

[Michael wang]

On 10/23/2013 05:24 AM, Fengguang Wu wrote:
[snip]
> 
>> @@ -3716,7 +3716,6 @@ long sched_setaffinity(pid_t pid, const struct cpumask 
>> *in_mask)
>>  p = find_process_by_pid(pid);
>>  if (!p) {
>>  rcu_read_unlock();
>> -put_online_cpus();
>>  return -ESRCH;
> 
> Yes, it fixed the WARNING.
> 
> Tested-by: Fengguang Wu 

Thanks for the testing :)

> 
> // The tests was queued for Michael Wang and have just finished.
> 
> There seems show up a new unreliable error "BUG:kernel_test_crashed".
> I'll increase test runs to confirm whether it's a new bug.

I guess it will be a new thread when get confirmed, let's fix this easy
one firstly, will send a formal patch later.

Regards,
Michael Wang

> 
> /kernel/x86_64-lkp/686c61a262ef88fdbc81c4d18bd0fcfc904d3f3e   
>
> +--+---+--+--+
> | 
>  | v3.12-rc4 | 6acce3ef8452 | 686c61a262ef |
> +--+---+--+--+
> | good_boots  
>  | 539   | 0| 16   |
> | has_kernel_error_warning
>  | 24| 20   | 1|
> | INFO:task_blocked_for_more_than_seconds 
>  | 14|  |  |
> | 
> WARNING:CPU:PID:at_arch/x86/kernel/cpu/perf_event_intel.c:intel_pmu_handle_irq()
>  | 1 |  |  |
> | INFO:NMI_handler(perf_event_nmi_handler)took_too_long_to_run:msecs  
>  | 1 |  |  |
> | XFS(vde):xlog_verify_grant_tail:space_BBTOB(tail_blocks)
>  | 5 |  |  |
> | Corruption_detected.Unmount_and_run_xfs_repair  
>  | 5 |  |  |
> | metadata_I/O_error:block(xfs_trans_read_buf_map)error_numblks   
>  | 5 |  |  |
> | BUG:kernel_test_hang
>  | 3 |  |  |
> | WARNING:CPU:PID:at_kernel/cpu.c:put_online_cpus()   
>  | 0 | 20   |  |
> | BUG:kernel_test_crashed 
>  | 0 | 0| 1|
> +--+---+--+--+
> 
> /kernel/x86_64-lkp-CONFIG_SCHED_DEBUG/686c61a262ef88fdbc81c4d18bd0fcfc904d3f3e
>   
> ++---+--+--+
> | 
>| v3.12-rc4 | 6acce3ef8452 | 686c61a262ef |
> ++---+--+--+
> | good_boots  
>| 39| 0| 16   |
> | has_kernel_error_warning
>| 0 | 20   |  |
> | INFO:rcu_sched_self-detected_stall_on_CPU(t=jiffies_g=c=q=) 
>| 0 | 1|  |
> | INFO:task_blocked_for_more_than_seconds 
>| 0 | 6|  |
> | 
> INFO:NMI_handler(arch_trigger_all_cpu_backtrace_handler)took_too_long_to_run:msecs
>  | 0 | 3|  |
> | Kernel_panic-not_syncing:hung_task:blocked_tasks
>| 0 | 3|  |
> | WARNING:CPU:PID:at_kernel/cpu.c:put_online_cpus()   
>| 0 | 12   |  |
> | BUG:kernel_test_crashed 
>| 0 | 1|  |
> ++---+--+--+
> 
> /kernel/x86_64-lkp-CONFIG_SCSI_DEBUG/686c61a262ef88fdbc81c4d18bd0fcfc904d3f3e
> 
> +--+---+--+--+
> |  | 
> v3.12-rc4 | 6acce3ef8452 | 686c61a262ef |
> +--+---+--+--+
> | good_boots   

Re: [Suggestion] arc: compiler: bug: about an arc compiler's bug which is not in gcc main source code.

[Joern Rennecke]

On 23 October 2013 03:00, Chen Gang  wrote:

> Binutils (1 issue, ld and as information):
>
>   when calling panic(), printk(), or memset() with R_ARC_S21W_PCREL, it may 
> be overflow (I guess it need be R_ARC_S25W_PCREL).
>
>   /usr/local/bin/arc-elf32-ld --build-id -X -o .tmp_vmlinux1 -T 
> /android/public-kernel/linux-next/arch/arc/kernel/vmlinux.lds 
> arch/arc/kernel/head.o init/built-in.o --start-group usr/built-in.o 
> arch/arc/built-in.o arch/arc/boot/dts/built-in.o 
> arch/arc/plat-arcfpga/built-in.o arch/arc/plat-tb10x/built-in.o 
> kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o 
> security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a 
> arch/arc/lib/lib.a /usr/local/lib/gcc/arc-elf32/4.8.0/libgcc.a lib/built-in.o 
> arch/arc/lib/built-in.o /usr/local/lib/gcc/arc-elf32/4.8.0/libgcc.a 
> drivers/built-in.o sound/built-in.o firmware/built-in.o net/built-in.o 
> --end-group
>   /usr/local/bin/arc-elf32-ld: Error: Overflow detected in relocation value;
>   /usr/local/bin/arc-elf32-ld: Relocation value should be between 1048575 and 
> -1048576 whereas it  2404264
>   /usr/local/bin/arc-elf32-ld: Global symbol: "panic".
>   /usr/local/bin/arc-elf32-ld:
>   Relocation type is:R_ARC_S21W_PCREL
>   FileName:arch/arc/built-in.o
>   Section Name:.text
>   Offset in Section:1716
>   /usr/local/bin/arc-elf32-ld: final link failed: Bad value
>   make: *** [vmlinux] Error 1

That just means that the image is too large to allow conditional
pc-relative calls (tail/sibcalls) or otherwise.

You can avoid generating them for functions with out a relevant
attribute with -mmedium-calls .



> GCC (2 issues, and gcc information):
>
> CC  drivers/rtc/systohc.o
>   drivers/rtc/systohc.c: In function 'rtc_set_ntp_time':
>   drivers/rtc/systohc.c:44:1: internal compiler error: in arc_ifcvt, at 
> config/arc/arc.c:8315
>}
>^
>   0x939c94 arc_ifcvt
> ../../gcc/gcc/config/arc/arc.c:8315
>   0x93a394 arc_reorg
> ../../gcc/gcc/config/arc/arc.c:5985
>   0x7517d9 rest_of_handle_machine_reorg
> ../../gcc/gcc/reorg.c:3927
>   Please submit a full bug report,
>   with preprocessed source if appropriate.
>   Please include the complete backtrace with any bug report.
>   See  for instructions.
>   make[2]: *** [drivers/rtc/systohc.o] Error 1
>   make[1]: *** [drivers/rtc] Error 2
>   make: *** [drivers] Error 2
>
>
> CC [M]  drivers/target/target_core_pr.o
>   drivers/target/target_core_pr.c: In function 'target_scsi3_emulate_pr_in':
>   drivers/target/target_core_pr.c:4033:1: error: unrecognizable insn:
>}
>^
>   (insn 846 194 196 12 (set (reg:QI 1 r1)
>   (subreg:QI (mem/j/c:DI (plus:SI (reg/v/f:SI 2 r2 [orig:199 pr_reg ] 
> [199])
>   (const_int 576 [0x240])) [0 pr_reg_50->pr_res_key+0 S8 
> A32]) 7)) drivers/target/target_core_pr.c:3677 -1
>(nil))
>   drivers/target/target_core_pr.c:4033:1: internal compiler error: in 
> extract_insn, at recog.c:2151
>   0x758fb5 _fatal_insn(char const*, rtx_def const*, char const*, int, char 
> const*)
> ../../gcc/gcc/rtl-error.c:109
>   0x758fe9 _fatal_insn_not_found(rtx_def const*, char const*, int, char 
> const*)
> ../../gcc/gcc/rtl-error.c:117
>   0x726e83 extract_insn(rtx_def*)
> ../../gcc/gcc/recog.c:2151
>   0x726ef4 extract_insn_cached(rtx_def*)
> ../../gcc/gcc/recog.c:2054
>   0x5fe026 cleanup_subreg_operands(rtx_def*)
> ../../gcc/gcc/final.c:3305
>   0x750c2e reload(rtx_def*, int)
> ../../gcc/gcc/reload1.c:1240
>   0x68e703 do_reload
> ../../gcc/gcc/ira.c:4631
>   0x68e703 rest_of_handle_reload
> ../../gcc/gcc/ira.c:4731
>   Please submit a full bug report,
>   with preprocessed source if appropriate.
>   Please include the complete backtrace with any bug report.
>   See  for instructions.
>   make[2]: *** [drivers/target/target_core_pr.o] Error 1
>   make[1]: *** [drivers/target] Error 2
>   make: *** [drivers] Error 2

Can these issues be reproduced with the lastest gcc version?  If so,
can you provide preprocessed source of the testcases and the compiler
flags to trigger the ICEs?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] mm,vdso: preallocate new vmas

[Davidlohr Bueso]

On Tue, 2013-10-22 at 08:48 -0700, wal...@google.com wrote:
> On Thu, Oct 17, 2013 at 05:50:35PM -0700, Davidlohr Bueso wrote:
> > Linus recently pointed out[1] some of the amount of unnecessary work 
> > being done with the mmap_sem held. This patchset is a very initial 
> > approach on reducing some of the contention on this lock, and moving
> > work outside of the critical region.
> > 
> > Patch 1 adds a simple helper function.
> > 
> > Patch 2 moves out some trivial setup logic in mlock related calls.
> > 
> > Patch 3 allows managing new vmas without requiring the mmap_sem for
> > vdsos. While it's true that there are many other scenarios where
> > this can be done, few are actually as straightforward as this in the
> > sense that we *always* end up allocating memory anyways, so there's really
> > no tradeoffs. For this reason I wanted to get this patch out in the open.
> > 
> > There are a few points to consider when preallocating vmas at the start
> > of system calls, such as how many new vmas (ie: callers of split_vma can
> > end up calling twice, depending on the mm state at that point) or the 
> > probability
> > that we end up merging the vma instead of having to create a new one, like 
> > the 
> > case of brk or copy_vma. In both cases the overhead of creating and freeing
> > memory at every syscall's invocation might outweigh what we gain in not 
> > holding
> > the sem.
> 
> Hi Davidlohr,
> 
> I had a quick look at the patches and I don't see anything wrong with them.
> However, I must also say that I have 99 problems with mmap_sem and the one
> you're solving doesn't seem to be one of them, so I would be interested to
> see performance numbers showing how much difference these changes make.
> 

Thanks for taking a look, could I get your ack? Unless folks have any
problems with the patchset, I do think it's worth picking up...

As discussed with Ingo, the numbers aren't too exciting, mainly because
of the nature of vdsos: with all patches combined I'm getting roughly
+5% throughput boost on some aim7 workloads. This was a first attempt at
dealing with the new vma allocation we do with the mmap_sem held. I've
recently explored some of the options I mentioned above, like for
brk(2). Unfortunately I haven't gotten good results; for instance we get
a -15% hit in ops/sec with aim9's brk_test program. So we end up using
already existing vmas a lot more than creating new ones, which makes a
lot of sense anyway. So all in all I don't think that preallocating vmas
outside the lock is a path to go, even at a micro-optimization level,
except for vdsos.

> Generally the problems I see with mmap_sem are related to long latency
> operations. Specifically, the mmap_sem write side is currently held
> during the entire munmap operation, which iterates over user pages to
> free them, and can take hundreds of milliseconds for large VMAs. Also,
> the mmap_sem read side is held during user page fauls - well, the
> VM_FAULT_RETRY mechanism allows us to drop mmap_sem during major page
> faults, but it is still held while allocating user pages or page tables,
> and while going through FS code for asynchronous readahead, which turns
> out not to be as asynchronous as you'd think as it can still block for
> reading extends etc... So, generally the main issues I am seeing with
> mmap_sem are latency related, while your changes only help for throughput
> for workloads that don't hit the above latency issues. I think that's a
> valid thing to do but I'm not sure if common workloads hit these throughput
> issues today ?

IMHO munmap is just one more example where having one big fat lock for
serializing an entire address space is something that must be addressed
(and, as you mention, mmap_sem doesn't even limit itself only to vmas -
heck... we even got it protecting superpage faults). For instance, it
would be really nice if we could somehow handle rbtrees with RCU, and
avoid taking any locks for things like lookups (ie: find_vma), of course
we need to guarantee that the vma won't be free'd underneath us one it's
found :) Or event allow concurrent updates and rebalancing - nonetheless
I don't know how realistic such things can be in the kernel.

> 
> > [1] https://lkml.org/lkml/2013/10/9/665 
> 
> Eh, that post really makes it look easy doesn't it :)
> 
> There are a few complications with mmap_sem as it turns out to protect
> more than just the VMA structures. For example, mmap_sem plays a role
> in preventing page tables from being unmapped while follow_page_mask()
> reads through them (there are other arch specific ways to do that,
> like disabling local interrupts on x86 to prevent TLB shootdown, but
> none that are currently available in generic code). This isn't an
> issue with your current proposed patches but is something you need to
> be aware of if you're going to do more work around the mmap_sem issues
> (which I would encourage you to BTW - there are a lot of issues around
> mmap_sem, so it definitely helps to 

Re: [sched] WARNING: CPU: 0 PID: 3166 at kernel/cpu.c:84 put_online_cpus()

[Michael wang]

On 10/23/2013 04:46 AM, Peter Zijlstra wrote:
> On Mon, Oct 21, 2013 at 11:28:30AM +0800, Michael wang wrote:
>> Hi, Fengguang
>>
>> On 10/19/2013 08:51 AM, Fengguang Wu wrote:
>>> Greetings,
>>
>> Will this do any helps?
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index c06b8d3..7c61f31 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -3716,7 +3716,6 @@ long sched_setaffinity(pid_t pid, const struct
>> cpumask *in_mask)
>> p = find_process_by_pid(pid);
>> if (!p) {
>> rcu_read_unlock();
>> -   put_online_cpus();
>> return -ESRCH;
>> }
> 
> Just so..

Yeah... anyway, will send out a formal patch later :)

Regards,
Michael Wang

> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 11/11] asmlinkage, wan/sbni: Make inline assembler symbols visible and assembler global

[Andi Kleen]

> How about scheduling the WAN drivers for removal? Does anybody
> actually use them nowadays?

Perhaps at least the ISA devices? ISA hardware should be nearing
end of live by now.

Looking at the git log there doesn't seem to be any real changes,
other than tree sweeps or build fixes.

But I must admit I don't really know much about them.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] arc: kernel: remove '__init' for first_lines_of_secondary()

[Chen Gang]

first_lines_of_secondary() is a '__init' function, but it may be called
by __cpu_up() by _cpu_up() by cpu_up() which is a normal export symbol
function. So recommend to remove '__init'.

The related warning (with allmodconfig):

MODPOST vmlinux.o
  WARNING: vmlinux.o(.text+0x315c): Section mismatch in reference from the 
function __cpu_up() to the function .init.text:first_lines_of_secondary()
  The function __cpu_up() references
  the function __init first_lines_of_secondary().
  This is often because __cpu_up lacks a __init
  annotation or the annotation of first_lines_of_secondary is wrong.


Signed-off-by: Chen Gang 
---
 arch/arc/include/asm/smp.h |2 +-
 arch/arc/kernel/head.S |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arc/include/asm/smp.h b/arch/arc/include/asm/smp.h
index c4fb211..eefc29f 100644
--- a/arch/arc/include/asm/smp.h
+++ b/arch/arc/include/asm/smp.h
@@ -30,7 +30,7 @@ extern void arch_send_call_function_ipi_mask(const struct 
cpumask *mask);
  * APIs provided by arch SMP code to rest of arch code
  */
 extern void __init smp_init_cpus(void);
-extern void __init first_lines_of_secondary(void);
+extern void first_lines_of_secondary(void);
 extern const char *arc_platform_smp_cpuinfo(void);
 
 /*
diff --git a/arch/arc/kernel/head.S b/arch/arc/kernel/head.S
index 0f944f0..2c878e9 100644
--- a/arch/arc/kernel/head.S
+++ b/arch/arc/kernel/head.S
@@ -95,7 +95,7 @@ stext:
 ;
 ; First lines of code run by secondary before jumping to 'C'
 ;
-   .section .init.text, "ax",@progbits
+   .section .text, "ax",@progbits
.type first_lines_of_secondary, @function
.globl first_lines_of_secondary
 
-- 
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 12/12] EFI: Runtime services virtual mapping

[Dave Young]

On 10/22/13 at 01:18pm, Borislav Petkov wrote:
> On Mon, Oct 21, 2013 at 11:04:26PM +0800, Dave Young wrote:
> > > You need this to map the runtime regions in the kexec kernel, right?
> > > Please write that in the commit message.
> > 
> > Yes, will do
> 
> Ok, but but, why doesn't the normal code path in efi_enter_virtual_mode
> work anymore? I mean, why do you need another function instead of doing
> what you did previously:
> 
>   if (!kexec)
>   phys_efi_set_virtual_address_map(...)
> 
> The path up to here does the mapping already anyway so you only need to
> do the mapping in the kexec kernel and skip set set_virtual_map thing.

Hi,

The reason is that I only pass runtime regions from 1st kernel to kexec
kernel, your efi mapping function uses the region size to determin the 
virtual address from top to down. Because the passed-in md ranges in kexec
kernel are different from ranges booting from firmware so the virtual address
will be different.

Even I pass the whole untouched ranges including BOOT_SERVICE there's still
chance the function for reserving boot regions overwrite the boot region
size to 0, and 1st kernel will leave it to be used as normal memory after efi 
init.
I think we have talked about this issue previously.

Thanks
Dave


> 
> Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How to set fops in "struct platform_pwm_backlight_data"?

[Mark Zhang]

On 10/22/2013 08:49 PM, Thierry Reding wrote:
> On Tue, Oct 22, 2013 at 04:55:09PM +0800, Mark Zhang wrote:
>> On 10/22/2013 03:24 PM, Thierry Reding wrote:
>>> On Fri, Oct 18, 2013 at 12:48:12PM +0800, Mark Zhang wrote:
>> [...]
>

 Okay, I just want to set the "notify" function pointer in "struct
 platform_pwm_backlight_data", because I want to tune the brightness
 value before the pwm-bl sets the brightness to hardware. I don't know
 how to do that, unless we define the platform data explicitly.
>>>
>>> Okay, my question should have been what you need the functions for and
>>> why you think you need them.
>>>
>>
>> If I understanding you correctly, I suppose I've said that: "because I
>> want to tune the brightness value before the pwm-bl sets the brightness
>> to hardware".
> 
> Why do you want to tune the brightness value? What are you trying to
> achieve?
> 

Oh, Tegra has a feature named PRISM(aka SmartDimmer). It changes the
color value to make the display looks bright so that we can reduce the
backlight brightness to save power. So everytime PRISM is triggered, we
call "backlight_update_status", then in the "notify" callback, we change
the brightness value which pwm-bl provides by considering the PRISM
compensations.

Mark
> Thierry
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 11/11] asmlinkage, wan/sbni: Make inline assembler symbols visible and assembler global

[Florian Fainelli]

2013/10/22 Andi Kleen :
> On Tue, Oct 22, 2013 at 01:59:28PM -0400, David Miller wrote:
>> From: Andi Kleen 
>> Date: Tue, 22 Oct 2013 09:12:26 -0700
>>
>> > From: Andi Kleen 
>> >
>> > - Inline assembler defining C callable code has to be global
>> > - The function has to be visible
>> >
>> > Do this in wan/sbni
>> >
>> > Cc: net...@vger.kernel.org
>> > Signed-off-by: Andi Kleen 
>>
>> Is it really impossible to use the generic crc32 support instead of this
>> unsightly custom inline assembler?
>
> Yes it's impossible.
>
> There's no way for me to test it, and this would be a far too big change
> to submit untested.
>
> Also my only interest here is this thing not breaking my LTO
> allyesconfig build. I'm not even sure what it does.
>
> Just because some legacy driver breaks my build you cannot make me
> accountable for maintaining it now.
>
> If it's not possible to get this trivial change in I would need
> to mark it "depends on !LTO" in Kconfig.

How about scheduling the WAN drivers for removal? Does anybody
actually use them nowadays?
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 06/11] asmlinkage: Make trace_hardirq visible

[Andi Kleen]

> $sub talks about asmlinkage, yet here you insert __visible; 'sup?

I use __visible for anything with arguments, because asmlinkage
changes the ABI from register to stack on i386.

I still used "asmlinkage" as the generic patch group name as that is more
descriptive, and "asmlinkage/visible" would look too ugly.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] arc: include: asm: remove '__init' for setup_processor() and arc_init_IRQ()

[Chen Gang]

They haven't '__init' in definition, but has '__init' in declaration.
And normal function start_kernel_secondary() may call setup_processor()
which will call arc_init_IRQ().

So need remove '__init' for both of them. The related warning (with
allmodconfig):

MODPOST vmlinux.o
  WARNING: vmlinux.o(.text+0x3084): Section mismatch in reference from the 
function start_kernel_secondary() to the function .init.text:setup_processor()
  The function start_kernel_secondary() references
  the function __init setup_processor().
  This is often because start_kernel_secondary lacks a __init
  annotation or the annotation of setup_processor is wrong.


Signed-off-by: Chen Gang 
---
 arch/arc/include/asm/irq.h   |2 +-
 arch/arc/include/asm/setup.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arc/include/asm/irq.h b/arch/arc/include/asm/irq.h
index c0a7210..548207f 100644
--- a/arch/arc/include/asm/irq.h
+++ b/arch/arc/include/asm/irq.h
@@ -18,7 +18,7 @@
 
 #include 
 
-extern void __init arc_init_IRQ(void);
+extern void arc_init_IRQ(void);
 extern int __init get_hw_config_num_irq(void);
 
 void arc_local_timer_setup(unsigned int cpu);
diff --git a/arch/arc/include/asm/setup.h b/arch/arc/include/asm/setup.h
index 229e506..e10f8ce 100644
--- a/arch/arc/include/asm/setup.h
+++ b/arch/arc/include/asm/setup.h
@@ -31,7 +31,7 @@ struct cpuinfo_data {
 extern int root_mountflags, end_mem;
 extern int running_on_hw;
 
-void __init setup_processor(void);
+void setup_processor(void);
 void __init setup_arch_memory(void);
 
 #endif /* __ASMARC_SETUP_H */
-- 
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: wan: sbni: remove assembly crc32 code

[Andi Kleen]

On Tue, Oct 22, 2013 at 08:36:25PM +0200, Sebastian Andrzej Siewior wrote:
> 
> There is also a C function doing the same thing. Unless the asm code is
> 110% faster we could stick to the C function.

I have no idea if it is or not. But doing it this way would be
acceptable for me.

Thanks for the patch.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 11/11] asmlinkage, wan/sbni: Make inline assembler symbols visible and assembler global

[Andi Kleen]

On Tue, Oct 22, 2013 at 01:59:28PM -0400, David Miller wrote:
> From: Andi Kleen 
> Date: Tue, 22 Oct 2013 09:12:26 -0700
> 
> > From: Andi Kleen 
> > 
> > - Inline assembler defining C callable code has to be global
> > - The function has to be visible
> > 
> > Do this in wan/sbni
> > 
> > Cc: net...@vger.kernel.org
> > Signed-off-by: Andi Kleen 
> 
> Is it really impossible to use the generic crc32 support instead of this
> unsightly custom inline assembler?

Yes it's impossible.

There's no way for me to test it, and this would be a far too big change
to submit untested.

Also my only interest here is this thing not breaking my LTO
allyesconfig build. I'm not even sure what it does.

Just because some legacy driver breaks my build you cannot make me
accountable for maintaining it now. 

If it's not possible to get this trivial change in I would need
to mark it "depends on !LTO" in Kconfig.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] arch: *: remove '__init' for setup_profiling_timer()

[Chen Gang]

Most of architectures not use '__init' for setup_profiling_timer(), so
need remove it, or can generate warning (e.g. arc with allmodconfig):

MODPOST vmlinux.o
  WARNING: vmlinux.o(.text+0x3c682): Section mismatch in reference from the 
function write_profile() to the function .init.text:setup_profiling_timer()
  The function write_profile() references
  the function __init setup_profiling_timer().
  This is often because write_profile lacks a __init
  annotation or the annotation of setup_profiling_timer is wrong.


Signed-off-by: Chen Gang 
---
 arch/arc/kernel/smp.c  |2 +-
 arch/blackfin/mach-bf561/smp.c |2 +-
 arch/parisc/kernel/smp.c   |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arc/kernel/smp.c b/arch/arc/kernel/smp.c
index bca3052..3bdac11 100644
--- a/arch/arc/kernel/smp.c
+++ b/arch/arc/kernel/smp.c
@@ -187,7 +187,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *idle)
 /*
  * not supported here
  */
-int __init setup_profiling_timer(unsigned int multiplier)
+int setup_profiling_timer(unsigned int multiplier)
 {
return -EINVAL;
 }
diff --git a/arch/blackfin/mach-bf561/smp.c b/arch/blackfin/mach-bf561/smp.c
index 11789be..3bef058 100644
--- a/arch/blackfin/mach-bf561/smp.c
+++ b/arch/blackfin/mach-bf561/smp.c
@@ -43,7 +43,7 @@ void __init platform_prepare_cpus(unsigned int max_cpus)
init_cpu_present();
 }
 
-int __init setup_profiling_timer(unsigned int multiplier) /* not supported */
+int setup_profiling_timer(unsigned int multiplier) /* not supported */
 {
return -EINVAL;
 }
diff --git a/arch/parisc/kernel/smp.c b/arch/parisc/kernel/smp.c
index 8a252f2..2e8cd36 100644
--- a/arch/parisc/kernel/smp.c
+++ b/arch/parisc/kernel/smp.c
@@ -433,7 +433,7 @@ int __cpu_up(unsigned int cpu, struct task_struct *tidle)
 }
 
 #ifdef CONFIG_PROC_FS
-int __init
+int
 setup_profiling_timer(unsigned int multiplier)
 {
return -EINVAL;
-- 
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Suggestion] arc: compiler: bug: about an arc compiler's bug which is not in gcc main source code.

[Chen Gang]

On 09/23/2013 02:53 PM, Chen Gang wrote:
> On 09/23/2013 02:39 PM, Vineet Gupta wrote:
>> Hi Chen,
>>
...
>>
>> Jeremy, Claudiu, Joern maintain the gcc and rest of GNU toolchain ports for 
>> ARC so
>> please add them to any future posting on toolchain issues.
>>


Firstly, sorry for so late to continue arc. Now I use latest tool-chain
(content gcc-4.8.0) to compile kernel with allmodconfig, and find three
tool chain issues (2 for gcc, 1 for binutils).

And also excuse me, I am still not quite sure where I should sent these
information to, although you have mentioned some valuable information.

I just list the issue details below, if necessary, please provide more
details where these information should be sent to (e.g. bugzilla), and
I will/should follow and work with related tool chain guys. thanks.


-information begin

Operation:

  for Linux next-20130927 tree
  make ARCH=arc CROSS_COMPILE=/usr/local/bin/arc-elf32- allmodconfig
  make ARCH=arc CROSS_COMPILE=/usr/local/bin/arc-elf32-

Binutils (1 issue, ld and as information):

  when calling panic(), printk(), or memset() with R_ARC_S21W_PCREL, it may be 
overflow (I guess it need be R_ARC_S25W_PCREL).

  /usr/local/bin/arc-elf32-ld --build-id -X -o .tmp_vmlinux1 -T 
/android/public-kernel/linux-next/arch/arc/kernel/vmlinux.lds 
arch/arc/kernel/head.o init/built-in.o --start-group usr/built-in.o 
arch/arc/built-in.o arch/arc/boot/dts/built-in.o 
arch/arc/plat-arcfpga/built-in.o arch/arc/plat-tb10x/built-in.o 
kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o 
security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a 
arch/arc/lib/lib.a /usr/local/lib/gcc/arc-elf32/4.8.0/libgcc.a lib/built-in.o 
arch/arc/lib/built-in.o /usr/local/lib/gcc/arc-elf32/4.8.0/libgcc.a 
drivers/built-in.o sound/built-in.o firmware/built-in.o net/built-in.o 
--end-group
  /usr/local/bin/arc-elf32-ld: Error: Overflow detected in relocation value;
  /usr/local/bin/arc-elf32-ld: Relocation value should be between 1048575 and 
-1048576 whereas it  2404264
  /usr/local/bin/arc-elf32-ld: Global symbol: "panic".
  /usr/local/bin/arc-elf32-ld:
  Relocation type is:R_ARC_S21W_PCREL
  FileName:arch/arc/built-in.o
  Section Name:.text
  Offset in Section:1716
  /usr/local/bin/arc-elf32-ld: final link failed: Bad value
  make: *** [vmlinux] Error 1

  [root@gchenlinux binutils]# arc-elf32-ld -v
  GNU ld (GNU Binutils) 2.23.2

  [root@gchenlinux binutils]# arc-elf32-as -v
  GNU assembler version 2.23.2 (arc-elf32) using BFD version (GNU Binutils) 
2.23.2

GCC (2 issues, and gcc information):

CC  drivers/rtc/systohc.o
  drivers/rtc/systohc.c: In function 'rtc_set_ntp_time':
  drivers/rtc/systohc.c:44:1: internal compiler error: in arc_ifcvt, at 
config/arc/arc.c:8315
   }
   ^
  0x939c94 arc_ifcvt
../../gcc/gcc/config/arc/arc.c:8315
  0x93a394 arc_reorg
../../gcc/gcc/config/arc/arc.c:5985
  0x7517d9 rest_of_handle_machine_reorg
../../gcc/gcc/reorg.c:3927
  Please submit a full bug report,
  with preprocessed source if appropriate.
  Please include the complete backtrace with any bug report.
  See  for instructions.
  make[2]: *** [drivers/rtc/systohc.o] Error 1
  make[1]: *** [drivers/rtc] Error 2
  make: *** [drivers] Error 2
  
  
CC [M]  drivers/target/target_core_pr.o
  drivers/target/target_core_pr.c: In function 'target_scsi3_emulate_pr_in':
  drivers/target/target_core_pr.c:4033:1: error: unrecognizable insn:
   }
   ^
  (insn 846 194 196 12 (set (reg:QI 1 r1)
  (subreg:QI (mem/j/c:DI (plus:SI (reg/v/f:SI 2 r2 [orig:199 pr_reg ] 
[199])
  (const_int 576 [0x240])) [0 pr_reg_50->pr_res_key+0 S8 
A32]) 7)) drivers/target/target_core_pr.c:3677 -1
   (nil))
  drivers/target/target_core_pr.c:4033:1: internal compiler error: in 
extract_insn, at recog.c:2151
  0x758fb5 _fatal_insn(char const*, rtx_def const*, char const*, int, char 
const*)
../../gcc/gcc/rtl-error.c:109
  0x758fe9 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:117
  0x726e83 extract_insn(rtx_def*)
../../gcc/gcc/recog.c:2151
  0x726ef4 extract_insn_cached(rtx_def*)
../../gcc/gcc/recog.c:2054
  0x5fe026 cleanup_subreg_operands(rtx_def*)
../../gcc/gcc/final.c:3305
  0x750c2e reload(rtx_def*, int)
../../gcc/gcc/reload1.c:1240
  0x68e703 do_reload
../../gcc/gcc/ira.c:4631
  0x68e703 rest_of_handle_reload
../../gcc/gcc/ira.c:4731
  Please submit a full bug report,
  with preprocessed source if appropriate.
  Please include the complete backtrace with any bug report.
  See  for instructions.
  make[2]: *** [drivers/target/target_core_pr.o] Error 1
  make[1]: *** [drivers/target] Error 2
  make: *** [drivers] Error 2
  
  
  [root@gchenlinux linux-next]# /usr/local/bin/arc-elf32-gcc -v
  Using built-in specs.
  

Re: [PATCH 9/9] backlight: atmel-pwm-bl: use gpio_request_one

[Jingoo Han]

On Wednesday, October 23, 2013 2:27 AM, Johan Hovold wrote:
> 
> Use devm_gpio_request_one rather than requesting and setting direction
> in two calls.
> 
> Signed-off-by: Johan Hovold 

Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
>  drivers/video/backlight/atmel-pwm-bl.c | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 8/9] backlight: atmel-pwm-bl: refactor gpio_on handling

[Jingoo Han]

On Wednesday, October 23, 2013 2:27 AM, Johan Hovold wrote:
> 
> Add helper function to control the gpio_on signal.
> 
> Signed-off-by: Johan Hovold 

Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
>  drivers/video/backlight/atmel-pwm-bl.c | 23 +++
>  1 file changed, 11 insertions(+), 12 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 7/9] backlight: atmel-pwm-bl: use gpio_is_valid

[Jingoo Han]

On Wednesday, October 23, 2013 2:27 AM, Johan Hovold wrote:
> 
> Use gpio_is_valid rather than open coding the more restrictive != -1
> test.
> 
> Signed-off-by: Johan Hovold 

Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
>  drivers/video/backlight/atmel-pwm-bl.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/9] backlight: atmel-pwm-bl: remove unused include

[Jingoo Han]

On Wednesday, October 23, 2013 2:27 AM, Johan Hovold wrote:
> 
> Remove unused include of clk.h.
> 
> Signed-off-by: Johan Hovold 

Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
>  drivers/video/backlight/atmel-pwm-bl.c | 1 -
>  1 file changed, 1 deletion(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/9] backlight: atmel-pwm-bl: clean up probe error handling

[Jingoo Han]

On Wednesday, October 23, 2013 2:27 AM, Johan Hovold wrote:
> 
> Clean up probe error handling by checking parameters before any
> allocations and removing an obsolete error label. Also remove
> unnecessary reset of private gpio number.
> 
> Signed-off-by: Johan Hovold 

Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
>  drivers/video/backlight/atmel-pwm-bl.c | 31 ---
>  1 file changed, 12 insertions(+), 19 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/9] backlight: atmel-pwm-bl: clean up get_intensity

[Jingoo Han]

On Wednesday, October 23, 2013 2:27 AM, Johan Hovold wrote:
> 
> Clean up get_intensity to increase readability.
> 
> Signed-off-by: Johan Hovold 

Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
>  drivers/video/backlight/atmel-pwm-bl.c | 13 ++---
>  1 file changed, 6 insertions(+), 7 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/9] backlight: atmel-pwm-bl: fix module autoload

[Jingoo Han]

On Wednesday, October 23, 2013 2:27 AM, Johan Hovold wrote:
> 
> Add missing module alias which is needed for module autoloading.
> 
> Signed-off-by: Johan Hovold 

Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
>  drivers/video/backlight/atmel-pwm-bl.c | 1 +
>  1 file changed, 1 insertion(+)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/9] backlight: atmel-pwm-bl: fix gpio polarity in remove

[Jingoo Han]

On Wednesday, October 23, 2013 2:27 AM, Johan Hovold wrote:
> 
> Make sure to honour gpio polarity also at remove so that the backlight
> is actually disabled on boards with active-low enable pin.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Johan Hovold 

Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
>  drivers/video/backlight/atmel-pwm-bl.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: MMC request with REQ_DISCARD option may not release host when it should

[Ray Jui]

Hi Seungwon,

Thanks for your reply. I'll try my best to find time and submit my patch within 
the next couple days.

Thanks,

Ray

-Original Message-
From: Seungwon Jeon [mailto:tgih@samsung.com] 
Sent: Tuesday, October 22, 2013 6:03 PM
To: Ray Jui; 'Chris Ball'
Cc: linux-kernel@vger.kernel.org
Subject: RE: MMC request with REQ_DISCARD option may not release host when it 
should

Hi Ray,

Thank you for information. Your analysis is right.
I also noticed same problem.
If you'd like to submit patch, not to report, please send it with regular form.
Or I could send similar patch I have.

Thanks,
Seungwon Jeon

On Wed, Oct 23, 2013, Ray Jui wrote:
Hi Seungwon/Chris,

We recently came across an eMMC issue that causes mmc_suspend to stuck waiting 
to claim the host. This issue only happens when one
of the MMC partitions is mounted with the discard option. By tracing the issue 
down in the kernel MMC stack, in the function
mmc_blk_issue_rq under drivers/mmc/card/block.c, we noticed the host will be 
released when req is valid and when req->cmd_flags is
set to one of the masks: MMC_REQ_SPECIAL_MASK. Based on the code comment, I 
believe the intention is to always release the host in
the case of special request (which include both REQ_DISCARD and REQ_FLUSH).

Note in function call mmc_blk_issue_discard_rq, the memory where req points to 
can be freed. This means at the bottom of the
mmc_blk_issue_rq, req->cmd_flags may contain garbage value and I believe this 
is what's causing the issue that we are seeing in
mmc_suspend after the discard operation: In mmc_suspend, it blocks waiting to 
claim the host but the host was never released after
the discard operation.

Please help to review the attached patch that fixes the issue.

Thanks,

Ray Jui



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/7] x86, asmlinkage, lguest: Pass in globals into assembler statement

[Rusty Russell]

Andi Kleen  writes:
> From: Andi Kleen 
>
> Tell the compiler that the inline assembler statement
> references lguest_entry.
>
> This fixes compile problems with LTO where the variable
> and the assembler code may end up in different files.
>
> Cc: x...@kernel.org
> Cc: ru...@rustcorp.com.au
> Signed-off-by: Andi Kleen 

Great, thanks.  Might as well keep this with the others:

Acked-by: Rusty Russell 
Tested-by: Rusty Russell 

Cheers,
Rusty.

> ---
>  drivers/lguest/x86/core.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/lguest/x86/core.c b/drivers/lguest/x86/core.c
> index 5169239..922a1ac 100644
> --- a/drivers/lguest/x86/core.c
> +++ b/drivers/lguest/x86/core.c
> @@ -157,7 +157,7 @@ static void run_guest_once(struct lg_cpu *cpu, struct 
> lguest_pages *pages)
>* stack, then the address of this call.  This stack layout happens to
>* exactly match the stack layout created by an interrupt...
>*/
> - asm volatile("pushf; lcall *lguest_entry"
> + asm volatile("pushf; lcall *%4"
>/*
> * This is how we tell GCC that %eax ("a") and %ebx ("b")
> * are changed by this routine.  The "=" means output.
> @@ -169,7 +169,9 @@ static void run_guest_once(struct lg_cpu *cpu, struct 
> lguest_pages *pages)
> * physical address of the Guest's top-level page
> * directory.
> */
> -  : "0"(pages), 
> "1"(__pa(cpu->lg->pgdirs[cpu->cpu_pgd].pgdir))
> +  : "0"(pages), 
> +"1"(__pa(cpu->lg->pgdirs[cpu->cpu_pgd].pgdir)),
> +"m"(lguest_entry)
>/*
> * We tell gcc that all these registers could change,
> * which means we don't have to save and restore them in
> -- 
> 1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/7] x86, asmlinkage, lguest: Fix C functions used by inline assembler

[Rusty Russell]

Andi Kleen  writes:
> From: Andi Kleen 
>
> - Make the C code used by the paravirt stubs visible
> - Since they have to be global now, give them a more unique
> name.
>
> Cc: ru...@rustcorp.com.au
> Cc: x...@kernel.org
> Signed-off-by: Andi Kleen 

Acked-by: Rusty Russell 

Cheers,
Rusty.

> ---
>  arch/x86/lguest/boot.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/lguest/boot.c b/arch/x86/lguest/boot.c
> index bdf8532..ad1fb5f 100644
> --- a/arch/x86/lguest/boot.c
> +++ b/arch/x86/lguest/boot.c
> @@ -233,13 +233,13 @@ static void lguest_end_context_switch(struct 
> task_struct *next)
>   * flags word contains all kind of stuff, but in practice Linux only cares
>   * about the interrupt flag.  Our "save_flags()" just returns that.
>   */
> -static unsigned long save_fl(void)
> +asmlinkage unsigned long lguest_save_fl(void)
>  {
>   return lguest_data.irq_enabled;
>  }
>  
>  /* Interrupts go off... */
> -static void irq_disable(void)
> +asmlinkage void lguest_irq_disable(void)
>  {
>   lguest_data.irq_enabled = 0;
>  }
> @@ -253,8 +253,8 @@ static void irq_disable(void)
>   * PV_CALLEE_SAVE_REGS_THUNK(), which pushes %eax onto the stack, calls the
>   * C function, then restores it.
>   */
> -PV_CALLEE_SAVE_REGS_THUNK(save_fl);
> -PV_CALLEE_SAVE_REGS_THUNK(irq_disable);
> +PV_CALLEE_SAVE_REGS_THUNK(lguest_save_fl);
> +PV_CALLEE_SAVE_REGS_THUNK(lguest_irq_disable);
>  /*:*/
>  
>  /* These are in i386_head.S */
> @@ -1291,9 +1291,9 @@ __init void lguest_init(void)
>*/
>  
>   /* Interrupt-related operations */
> - pv_irq_ops.save_fl = PV_CALLEE_SAVE(save_fl);
> + pv_irq_ops.save_fl = PV_CALLEE_SAVE(lguest_save_fl);
>   pv_irq_ops.restore_fl = __PV_IS_CALLEE_SAVE(lg_restore_fl);
> - pv_irq_ops.irq_disable = PV_CALLEE_SAVE(irq_disable);
> + pv_irq_ops.irq_disable = PV_CALLEE_SAVE(lguest_irq_disable);
>   pv_irq_ops.irq_enable = __PV_IS_CALLEE_SAVE(lg_irq_enable);
>   pv_irq_ops.safe_halt = lguest_safe_halt;
>  
> -- 
> 1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 07/11] asmlinkage, module: Make ksymtab and kcrctab symbols and __this_module __visible

[Rusty Russell]

Andi Kleen  writes:
> From: Andi Kleen 
>
> Make the ksymtab symbols for EXPORT_SYMBOL visible.
> This prevents the LTO compiler from adding a .NUMBER prefix,
> which avoids various problems in later export processing.

Applied, thanks.

Cheers,
Rusty.

> Cc: ru...@rustcorp.com.au
> Signed-off-by: Andi Kleen 
> ---
>  include/linux/export.h | 4 ++--
>  scripts/mod/modpost.c  | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/export.h b/include/linux/export.h
> index 412cd50..3f2793d 100644
> --- a/include/linux/export.h
> +++ b/include/linux/export.h
> @@ -43,7 +43,7 @@ extern struct module __this_module;
>  /* Mark the CRC weak since genksyms apparently decides not to
>   * generate a checksums for some symbols */
>  #define __CRC_SYMBOL(sym, sec)   \
> - extern void *__crc_##sym __attribute__((weak)); \
> + extern __visible void *__crc_##sym __attribute__((weak));   
> \
>   static const unsigned long __kcrctab_##sym  \
>   __used  \
>   __attribute__((section("___kcrctab" sec "+" #sym), unused)) \
> @@ -59,7 +59,7 @@ extern struct module __this_module;
>   static const char __kstrtab_##sym[] \
>   __attribute__((section("__ksymtab_strings"), aligned(1))) \
>   = VMLINUX_SYMBOL_STR(sym);  \
> - static const struct kernel_symbol __ksymtab_##sym   \
> + __visible const struct kernel_symbol __ksymtab_##sym\
>   __used  \
>   __attribute__((section("___ksymtab" sec "+" #sym), unused)) \
>   = { (unsigned long), __kstrtab_##sym }
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index 8247979..0971bac 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -1853,7 +1853,7 @@ static void add_header(struct buffer *b, struct module 
> *mod)
>   buf_printf(b, "\n");
>   buf_printf(b, "MODULE_INFO(vermagic, VERMAGIC_STRING);\n");
>   buf_printf(b, "\n");
> - buf_printf(b, "struct module __this_module\n");
> + buf_printf(b, "__visible struct module __this_module\n");
>   buf_printf(b, "__attribute__((section(\".gnu.linkonce.this_module\"))) 
> = {\n");
>   buf_printf(b, "\t.name = KBUILD_MODNAME,\n");
>   if (mod->has_init)
> -- 
> 1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 04/13] uprobes: allow arch-specific initialization

[David Long]

On 10/19/13 12:42, Oleg Nesterov wrote:

On 10/15, David Long wrote:


Add a weak function for any architecture-specific initialization.  ARM
will use this to register the handlers for the undefined instructions it
uses to implement uprobes.


Could you explain why ARM can't simply do the necessary initialization in
arch/arm/kernel/uprobes-arm.c ?



+int __weak __init arch_uprobes_init(void)
+{
+   return 0;
+}
+
  static int __init init_uprobes(void)
  {
+   int ret;
int i;

for (i = 0; i < UPROBES_HASH_SZ; i++)
@@ -1870,6 +1876,10 @@ static int __init init_uprobes(void)
if (percpu_init_rwsem(_mmap_sem))
return -ENOMEM;

+   ret = arch_uprobes_init();
+   if (ret)
+   return ret;
+
return register_die_notifier(_exception_nb);
  }
  module_init(init_uprobes);


IOW, why do we need to call arch_uprobes_init() from init_uprobes().

Oleg



I don't know how you would do the initialization without invoking it 
through the module_init function, which I think you can only have one 
of.  Could you explain in more detail what you had in mind?


-dl

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/9] backlight: atmel-pwm-bl: fix reported brightness

[Jingoo Han]

On Wednesday, October 23, 2013 2:27 AM, Johan Hovold wrote:
> 
> The driver supports 16-bit brightness values, but the value returned
> from get_brightness was truncated to eight bits.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Johan Hovold 
> ---
>  drivers/video/backlight/atmel-pwm-bl.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/video/backlight/atmel-pwm-bl.c 
> b/drivers/video/backlight/atmel-pwm-bl.c
> index 66885fb..8aac273 100644
> --- a/drivers/video/backlight/atmel-pwm-bl.c
> +++ b/drivers/video/backlight/atmel-pwm-bl.c
> @@ -70,7 +70,7 @@ static int atmel_pwm_bl_set_intensity(struct 
> backlight_device *bd)
>  static int atmel_pwm_bl_get_intensity(struct backlight_device *bd)
>  {
>   struct atmel_pwm_bl *pwmbl = bl_get_data(bd);
> - u8 intensity;
> + u32 intensity;
> 
>   if (pwmbl->pdata->pwm_active_low) {
>   intensity = pwm_channel_readl(>pwmc, PWM_CDTY) -
> @@ -80,7 +80,7 @@ static int atmel_pwm_bl_get_intensity(struct 
> backlight_device *bd)
>   pwm_channel_readl(>pwmc, PWM_CDTY);
>   }
> 
> - return intensity;
> + return (u16)intensity;

However, atmel_pwm_bl_get_intensity() should return 'int',
instead of 'u16'. Also, pwm_channel_readl() returns 'u32'.

Then, how about the following?

--- a/drivers/video/backlight/atmel-pwm-bl.c
+++ b/drivers/video/backlight/atmel-pwm-bl.c
@@ -70,17 +70,17 @@ static int atmel_pwm_bl_set_intensity(struct 
backlight_device *bd)
 static int atmel_pwm_bl_get_intensity(struct backlight_device *bd)
 {
struct atmel_pwm_bl *pwmbl = bl_get_data(bd);
-   u8 intensity;
+   u16 intensity;

if (pwmbl->pdata->pwm_active_low) {
-   intensity = pwm_channel_readl(>pwmc, PWM_CDTY) -
+   intensity = (u16) pwm_channel_readl(>pwmc, PWM_CDTY) -
pwmbl->pdata->pwm_duty_min;
} else {
-   intensity = pwmbl->pdata->pwm_duty_max -
+   intensity = (u16) pwmbl->pdata->pwm_duty_max -
pwm_channel_readl(>pwmc, PWM_CDTY);
}

-   return intensity;
+   return (int)intensity;
 }

Best regards,
Jingoo Han

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/9] backlight: atmel-pwm-bl: fixes and clean ups

[Jingoo Han]

On Wednesday, October 23, 2013 2:27 AM, Johan Hovold wrote:
> 
> These patches fix a few issues and clean up the atmel-pwm-bl driver
> somewhat.
> 
> Johan
> 
> Johan Hovold (9):
>   backlight: atmel-pwm-bl: fix reported brightness
>   backlight: atmel-pwm-bl: fix gpio polarity in remove
>   backlight: atmel-pwm-bl: fix module autoload
>   backlight: atmel-pwm-bl: clean up probe error handling
>   backlight: atmel-pwm-bl: clean up get_intensity
>   backlight: atmel-pwm-bl: remove unused include
>   backlight: atmel-pwm-bl: use gpio_is_valid
>   backlight: atmel-pwm-bl: refactor gpio_on handling
>   backlight: atmel-pwm-bl: use gpio_request_one

++cc Andrew Morton, Tomi Valkeinen, Jean-Christophe Plagniol-Villard

Hi Johan Hovold,

Currently, because there is no git tree for backlight,
backlight patches have been merged to mm-tree by Andrew Morton.
Please, add Andrew Morton to CC list.

Also, there is another way.
If Nicolas Ferre wants to merge these patches, the patches can be
merged through ATMEL-SoC tree with my Acked-by.

Best regards,
Jingoo Han

> 
>  drivers/video/backlight/atmel-pwm-bl.c | 86 
> --
>  1 file changed, 40 insertions(+), 46 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 11/13] NTB: convert to dmaengine_unmap_data

[Jon Mason]

On Tue, Oct 22, 2013 at 06:05:31PM -0700, Dan Williams wrote:
> On Tue, Oct 22, 2013 at 4:12 PM, Jon Mason  wrote:
> > On Tue, Oct 22, 2013 at 02:29:36PM -0700, Dan Williams wrote:
> >> On Fri, Oct 18, 2013 at 6:06 PM, Jon Mason  wrote:
> >> > On Fri, Oct 18, 2013 at 07:35:31PM +0200, Bartlomiej Zolnierkiewicz 
> >> > wrote:
> >> >> Use the generic unmap object to unmap dma buffers.
> >> >>
> >> >> As NTB can be compiled without DMA_ENGINE support add
> >> >
> >> > Seems like the stubs should be added outside of this patch.
> >>
> >> I think they are ok here as this is the only driver that uses them.
> >> The alternative is a new api patch without a user.
> >>
> >> > Also, the
> >> > comment implies that NTB could not be compiled without DMA_ENGINE
> >> > support before, which it could be.
> >>
> >> Hmm, I read it as "since NTB *can* be compiled without dmaengine here
> >> are some stubs".
> >
> > This poses an overall question of whether it would simply be better to
> > abstract all of the with/without DMA_ENGINE part and simply remap it
> > to memcpy if DMA_ENGINE is not set (or if the DMA engine is
> > hotplugged).  Of course, this is outside the scope of this patch.
> 
> That's at least the promise of async_memcpy() it does not care if a
> channel is there or not, but I think it is better if the client has a
> strict dma and non-dma path.  Hiding the dma details from the client
> seems to have been the wrong choice at least for raid.
> 
> > That is fine.  It can be like this in the short term.
> >
> > Thanks,
> > Jon
> 
> I'll take that as:
> 
> Acked-by: Jon Mason 

Begrudgingly-Acked-by: Jon Mason 

> 
> ...but holler if not.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 11/13] NTB: convert to dmaengine_unmap_data

[Dan Williams]

On Tue, Oct 22, 2013 at 4:12 PM, Jon Mason  wrote:
> On Tue, Oct 22, 2013 at 02:29:36PM -0700, Dan Williams wrote:
>> On Fri, Oct 18, 2013 at 6:06 PM, Jon Mason  wrote:
>> > On Fri, Oct 18, 2013 at 07:35:31PM +0200, Bartlomiej Zolnierkiewicz wrote:
>> >> Use the generic unmap object to unmap dma buffers.
>> >>
>> >> As NTB can be compiled without DMA_ENGINE support add
>> >
>> > Seems like the stubs should be added outside of this patch.
>>
>> I think they are ok here as this is the only driver that uses them.
>> The alternative is a new api patch without a user.
>>
>> > Also, the
>> > comment implies that NTB could not be compiled without DMA_ENGINE
>> > support before, which it could be.
>>
>> Hmm, I read it as "since NTB *can* be compiled without dmaengine here
>> are some stubs".
>
> This poses an overall question of whether it would simply be better to
> abstract all of the with/without DMA_ENGINE part and simply remap it
> to memcpy if DMA_ENGINE is not set (or if the DMA engine is
> hotplugged).  Of course, this is outside the scope of this patch.

That's at least the promise of async_memcpy() it does not care if a
channel is there or not, but I think it is better if the client has a
strict dma and non-dma path.  Hiding the dma details from the client
seems to have been the wrong choice at least for raid.

> That is fine.  It can be like this in the short term.
>
> Thanks,
> Jon

I'll take that as:

Acked-by: Jon Mason 

...but holler if not.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] LSM: ModPin LSM for module loading restrictions

[Casey Schaufler]

On 10/22/2013 5:02 PM, James Morris wrote:
> On Thu, 17 Oct 2013, Casey Schaufler wrote:
>
>> On 10/17/2013 1:02 AM, James Morris wrote:
>>> This seems like a regression in terms of separating mechanism and policy.  
>>>
>>> We have several access control systems available (SELinux, at least) which 
>>> can implement this functionality with existing mechanisms using dynamic 
>>> policy.
>> They said the same thing about Smack.
>>
> Nope.  Smack separates mechanism and policy.  The argument then was 
> whether we need more than one such enhanced access control system.
>
> The issue now is that we do have several of them (SELinux, Smack, 
> AppArmor) which are policy-flexible, whether to regress back to adding 
> hard-coded security policies into the kernel.
>
>> The problem there is that you have to buy into the entirety of
>> SELinux to implement a small bit of behavior. You have to write
>> a policy that takes every aspect of system behavior into account
>> when all you care about is loading restrictions on modules.
> You always need to consider the behavior of the system as a whole when 
> designing security policies.

This is right thinking. It's just not common thinking.

> It's a major step backwards to hard-code a series of ad-hoc policies in 
> the kernel.  You still need to compose them somehow, and reason about the 
> security of the system as a whole.

It's not like we're talking about throwing out the legacy monolithic LSMs.
And let us not forget that Fedora is using SELinux and Yama. There's a
perception of value in independent security mechanisms used in combination.

>> The rationale is that lots of people doing little things is
>> likely to get us relevant security in a reasonable amount of time.
>> The existing LSMs reflect 20th century technologies and use cases.
>> They are fine for multi-user timesharing systems. We need to move
>> forward to support networked gaming, phones, tablets and toasters.
> You keep making these grand

Cool! Most people use other, less complimentary adjectives!

> assertions but never provide any detail, or 
> any kind of evidence to back them up.

There are simple reasons for that. Between Tizen and the stacking patch
the work on a real Application+Service+Resource security model and the
implementation thereof has gotten insufficient attention. I have been
emphasizing work on enabling technology over work on what needs to be
enabled. Kees' approach to security development on CromeOS is the example
I'll hold up for the wave of the future.

> Yet there are many, many examples 
> of how the current LSMs meet all of these needs in the 21st century, such 
> as Smack being adopted for Tizen, digital television etc.:

Smack in Tizen is an example of old school distribution packaging.
Tizen is very old school in its approach. It's working out pretty
well, but Tizen is hardly a major advance in the world of OS security.

If you look at Android, their (re/miss/ab)use of the UID mechanism and
reliance on the binder to wedge an application based security policy
on top of existing mechanisms it should be pretty obvious that they
would have been better suited with new security features than with
retrofitting to existing technology.

SEAndroid is taking a refreshing approach by putting the access controls
in the middleware and by doing so enabling an appropriate implementation
on the flask architecture. I would not say that SEAndroid qualifies as an
example of adopting an LSM.

> http://en.wikipedia.org/wiki/Smack
>
>
>
> - James

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: MMC request with REQ_DISCARD option may not release host when it should

[Seungwon Jeon]

Hi Ray,

Thank you for information. Your analysis is right.
I also noticed same problem.
If you'd like to submit patch, not to report, please send it with regular form.
Or I could send similar patch I have.

Thanks,
Seungwon Jeon

On Wed, Oct 23, 2013, Ray Jui wrote:
Hi Seungwon/Chris,

We recently came across an eMMC issue that causes mmc_suspend to stuck waiting 
to claim the host. This issue only happens when one
of the MMC partitions is mounted with the discard option. By tracing the issue 
down in the kernel MMC stack, in the function
mmc_blk_issue_rq under drivers/mmc/card/block.c, we noticed the host will be 
released when req is valid and when req->cmd_flags is
set to one of the masks: MMC_REQ_SPECIAL_MASK. Based on the code comment, I 
believe the intention is to always release the host in
the case of special request (which include both REQ_DISCARD and REQ_FLUSH).

Note in function call mmc_blk_issue_discard_rq, the memory where req points to 
can be freed. This means at the bottom of the
mmc_blk_issue_rq, req->cmd_flags may contain garbage value and I believe this 
is what’s causing the issue that we are seeing in
mmc_suspend after the discard operation: In mmc_suspend, it blocks waiting to 
claim the host but the host was never released after
the discard operation.

Please help to review the attached patch that fixes the issue.

Thanks,

Ray Jui

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: allow unlimited audit_backlog_limit [was: Re: [PATCH] audit: don't create audit log when audit_backlog_limit is zero]

[Gao feng]

On 10/23/2013 01:59 AM, Richard Guy Briggs wrote:
> On Mon, Oct 21, 2013 at 04:01:40PM +0800, Gao feng wrote:
>> As the man page of auditctl said:
>> "
>> -b backlog
>>   Set max number of outstanding audit buffers allowed (Kernel 
>> Default=64)
>>If all buffers are full, the failure flag is consulted by the 
>> kernel
>>   for action.
>> "
>>
>> So if audit_backlog_limit is zero, it means no audit buffer
>> should be allocated.
> 
> Which sounds the same as audit=0 on the kernel boot line or "auditctl -e 0"
> to disable it.  This is redundant.  I would suggest instead that it
> would be more useful to have backlog set to zero mean unlimited (well,
> limited by system RAM).  This can be dangerous, but that can be
> warned in the manpage.  So, to accomplish that, a minor change is
> needed in the audit_hold_skb() funciton:
> 
> diff --git a/kernel/audit.c b/kernel/audit.c
> @@ -355,7 +355,8 @@ static int audit_set_failure(int state)
>  static void audit_hold_skb(struct sk_buff *skb)
>  {
>   if (audit_default &&
> - skb_queue_len(_skb_hold_queue) < audit_backlog_limit)
> + (!audit_backlog_limit ||
> +  skb_queue_len(_skb_hold_queue) < audit_backlog_limit))
>   skb_queue_tail(_skb_hold_queue, skb);
>   else
>   kfree_skb(skb);
> 
> And here is what I would propose for the corresponding userspace mod:
> 
> diff --git a/trunk/docs/auditctl.8 b/trunk/docs/auditctl.8
> @@ -8,7 +8,7 @@ The \fBauditctl\fP program is used to control the behavior, 
> get status, and add
>  .SH OPTIONS
>  .TP
>  .BI \-b\  backlog
> -Set max number of outstanding audit buffers allowed (Kernel Default=64) If 
> all buffers are full, the failure flag is consulted by the kernel for action.
> +Set max number of outstanding audit buffers allowed (Kernel Default=64) If 
> all buffers are full, the failure flag is consulted by the kernel for action. 
>  Setting this to "0" (which is dangerous) implies an unlimited queue, limited 
> only by system resources.
>  .TP
>  \fB\-e\fP [\fB0\fP..\fB2\fP]
>  Set enabled flag. When \fB0\fP is passed, this can be used to temporarily 
> disable auditing. When \fB1\fP is passed as an argument, it will enable 
> auditing. To lock the audit configuration so that it can't be changed, pass a 
> \fB2\fP as the argument. Locking the configuration is intended to be the last 
> command in audit.rules for anyone wishing this feature to be active. Any 
> attempt to change the configuration in this mode will be audited and denied. 
> The configuration can only be changed by rebooting the machine.
> diff --git a/trunk/src/auditctl.c b/trunk/src/auditctl.c
> @@ -107,7 +107,7 @@ static void usage(void)
>   "-a Append rule to end of ist with ction\n"
>   "-A Add rule at beginning of ist with 
> ction\n"
>   "-b Set max number of outstanding audit buffers\n"
> - "allowed Default=64\n"
> + "allowed. Default=64 Unlimited=0(dangerous)\n"
>   "-c  Continue through errors in rules\n"
>   "-C f=f  Compare collected fields if available:\n"
>   "Field name, operator(=,!=), field name\n"
> 
> 
> Does this sound like a reasonable change?
> 

Yes, it's reasonable, I'm ok with this change, just like audit_rate_limit,
zero means unlimited. And it's better to change the comments of 
audit_backlog_limit
in kernel.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] x86: intel-mid: add Merrifield platform support

[Yang, Fei]

+   if (intel_mid_identify_cpu() ==
+   INTEL_MID_CPU_CHIP_TANGIER) {
+   if (!strncmp(pentry->name,
+   "r69001-ts-i2c", 13))
+   /* active low */
+   irq_attr.polarity = 1;
+   else if (!strncmp(pentry->name,
+   "synaptics_3202", 14))
+   /* active low */
+   irq_attr.polarity = 1;
+   else if (irq == 41)
+   /* fast_int_1 */
+   irq_attr.polarity = 1;

Do you really want to upstream these very hardware specific hacks? It's needed 
for
Saltbay, but might not be correct for other Merrifield based hardware, if any.

-Fei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

A thought about IO scheduler in linux kernel for SSD

[韩磊]

Nowadays,the IO schedulers in linux kernel have four types:

deadline,noop,Anticiptory and CFQ.CFQ is the default scheduler.But CFQ is

not a good scheduler for SSD,dealine may be a good choice.
When deadline runs,it has a mount of computation about merging and

sorting.Merge has three types: front_merge,no_merge and back_merge.
Why don't have  another type: merge based same sector.For example,it have

two bios in a request list,theyboth have the same bi->sector,the bi->size

maybe not equal. Whether can we put the latter bio replace the former?What

do you find that significant?Or the other levels in OS has finished this
function?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [3.12-rc] sg_open: leaving the kernel with locks still held!

[Douglas Gilbert]

On 13-10-22 04:56 PM, Simon Kirby wrote:

Hello!

While trying to figure out why the request queue to sda (ext4) was
clogging up on one of our btrfs backup boxes, I noticed a megarc process
in D state, so enabled locking debugging, and got this (on 3.12-rc6):

[  205.372823] 
[  205.372901] [ BUG: lock held when returning to user space! ]
[  205.372979] 3.12.0-rc6-hw-debug-pagealloc+ #67 Not tainted
[  205.373055] 
[  205.373132] megarc.bin/5283 is leaving the kernel with locks still held!
[  205.373212] 1 lock held by megarc.bin/5283:
[  205.373285]  #0:  (>o_sem){.+.+..}, at: [] 
sg_open+0x3a0/0x4d0

Vaughan, it seems you touched this area last in 15b06f9a02406e, and git
tag --contains says this went in for 3.12-rc. We didn't see this on 3.11,
though I haven't tried with lockdep.

This is caused by some of our internal RAID monitoring scripts that run
"megarc.bin -dispCfg -a0" (even though that controller isn't present on
this server -- a PowerEdge 2950 w/Perc 5).

strace output of the program execution that causes the above message is
here: http://0x.ca/sim/ref/3.12-rc6/megarc_strace.txt


This has been reported. That patch will be reverted or,
if there is enough time, a fix will (or at least should)
go in before the release of lk 3.12 .

See this thread:
  http://marc.info/?t=13822854731=1=2


And you might test the patch and confirm that it does
fix the problem (and report back).

Doug Gilbert

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 1/2] devices cgroup: allow can_attach() if ns_capable

[Serge E. Hallyn]

Quoting Tejun Heo (t...@kernel.org):
> On Tue, Jul 23, 2013 at 2:38 PM, Serge Hallyn  wrote:
> > This doesn't delegate it into the container.  It allows me, on the host,
> > to set the cgroup for a container.
> 
> Hmmm? I'm a bit confused. Isn't the description saying that the patch
> allows pseudo-root in userns to change cgroup membership even if it
> isn't actually root?
> 
> Besides, I find the whole check rather bogus and would actually much
> prefer just nuking the check and just follow the standard permission
> checks.

Can we please nuke it like this then?

>From b840083ec8fa1f0645ae925c79db3dc51edd019c Mon Sep 17 00:00:00 2001
From: Serge Hallyn 
Date: Wed, 23 Oct 2013 01:34:00 +0200
Subject: [PATCH 1/1] device_cgroup: remove can_attach

It is really only wanting to duplicate a check which is already done by the
cgroup subsystem.

With this patch, user jdoe still cannot move pid 1 into a devices cgroup
he owns, but now he can move his own other tasks into devices cgroups.

Signed-off-by: Serge Hallyn 
Cc: Aristeu Rozanski 
Cc: Tejun Heo 
---
 security/device_cgroup.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/security/device_cgroup.c b/security/device_cgroup.c
index efc6f68..a37c054 100644
--- a/security/device_cgroup.c
+++ b/security/device_cgroup.c
@@ -64,16 +64,6 @@ static inline struct dev_cgroup *task_devcgroup(struct 
task_struct *task)
 
 struct cgroup_subsys devices_subsys;
 
-static int devcgroup_can_attach(struct cgroup_subsys_state *new_css,
-   struct cgroup_taskset *set)
-{
-   struct task_struct *task = cgroup_taskset_first(set);
-
-   if (current != task && !capable(CAP_SYS_ADMIN))
-   return -EPERM;
-   return 0;
-}
-
 /*
  * called under devcgroup_mutex
  */
@@ -698,7 +688,6 @@ static struct cftype dev_cgroup_files[] = {
 
 struct cgroup_subsys devices_subsys = {
.name = "devices",
-   .can_attach = devcgroup_can_attach,
.css_alloc = devcgroup_css_alloc,
.css_free = devcgroup_css_free,
.css_online = devcgroup_online,
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/24] md: Convert use of typedef ctl_table to struct ctl_table

[NeilBrown]

On Tue, 22 Oct 2013 15:29:51 -0700 Joe Perches  wrote:

> This typedef is unnecessary and should just be removed.
> 
> Signed-off-by: Joe Perches 
> ---
>  drivers/md/md.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 8a0d762..7b57639 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -112,7 +112,7 @@ static inline int speed_max(struct mddev *mddev)
>  
>  static struct ctl_table_header *raid_table_header;
>  
> -static ctl_table raid_table[] = {
> +static struct ctl_table raid_table[] = {
>   {
>   .procname   = "speed_limit_min",
>   .data   = _speed_limit_min,
> @@ -130,7 +130,7 @@ static ctl_table raid_table[] = {
>   { }
>  };
>  
> -static ctl_table raid_dir_table[] = {
> +static struct ctl_table raid_dir_table[] = {
>   {
>   .procname   = "raid",
>   .maxlen = 0,
> @@ -140,7 +140,7 @@ static ctl_table raid_dir_table[] = {
>   { }
>  };
>  
> -static ctl_table raid_root_table[] = {
> +static struct ctl_table raid_root_table[] = {
>   {
>   .procname   = "dev",
>   .maxlen = 0,


Applied, thanks.

NeilBrown


signature.asc
Description: PGP signature

Re: [PATCH 1/1] x86: boot: support minigzip bzImage compression

[H. Peter Anvin]

Wouldn't it be better to fix gzip than hacking around this in the kernel?

Andrew Boie  wrote:
>Android OTA system computes very efficient diffs of compressed files
>if the deflate() algorithm it has access to is the same version as
>used to create the original file. Here we add support for compressing
>the kernel with 'minigzip' which uses the deflate() inside zlib.
>This is much better than using 'gzip' as that tool has a very old
>version of deflate() inside the gzip codebase instead of linking
>against
>zlib.
>
>Signed-off-by: Andrew Boie 
>---
> arch/x86/Kconfig  |  1 +
> arch/x86/boot/compressed/Makefile |  3 +++
> arch/x86/boot/compressed/misc.c   |  2 +-
> init/Kconfig  | 18 +-
> scripts/Makefile.lib  |  7 +++
> 5 files changed, 29 insertions(+), 2 deletions(-)
>
>diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>index f67e839..aa91cef 100644
>--- a/arch/x86/Kconfig
>+++ b/arch/x86/Kconfig
>@@ -62,6 +62,7 @@ config X86
>   select HAVE_REGS_AND_STACK_ACCESS_API
>   select HAVE_DMA_API_DEBUG
>   select HAVE_KERNEL_GZIP
>+  select HAVE_KERNEL_MINIGZIP
>   select HAVE_KERNEL_BZIP2
>   select HAVE_KERNEL_LZMA
>   select HAVE_KERNEL_XZ
>diff --git a/arch/x86/boot/compressed/Makefile
>b/arch/x86/boot/compressed/Makefile
>index dcd90df..f000791 100644
>--- a/arch/x86/boot/compressed/Makefile
>+++ b/arch/x86/boot/compressed/Makefile
>@@ -56,6 +56,8 @@ vmlinux.bin.all-$(CONFIG_X86_NEED_RELOCS) +=
>$(obj)/vmlinux.relocs
> 
> $(obj)/vmlinux.bin.gz: $(vmlinux.bin.all-y) FORCE
>   $(call if_changed,gzip)
>+$(obj)/vmlinux.bin.mgz: $(vmlinux.bin.all-y) FORCE
>+  $(call if_changed,minigzip)
> $(obj)/vmlinux.bin.bz2: $(vmlinux.bin.all-y) FORCE
>   $(call if_changed,bzip2)
> $(obj)/vmlinux.bin.lzma: $(vmlinux.bin.all-y) FORCE
>@@ -68,6 +70,7 @@ $(obj)/vmlinux.bin.lz4: $(vmlinux.bin.all-y) FORCE
>   $(call if_changed,lz4)
> 
> suffix-$(CONFIG_KERNEL_GZIP)  := gz
>+suffix-$(CONFIG_KERNEL_MINIGZIP):= mgz
> suffix-$(CONFIG_KERNEL_BZIP2) := bz2
> suffix-$(CONFIG_KERNEL_LZMA)  := lzma
> suffix-$(CONFIG_KERNEL_XZ):= xz
>diff --git a/arch/x86/boot/compressed/misc.c
>b/arch/x86/boot/compressed/misc.c
>index 434f077..4e55d32 100644
>--- a/arch/x86/boot/compressed/misc.c
>+++ b/arch/x86/boot/compressed/misc.c
>@@ -125,7 +125,7 @@ static char *vidmem;
> static int vidport;
> static int lines, cols;
> 
>-#ifdef CONFIG_KERNEL_GZIP
>+#if defined(CONFIG_KERNEL_GZIP) || defined(CONFIG_KERNEL_MINIGZIP)
> #include "../../../../lib/decompress_inflate.c"
> #endif
> 
>diff --git a/init/Kconfig b/init/Kconfig
>index 3ecd8a1..818f225 100644
>--- a/init/Kconfig
>+++ b/init/Kconfig
>@@ -100,6 +100,9 @@ config LOCALVERSION_AUTO
> config HAVE_KERNEL_GZIP
>   bool
> 
>+config HAVE_KERNEL_MINIGZIP
>+  bool
>+
> config HAVE_KERNEL_BZIP2
>   bool
> 
>@@ -118,7 +121,7 @@ config HAVE_KERNEL_LZ4
> choice
>   prompt "Kernel compression mode"
>   default KERNEL_GZIP
>-  depends on HAVE_KERNEL_GZIP || HAVE_KERNEL_BZIP2 || HAVE_KERNEL_LZMA
>|| HAVE_KERNEL_XZ || HAVE_KERNEL_LZO || HAVE_KERNEL_LZ4
>+  depends on HAVE_KERNEL_GZIP || HAVE_KERNEL_MINIGZIP ||
>HAVE_KERNEL_BZIP2 || HAVE_KERNEL_LZMA || HAVE_KERNEL_XZ ||
>HAVE_KERNEL_LZO || HAVE_KERNEL_LZ4
>   help
> The linux kernel is a kind of self-extracting executable.
> Several compression algorithms are available, which differ
>@@ -144,6 +147,19 @@ config KERNEL_GZIP
> The old and tried gzip compression. It provides a good balance
> between compression ratio and decompression speed.
> 
>+config KERNEL_MINIGZIP
>+  bool "Minigzip"
>+  depends on HAVE_KERNEL_MINIGZIP
>+  help
>+Use minigzip to compress the bzImage. This is very similar to gzip
>+but uses the zlib library to compress, rather than the very old
>version
>+of zlib inside the gzip codebase. This is used for Android kernels
>+so that the same version of the deflate() algorithm is used when
>+building the kernel and constructing diffs with OTA applypatch,
>which
>+uncompresses sections of files that it detects are gzipped before
>computing
>+the diffs. If the versions of deflate() are out of alignment the
>binary
>+diffs tend to be very large.
>+
> config KERNEL_BZIP2
>   bool "Bzip2"
>   depends on HAVE_KERNEL_BZIP2
>diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
>index 49392ec..deb1bb8 100644
>--- a/scripts/Makefile.lib
>+++ b/scripts/Makefile.lib
>@@ -240,6 +240,13 @@ quiet_cmd_gzip = GZIP$@
> cmd_gzip = (cat $(filter-out FORCE,$^) | gzip -n -f -9 > $@) || \
>   (rm -f $@ ; false)
> 
>+# Minigzip
>+#
>---
>+
>+quiet_cmd_minigzip = MINGZIP $@
>+cmd_minigzip = (cat $(filter-out FORCE,$^) | minigzip -c -9 > $@) || \
>+  (rm -f $@ ; false)
>+
> # DTC
>#

Re: [PATCH v4 0/3] x86, apic, kexec: Add disable_cpu_apic kernel parameter

[HATAYAMA Daisuke]

(2013/10/23 7:08), jerry.hoem...@hp.com wrote:

On Wed, Oct 23, 2013 at 12:01:18AM +0900, HATAYAMA Daisuke wrote:

This patch set is to allow kdump 2nd kernel to wake up multiple CPUs
even if 1st kernel crashs on some AP, a continueing work from:

   [PATCH v3 0/2] x86, apic, kdump: Disable BSP if boot cpu is AP
   https://lkml.org/lkml/2013/10/16/300.

In this version, basic design has changed. Now users need to figure
out initial APIC ID of BSP in the 1st kernel and configures kernel
parameter for the 2nd kernel manually using disable_cpu_apic kernel
parameter to be newly introduced in this patch set. This design is
more flexible than the previous version in that we no longer have to
rely on ACPI/MP table to get initial APIC ID of BSP.

Sorry, this patch set have not include in-source documentation
requested by Borislav Petkov yet, but I'll post it later separately,
which would be better to focus on documentation reviewing.

ChangeLog

v3 => v4)

- Rebased on top of v3.12-rc6

- Basic design has been changed. Now users need to figure out initial
   APIC ID of BSP in the 1st kernel and configures kernel parameter for
   the 2nd kernel manually using disable_cpu_apic kernel parameter to
   be newly introduced in this patch set. This design is more flexible
   than the previous version in that we no longer have to rely on
   ACPI/MP table to get initial APIC ID of BSP.



Do you literally mean a human at each boot will have to configure
the kdump configuration files for passing disable_cpu_apic?
Or do you envision the setting of disable_cpu_apic being put into
the kdump initialization scripts?

thanks

Jerry


Nearer to the former case, but this is not what a human should do. It's
a cumbersome task. I think, on fedora/RHEL system for example, kdump
service should check at each boot automatically.

--
Thanks.
HATAYAMA, Daisuke

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] block/aio: Enable sysfs nomerge control for I/O requests in the plug list

[Alireza Haghdoost]

This patch enables the sysfs to control I/O request merge
functionality in the plug list. While this control has been
implemented for the request queue, it was dismissed in the plug list.
Therefore, block layer merges requests together (or attempt to merge)
even if the merge capability was disable using sysfs nomerge parameter
value 2.

This limitation is directly affects functionality of io_submit()
system call. The system call enables user to submit a bunch of IO
requests from user space using struct iocb **ios input argument.
However, the unconditioned merging functionality in the plug list
potentially merges these requests together down the road. Therefore,
there is no way to distinguish between an application sending bunch of
sequential IOs and an application sending one big IO. Ultimately, all
requests generated by the former app merge within the plug list
together and looks similar to the second app.

While the merging functionality is a desirable feature to improve the
performance of IO subsystem for some applications, it is not useful
for other application like ours at all.



Signed-off-by: Alireza Haghdoost 

--- block/blk-core.c.orig 2013-10-22 15:26:59.484961156 -0500
+++ block/blk-core.c 2013-10-21 23:24:21.437887017 -0500
@@ -1420,7 +1420,7 @@
  bool ret = false;

  plug = current->plug;
- if (!plug)
+ if (!plug || blk_queue_nomerges(q) )
  goto out;
  *request_count = 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 03/13] uprobes: allow arch access to xol slot

[David Long]

On 10/19/13 12:36, Oleg Nesterov wrote:

On 10/15, David Long wrote:


Allow arches to customize how the instruction is filled into the xol
slot.  ARM will use this to insert an undefined instruction after the
real instruction in order to simulate a single step of the instruction
without hardware support.


OK, but


+void __weak arch_uprobe_xol_copy(struct arch_uprobe *auprobe, void *vaddr)
+{
+   memcpy(vaddr, auprobe->insn, MAX_UINSN_BYTES);
+}
+
  /*
   * xol_get_insn_slot - allocate a slot for xol.
   * Returns the allocated slot address or 0.
@@ -1246,6 +1251,7 @@ static unsigned long xol_get_insn_slot(struct uprobe 
*uprobe)
  {
struct xol_area *area;
unsigned long xol_vaddr;
+   void *kaddr;

area = get_xol_area();
if (!area)
@@ -1256,7 +1262,9 @@ static unsigned long xol_get_insn_slot(struct uprobe 
*uprobe)
return 0;

/* Initialize the slot */
-   copy_to_page(area->page, xol_vaddr, uprobe->arch.insn, MAX_UINSN_BYTES);
+   kaddr = kmap_atomic(area->page);
+   arch_uprobe_xol_copy(>arch, kaddr + (xol_vaddr & ~PAGE_MASK));
+   kunmap_atomic(kaddr);


This looks a bit strange and defeats the purpose of generic helper...

How about

void __weak arch_uprobe_xol_copy(...)
{
copy_to_page(...);
}

then just

- copy_to_page(...);
+ arch_uprobe_xol_copy(...);

?



I was trying to avoid duplicating the VM calls in the 
architecture-specific implementations, but maybe that is the cleaner way 
to do it after all.  I've made changes as suggested above.



Or, I am just curious, can't we have an empty "__weak arch_uprobe_xol_copy" if
we call it right after copy_to_page() ?



Then there would potentially be effectively two copy calls.  That 
doesn't feel at all the right thing to do.


-dl

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] LSM: ModPin LSM for module loading restrictions

[James Morris]

On Thu, 17 Oct 2013, Casey Schaufler wrote:

> On 10/17/2013 1:02 AM, James Morris wrote:
> > This seems like a regression in terms of separating mechanism and policy.  
> >
> > We have several access control systems available (SELinux, at least) which 
> > can implement this functionality with existing mechanisms using dynamic 
> > policy.
> 
> They said the same thing about Smack.
> 

Nope.  Smack separates mechanism and policy.  The argument then was 
whether we need more than one such enhanced access control system.

The issue now is that we do have several of them (SELinux, Smack, 
AppArmor) which are policy-flexible, whether to regress back to adding 
hard-coded security policies into the kernel.

> The problem there is that you have to buy into the entirety of
> SELinux to implement a small bit of behavior. You have to write
> a policy that takes every aspect of system behavior into account
> when all you care about is loading restrictions on modules.

You always need to consider the behavior of the system as a whole when 
designing security policies.

It's a major step backwards to hard-code a series of ad-hoc policies in 
the kernel.  You still need to compose them somehow, and reason about the 
security of the system as a whole.

> The rationale is that lots of people doing little things is
> likely to get us relevant security in a reasonable amount of time.
> The existing LSMs reflect 20th century technologies and use cases.
> They are fine for multi-user timesharing systems. We need to move
> forward to support networked gaming, phones, tablets and toasters.

You keep making these grand assertions but never provide any detail, or 
any kind of evidence to back them up.  Yet there are many, many examples 
of how the current LSMs meet all of these needs in the 21st century, such 
as Smack being adopted for Tizen, digital television etc.:

http://en.wikipedia.org/wiki/Smack



- James
-- 
James Morris

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/24] treewide: Convert use of typedef ctl_table to struct ctl_table

[Joe Perches]

On Tue, 2013-10-22 at 16:53 -0700, David Daney wrote:
> After all this work, why not go ahead and remove the typedef?  That way 
> people won't add more users of this abomination.

Hi David.

The typedef can't be removed until all the uses are gone.

I've sent this before as a single large patch as well as
individual patches.

treewide:   https://lkml.org/lkml/2013/7/22/600
RemoveTypedef:  https://lkml.org/lkml/2013/7/22/603

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 02/13] uprobes: allow ignoring of probe hits

[David Long]

On 10/22/13 07:25, Oleg Nesterov wrote:

Sorry for top-posting/formatting,

Do you mean arch_uprobe_skip_sstep() ?

Yes, this __weak is wrong, already fixed in my tree. See
http://marc.info/?l=linux-mips=138132052022388=2



That was one I was looking at, but it seemed to me a general opportunity 
for runtime failures in the kernel that could have been detected at link 
time.  But that's a topic for discussion elsewhere I should think.


-dl

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

perf events ring buffer memory barrier on powerpc

[Michael Neuling]

Frederic,

In the perf ring buffer code we have this in perf_output_get_handle():

if (!local_dec_and_test(>nest))
goto out;

/*
 * Publish the known good head. Rely on the full barrier implied
 * by atomic_dec_and_test() order the rb->head read and this
 * write.
 */
rb->user_page->data_head = head;

The comment says atomic_dec_and_test() but the code is
local_dec_and_test().

On powerpc, local_dec_and_test() doesn't have a memory barrier but
atomic_dec_and_test() does.  Is the comment wrong, or is
local_dec_and_test() suppose to imply a memory barrier too and we have
it wrongly implemented in powerpc?

My guess is that local_dec_and_test() is correct but we to add an
explicit memory barrier like below:

(Kudos to Victor Kaplansky for finding this)

Mikey

diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
index cd55144..95768c6 100644
--- a/kernel/events/ring_buffer.c
+++ b/kernel/events/ring_buffer.c
@@ -87,10 +87,10 @@ again:
goto out;
 
/*
-* Publish the known good head. Rely on the full barrier implied
-* by atomic_dec_and_test() order the rb->head read and this
-* write.
+* Publish the known good head. We need a memory barrier to order the
+* order the rb->head read and this write.
 */
+   smp_mb ();
rb->user_page->data_head = head;
 
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/24] treewide: Convert use of typedef ctl_table to struct ctl_table

[David Daney]

On 10/22/2013 03:29 PM, Joe Perches wrote:

Joe Perches (24):
   arm: Convert use of typedef ctl_table to struct ctl_table
   ia64: Convert use of typedef ctl_table to struct ctl_table
   s390: Convert use of typedef ctl_table to struct ctl_table
   tile: Convert use of typedef ctl_table to struct ctl_table
   cdrom: Convert use of typedef ctl_table to struct ctl_table
   random: Convert use of typedef ctl_table to struct ctl_table
   infiniband: Convert use of typedef ctl_table to struct ctl_table
   md: Convert use of typedef ctl_table to struct ctl_table
   parport: Convert use of typedef ctl_table to struct ctl_table
   scsi: Convert use of typedef ctl_table to struct ctl_table
   coda: Convert use of typedef ctl_table to struct ctl_table
   fscache: Convert use of typedef ctl_table to struct ctl_table
   lockd: Convert use of typedef ctl_table to struct ctl_table
   nfs: Convert use of typedef ctl_table to struct ctl_table
   inotify: Convert use of typedef ctl_table to struct ctl_table
   ntfs: Convert use of typedef ctl_table to struct ctl_table
   ocfs2: Convert use of typedef ctl_table to struct ctl_table
   proc: Convert use of typedef ctl_table to struct ctl_table
   fs: Convert use of typedef ctl_table to struct ctl_table
   key: Convert use of typedef ctl_table to struct ctl_table
   ipc: Convert use of typedef ctl_table to struct ctl_table
   kernel: Convert use of typedef ctl_table to struct ctl_table
   mm: Convert use of typedef ctl_table to struct ctl_table
   security:keys: Convert use of typedef ctl_table to struct ctl_table


After all this work, why not go ahead and remove the typedef?  That way 
people won't add more users of this abomination.


David Daney





  arch/arm/kernel/isa.c  |  6 ++---
  arch/ia64/kernel/crash.c   |  4 +--
  arch/ia64/kernel/perfmon.c |  6 ++---
  arch/s390/appldata/appldata_base.c | 10 
  arch/s390/kernel/debug.c   |  2 +-
  arch/s390/mm/cmm.c |  8 +++---
  arch/tile/kernel/proc.c|  4 +--
  drivers/cdrom/cdrom.c  | 10 
  drivers/char/random.c  |  4 +--
  drivers/infiniband/core/ucma.c |  2 +-
  drivers/md/md.c|  6 ++---
  drivers/parport/procfs.c   | 52 ++
  drivers/scsi/scsi_sysctl.c |  6 ++---
  fs/coda/sysctl.c   |  4 +--
  fs/dcache.c|  2 +-
  fs/drop_caches.c   |  2 +-
  fs/eventpoll.c |  2 +-
  fs/file_table.c|  4 +--
  fs/fscache/main.c  |  4 +--
  fs/inode.c |  2 +-
  fs/lockd/svc.c |  6 ++---
  fs/nfs/nfs4sysctl.c|  6 ++---
  fs/nfs/sysctl.c|  6 ++---
  fs/notify/inotify/inotify_user.c   |  2 +-
  fs/ntfs/sysctl.c   |  4 +--
  fs/ocfs2/stackglue.c   |  8 +++---
  fs/proc/proc_sysctl.c  |  2 +-
  include/linux/key.h|  2 +-
  ipc/ipc_sysctl.c   | 14 +-
  ipc/mq_sysctl.c| 10 
  kernel/sysctl.c|  2 +-
  kernel/utsname_sysctl.c|  6 ++---
  mm/page-writeback.c|  2 +-
  mm/page_alloc.c| 12 -
  security/keys/sysctl.c |  2 +-
  35 files changed, 111 insertions(+), 113 deletions(-)



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/4] drivers/misc: add rawio framework and drivers

[Greg Kroah-Hartman]

On Tue, Oct 22, 2013 at 11:19:30AM -0700, Bin Gao wrote:
> On Tue, Oct 22, 2013 at 06:44:06AM +0100, Greg Kroah-Hartman wrote:
> > So, just because userspace is "hard" you want to add stuff to the kernel
> > instead.
> > 
> Well, there are other reasons - "hard" is just one of them.
> For instance, on some platforms with runtime pm enabled, access to registers
> of a device which is in low power state will cause problems(syste reboot, 
> etc.).
> You can only wake it up to running state by runtime API from kernel space.

Then write a UIO pci driver, that should work, right?

> > Sorry, but for over the past decade, we have been doing just the
> > opposite, if things can be done in userspace, then they should be done
> > there.  So for us to go in the opposite direction, like these patches
> > show, would be a major change.
> > 
> Agree, but as mentioned above, for some situation we can't do it from
> user space.
> 
> > You can already do this today for PCI with the UIO framework, right?
> > Why duplicate that functionality here with another userapce API that we
> > will then have to maintain for the next 40+ years?
> > 
> No, UIO is not appropriate for my requirement.

I don't know what your "requirements" are.

> The thing I need is to dump any registers just by 2 simple commands.

I find it hard to believe that your "requirement" dictates the exact
method of _how_ you get access to this hardware.

> > Have you run these proposed changes by any of the Intel kernel
> > developers?  What did they say to them?
> > 
> > If not, why haven't you, isn't that a resource you should be using for
> > things like this?
> > 
> Why you had these strange questions?

It's something I ask any Intel developer who sends odd patches that have
obviously not been reviewed by Intel's kernel developers.  They are a
resource you should be using to tell you these types of things, don't
make me, a community member, tell you this.

> Over years, we have been maintaining and using these drivers internally 
> for various purpose across our group for SoC pre-silicon and post-silicon
> degugging, e.g. IOAPIC RTE dumping, GPIO tunning, raw device degugging
> without a driver(i2c, spi, uart), etc., etc., ...
> Trying to push some existed codes upstream is not a bad thing.

Trying to push code that is incorrect is a bad thing.  Just because it
has been living in a private tree for X number of years is not an
excuse, because you are now asking me and others to maintain this API
you have created (which is undocumented) for the next 40+ years.

Again, use the interfaces we already have, and if they are not
sufficient for whatever reason, help make them better.  Don't create
whole new ones just because someone 5+ years ago didn't know about them,
or that they weren't even present at that time.  That's not the
community's fault, it's yours.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/4] drivers/misc: add rawio framework and drivers

[Greg Kroah-Hartman]

On Tue, Oct 22, 2013 at 11:50:04AM -0700, Bin Gao wrote:
> On Tue, Oct 22, 2013 at 10:14:00AM -0700, Guenter Roeck wrote:
> > > 
> > > You can already do this today for PCI with the UIO framework, right?
> > > Why duplicate that functionality here with another userapce API that we
> > > will then have to maintain for the next 40+ years?
> > > 
> > Same for i2c, where the same functionality is supported through i2c-tools 
> > and
> > the i2c-dev driver. Adding i2c-tools to initramfs and/or to the root file 
> > system
> > should not be that much of an issue, much less than having to maintain two 
> > APIs
> > for the same purpose.
> > 
> > Guenter
> 
> For PCI and memory mapped I/O devices, we have the runtime pm issue that has 
> to
> be addressed from kernel space.

Then create a UIO pci driver and you should be fine, right?  That's what
others do today and it works quite well for them.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 3/4] ARM: pinctrl: Add Broadcom Capri pinctrl driver

[Sherman Yin]

> +static const struct capri_cfg_param capri_pinconf_params[] = {
> +   {"brcm,hysteresis", CAPRI_PINCONF_PARAM_HYST},
> +   {"brcm,pull",   CAPRI_PINCONF_PARAM_PULL},
> +   {"brcm,slew",   CAPRI_PINCONF_PARAM_SLEW},
> +   {"brcm,input_dis",  CAPRI_PINCONF_PARAM_INPUT_DIS},
> +   {"brcm,drive_str",  CAPRI_PINCONF_PARAM_DRV_STR},
> +   {"brcm,pull_up_str",CAPRI_PINCONF_PARAM_PULL_UP_STR},
> +   {"brcm,mode",   CAPRI_PINCONF_PARAM_MODE},
> +};

As well as all this stuff...
>>>
>>> OK.  Will see if I can find something suitable for "input disable" and 
>>> "mode"
>>
>>Let's discuss this. What exactly does "input disable" and "mode"
>>mean, in electrical terms?
>>
>>When you come down to what actually happens it may turn out that
>>"input disable" is PIN_CONFIG_OUTPUT, which implicitly turns
>>off input does it not?
>
>I'm going to verify the details with our hardware team first, and will let you
>know if we think we can use one of the existing generic parameters or if we
>need a new one.

"input disable"
This setting disconnects the input (DIN) to the internal logic from the pin 
pad.  
However, the output (DOUT) can still drive the pad.  It seems to match 
PIN_CONFIG_OUTPUT, but the current generic option is either "output-low" or
"output-high" - are these referring to a static output of 0 and 1? 
 
"mode"
This controls several aspect of the pin (slew rate, pull up strength, etc) to 
meet
I2C specs for Standard/Fast mode vs High Speed mode.  I think the best
way is to map this to slew rate, which would require some explanation because
the meaning of slew rate differs depending on what pin function is selected:
- When I2C (*_SCL or *_SDA) function is selected for the pin: 0: Standard 
(100kbps)
  & Fast mode (400kbps), 1: High Speed mode (3.4Mbps)
- When IC_DM or IC_DP function is selected, 0: normal slew rate, 1: fast slew 
rate
- Else: 0: fast slew rate, 1: normal slew rate 

Also, it seems like I have to add "slew-rate" to dt_params[] in 
pinconf-generic.c and
pinctrl-bindings.txt.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] x86: intel-mid: add Merrifield platform support

[David Cohen]

This code was partially based on Mark Brown's previous work.

Signed-off-by: David Cohen 
Signed-off-by: Fei Yang 
Cc: Mark F. Brown 
Cc: Kuppuswamy Sathyanarayanan 
---

This patch should be applied right after the following one already submitted:
 - [PATCH 3/3] x86: intel-mid: add Clovertrail platform support

Br, David Cohen

---
 arch/x86/include/asm/intel-mid.h   |   2 +
 arch/x86/pci/intel_mid_pci.c   |   6 +-
 arch/x86/platform/intel-mid/Makefile   |   2 +-
 arch/x86/platform/intel-mid/intel-mid.c|   4 +
 arch/x86/platform/intel-mid/intel_mid_weak_decls.h |   1 +
 arch/x86/platform/intel-mid/mrfl.c | 103 +
 arch/x86/platform/intel-mid/sfi.c  |  34 +--
 7 files changed, 144 insertions(+), 8 deletions(-)
 create mode 100644 arch/x86/platform/intel-mid/mrfl.c

diff --git a/arch/x86/include/asm/intel-mid.h b/arch/x86/include/asm/intel-mid.h
index f8a8314..e34e097 100644
--- a/arch/x86/include/asm/intel-mid.h
+++ b/arch/x86/include/asm/intel-mid.h
@@ -52,6 +52,7 @@ enum intel_mid_cpu_type {
/* 1 was Moorestown */
INTEL_MID_CPU_CHIP_PENWELL = 2,
INTEL_MID_CPU_CHIP_CLOVERVIEW,
+   INTEL_MID_CPU_CHIP_TANGIER,
 };
 
 extern enum intel_mid_cpu_type __intel_mid_cpu_chip;
@@ -82,6 +83,7 @@ struct intel_mid_ops {
 #define INTEL_MID_OPS_INIT {\
DECLARE_INTEL_MID_OPS_INIT(penwell, INTEL_MID_CPU_CHIP_PENWELL), \
DECLARE_INTEL_MID_OPS_INIT(cloverview, INTEL_MID_CPU_CHIP_CLOVERVIEW), \
+   DECLARE_INTEL_MID_OPS_INIT(tangier, INTEL_MID_CPU_CHIP_TANGIER) \
 };
 
 #ifdef CONFIG_X86_INTEL_MID
diff --git a/arch/x86/pci/intel_mid_pci.c b/arch/x86/pci/intel_mid_pci.c
index 51384ca..84b9d67 100644
--- a/arch/x86/pci/intel_mid_pci.c
+++ b/arch/x86/pci/intel_mid_pci.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define PCIE_CAP_OFFSET0x100
 
@@ -219,7 +220,10 @@ static int intel_mid_pci_irq_enable(struct pci_dev *dev)
irq_attr.ioapic = mp_find_ioapic(dev->irq);
irq_attr.ioapic_pin = dev->irq;
irq_attr.trigger = 1; /* level */
-   irq_attr.polarity = 1; /* active low */
+   if (intel_mid_identify_cpu() == INTEL_MID_CPU_CHIP_TANGIER)
+   irq_attr.polarity = 0; /* active high */
+   else
+   irq_attr.polarity = 1; /* active low */
io_apic_set_pci_routing(>dev, dev->irq, _attr);
 
return 0;
diff --git a/arch/x86/platform/intel-mid/Makefile 
b/arch/x86/platform/intel-mid/Makefile
index 78a14ba..0a8ee70 100644
--- a/arch/x86/platform/intel-mid/Makefile
+++ b/arch/x86/platform/intel-mid/Makefile
@@ -1,4 +1,4 @@
-obj-$(CONFIG_X86_INTEL_MID) += intel-mid.o intel_mid_vrtc.o mfld.o
+obj-$(CONFIG_X86_INTEL_MID) += intel-mid.o intel_mid_vrtc.o mfld.o mrfl.o
 obj-$(CONFIG_EARLY_PRINTK_INTEL_MID) += early_printk_intel_mid.o
 
 # SFI specific code
diff --git a/arch/x86/platform/intel-mid/intel-mid.c 
b/arch/x86/platform/intel-mid/intel-mid.c
index bb0cf4d..2e59353 100644
--- a/arch/x86/platform/intel-mid/intel-mid.c
+++ b/arch/x86/platform/intel-mid/intel-mid.c
@@ -116,6 +116,10 @@ static void __cpuinit intel_mid_arch_setup(void)
case 0x35:
__intel_mid_cpu_chip = INTEL_MID_CPU_CHIP_CLOVERVIEW;
break;
+   case 0x3C:
+   case 0x4A:
+   __intel_mid_cpu_chip = INTEL_MID_CPU_CHIP_TANGIER;
+   break;
case 0x27:
default:
__intel_mid_cpu_chip = INTEL_MID_CPU_CHIP_PENWELL;
diff --git a/arch/x86/platform/intel-mid/intel_mid_weak_decls.h 
b/arch/x86/platform/intel-mid/intel_mid_weak_decls.h
index 9ebce04..a537ffc 100644
--- a/arch/x86/platform/intel-mid/intel_mid_weak_decls.h
+++ b/arch/x86/platform/intel-mid/intel_mid_weak_decls.h
@@ -16,3 +16,4 @@
  */
 extern void * __cpuinit get_penwell_ops(void) __attribute__((weak));
 extern void * __cpuinit get_cloverview_ops(void) __attribute__((weak));
+extern void * __init get_tangier_ops(void) __attribute__((weak));
diff --git a/arch/x86/platform/intel-mid/mrfl.c 
b/arch/x86/platform/intel-mid/mrfl.c
new file mode 100644
index 000..09d1015
--- /dev/null
+++ b/arch/x86/platform/intel-mid/mrfl.c
@@ -0,0 +1,103 @@
+/*
+ * mrfl.c: Intel Merrifield platform specific setup code
+ *
+ * (C) Copyright 2013 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2
+ * of the License.
+ */
+
+#include 
+
+#include 
+#include 
+
+#include "intel_mid_weak_decls.h"
+
+static unsigned long __init tangier_calibrate_tsc(void)
+{
+   unsigned long fast_calibrate;
+   u32 lo, hi, ratio, fsb, bus_freq;
+
+   /* *** */
+   /* Compute TSC:Ratio * FSB */
+   /* *** */
+
+   /* Compute Ratio */
+   rdmsr(MSR_PLATFORM_INFO, lo, hi);
+   

Re: [PATCH 2/2] intel_microcode, Fix long microcode load time when firmware file is missing

[Prarit Bhargava]

On 10/21/2013 10:43 PM, Ming Lei wrote:
> On Mon, Oct 21, 2013 at 10:25 PM, Prarit Bhargava  wrote:
>>
>>
>> On 10/21/2013 08:32 AM, Ming Lei wrote:
>>> On Mon, Oct 21, 2013 at 8:26 PM, Prarit Bhargava  wrote:
>
> And why don't you pass FW_ACTION_HOTPLUG? and you are sure
> that udev isn't required to handle your microcode update request?
>

 AFAICT in both cases, udev wasn't required to handle the cpu microcode 
 update.
 Both drivers use CMH to load the firmware which removes the need for udev 
 to do
 anything.  Admittedly maybe I've missed some odd use case but I don't 
 think it
 is necessary.
>>>
>>> OK, so I guess the CMH still need uevent to get notified, right?
>>
>> The code as it is _currently_ written does not use uevents to load the 
>> processor
>> firmware.  ie) call_usermodehelper does not need uevent to get notified, so I
>> think FW_ACTION_NOHOTPLUG is correct.
> 
> You need to make sure your patch won't break userspace in old
> distribution with your _currently_ code.
> 

AFAICT, Suse, Ubuntu, Linux Mint and Fedora all work with my changes.

P.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] firmware, fix request_firmware_nowait() freeze with no uevent

[Prarit Bhargava]

On 10/21/2013 10:35 PM, Ming Lei wrote:
> On Tue, Oct 22, 2013 at 6:24 AM, Prarit Bhargava  wrote:
>>
>>
>> On 10/21/2013 08:24 AM, Ming Lei wrote:
>>> On Mon, Oct 21, 2013 at 5:35 AM, Prarit Bhargava  wrote:
 If request_firmware_nowait() is called with uevent == NULL, the firmware
 completion is never marked complete resulting in a hang in the process.

 If uevent is undefined, that means we're not waiting on anything and the
 process should just clean up and complete.  While we're at it, add a
 debug dev_dbg() to indicate that the FW has not been found.

 Signed-off-by: Prarit Bhargava 
 Cc: x...@kernel.org
 Cc: herrmann.der.u...@googlemail.com
 Cc: ming@canonical.com
 Cc: tig...@aivazian.fsnet.co.uk
 ---
  drivers/base/firmware_class.c |6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

 diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
 index 10a4467..95778dc 100644
 --- a/drivers/base/firmware_class.c
 +++ b/drivers/base/firmware_class.c
 @@ -335,7 +335,8 @@ static bool fw_get_filesystem_firmware(struct device 
 *device,
 set_bit(FW_STATUS_DONE, >status);
 complete_all(>completion);
 mutex_unlock(_lock);
 -   }
 +   } else
 +   dev_dbg(device, "firmware: %s not found\n", buf->fw_id);

 return success;
  }
 @@ -886,6 +887,9 @@ static int _request_firmware_load(struct firmware_priv 
 *fw_priv, bool uevent,
 schedule_delayed_work(_priv->timeout_work, 
 timeout);

 kobject_uevent(_priv->dev.kobj, KOBJ_ADD);
 +   } else {
 +   /* if there is no uevent then just cleanup */
 +   schedule_delayed_work(_priv->timeout_work, 0);
 }
>>>
>>> This may not a good idea and might break current NOHOTPLUG
>>> users,
>>
>> Ming,
>>
>> The code is broken for all callers of request_firmware_nowait() with 
>> NOHOTPLUG
>> and CONFIG_FW_LOADER_USER_HELPER=y.  AFAICT with the two existing cases of 
>> this
>> usage in the kernel, both are broken and both are attempting to do the same
>> thing that I'm doing in the x86 microcode ATM.
>>
>> This is the situation as I understand it and please correct me if I'm wrong
>> about the execution path.  If I call request_firmware_nowait() with 
>> NOHOTPLUG I
>> am essentially saying that there is no uevent associated with this firmware
>> load; that is uevent = 0.  request_firmware_work_func() is called as 
>> scheduled
>> task, which results in a call to _request_firmware().  _request_firmware() 
>> first
>> calls _request_firmware_prepare() which eventually results in a call to
>> __allocate_fw_buf() which does an init_completion(>completion).
>>
>> Returning back up the stack to _request_firmware() we eventually call
>> fw_get_filesystem_firmware().  _If the firmware does not exist_ success is 
>> false
>> and the if (success) loop is not executed, and it is important to note that 
>> the
>> complete_all(>completion) is _not_ called.  fw_get_filesystem_firmware()
>> returns an error so that fw_load_from_user_helper() is called from
>> _request_firmware().
>>
>> fw_load_from_user_helper() eventually calls _request_firmware_load() and 
>> this is
>> where we get into a problem.  fw_load_from_user_helper() calls all the file
>> creation, etc., and then hits this chunk of code:
>>
>> if (uevent) {
>> dev_set_uevent_suppress(f_dev, false);
>> dev_dbg(f_dev, "firmware: requesting %s\n", buf->fw_id);
>> if (timeout != MAX_SCHEDULE_TIMEOUT)
>> schedule_delayed_work(_priv->timeout_work, 
>> timeout);
>>
>> kobject_uevent(_priv->dev.kobj, KOBJ_ADD);
>> }
>>
>> wait_for_completion(>completion);
>>
>> As I previously said, we've been called with NOHOTPLUG, ie) uevent = 0.  That
>> means we skip down to the wait_for_completion(>completion) ... and we 
>> wait
>> ... forever.
> 
> Yes, it is exactly the previous design on NOHOTPLUG, because
> firmware loader has to wait for the handling from user space, and
> no one can predict when userspace comes because of no
> notification. For example, the userspace may be 'some inputting
> from shell by someone once he is free', :-) so it is difficult to set a
> timeout explicitly for the handling.
> 
> But the requests can be killed before suspend & shutdown, so
> it is still OK.
> 
> That is why NOHOTPLUG isn't encouraged to be taken, actually
> I don't suggest you to do that too, :-)
Okay ... I can certainly switch to HOTPLUG.

> 
> You need to make sure your approach won't break micro-code
> update application in current/previous distributions.

I've tested the following distributions today on a Dell PE 1850:  Ubuntu, SuSe,
Linux Mint, and of course Fedora.  I do not see any issues with 

Re: [PATCH v2 11/13] NTB: convert to dmaengine_unmap_data

[Jon Mason]

On Tue, Oct 22, 2013 at 02:29:36PM -0700, Dan Williams wrote:
> On Fri, Oct 18, 2013 at 6:06 PM, Jon Mason  wrote:
> > On Fri, Oct 18, 2013 at 07:35:31PM +0200, Bartlomiej Zolnierkiewicz wrote:
> >> Use the generic unmap object to unmap dma buffers.
> >>
> >> As NTB can be compiled without DMA_ENGINE support add
> >
> > Seems like the stubs should be added outside of this patch.
> 
> I think they are ok here as this is the only driver that uses them.
> The alternative is a new api patch without a user.
> 
> > Also, the
> > comment implies that NTB could not be compiled without DMA_ENGINE
> > support before, which it could be.
> 
> Hmm, I read it as "since NTB *can* be compiled without dmaengine here
> are some stubs".

This poses an overall question of whether it would simply be better to
abstract all of the with/without DMA_ENGINE part and simply remap it
to memcpy if DMA_ENGINE is not set (or if the DMA engine is
hotplugged).  Of course, this is outside the scope of this patch.

> >
> >> stub functions to  for dma_set_unmap(),
> >> dmaengine_get_unmap_data() and dmaengine_unmap_put().
> >>
> >> Cc: Dan Williams 
> >> Cc: Vinod Koul 
> >> Cc: Tomasz Figa 
> >> Cc: Dave Jiang 
> >> Cc: Jon Mason 
> >> Signed-off-by: Bartlomiej Zolnierkiewicz 
> >> Signed-off-by: Kyungmin Park 
> >> ---
> >>  drivers/ntb/ntb_transport.c | 63 
> >> +
> >>  include/linux/dmaengine.h   | 15 +++
> >>  2 files changed, 61 insertions(+), 17 deletions(-)
> >>
> >> diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
> >> index 12a9e83..fc6bbf1 100644
> >> --- a/drivers/ntb/ntb_transport.c
> >> +++ b/drivers/ntb/ntb_transport.c
> >> @@ -1034,7 +1034,7 @@ static void ntb_async_rx(struct ntb_queue_entry 
> >> *entry, void *offset,
> >>   struct dma_chan *chan = qp->dma_chan;
> >>   struct dma_device *device;
> >>   size_t pay_off, buff_off;
> >> - dma_addr_t src, dest;
> >> + struct dmaengine_unmap_data *unmap;
> >>   dma_cookie_t cookie;
> >>   void *buf = entry->buf;
> >>   unsigned long flags;
> >> @@ -1054,27 +1054,41 @@ static void ntb_async_rx(struct ntb_queue_entry 
> >> *entry, void *offset,
> >>   if (!is_dma_copy_aligned(device, pay_off, buff_off, len))
> >>   goto err1;
> >>
> >> - dest = dma_map_single(device->dev, buf, len, DMA_FROM_DEVICE);
> >> - if (dma_mapping_error(device->dev, dest))
> >> + unmap = dmaengine_get_unmap_data(device->dev, 2, GFP_NOIO);
> >> + if (!unmap)
> >>   goto err1;
> >>
> >> - src = dma_map_single(device->dev, offset, len, DMA_TO_DEVICE);
> >> - if (dma_mapping_error(device->dev, src))
> >> + unmap->addr[0] = dma_map_page(device->dev, virt_to_page(offset),
> >> +   pay_off, len, DMA_TO_DEVICE);
> >> + if (dma_mapping_error(device->dev, unmap->addr[0]))
> >>   goto err2;
> >>
> >> - flags = DMA_COMPL_DEST_UNMAP_SINGLE | DMA_COMPL_SRC_UNMAP_SINGLE |
> >> + unmap->to_cnt = 1;
> >> +
> >> + unmap->addr[1] = dma_map_page(device->dev, virt_to_page(buf),
> >> +   buff_off, len, DMA_FROM_DEVICE);
> >> + if (dma_mapping_error(device->dev, unmap->addr[1]))
> >> + goto err2;
> >> +
> >> + unmap->from_cnt = 1;
> >> +
> >> + flags = DMA_COMPL_SKIP_SRC_UNMAP | DMA_COMPL_SKIP_DEST_UNMAP |
> >>   DMA_PREP_INTERRUPT;
> >> - txd = device->device_prep_dma_memcpy(chan, dest, src, len, flags);
> >> + txd = device->device_prep_dma_memcpy(chan, unmap->addr[1],
> >> +  unmap->addr[0], len, flags);
> >
> > I must say, as a user I dislike this interface much less than the
> > previous.  Can we abstract all of this away in a helper function
> > that simply takes the src, dest, and len, then maps and calls
> > device_prep_dma_memcpy?  The driver does not keep track of the
> > dmaengine_unmap_data, so the helper function could simply return an
> > error if something isn't happy.  Thoughts?
> 
> Well, that's almost dma_async_memcpy_pg_to_pg, except NTB wants it's
> own callback.  We could add a new helper that does
> dma_async_memcpy_pg_to_pg() with callback, but I want to do a larger
> reorganization of dmaengine to try to kill off the need to specify the
> callback after ->prep().  Can we go with as is for now and cleanup
> later?  The same is happening to the other clients in this patchset
> (async_tx, dmatest, net_dma) in terms of picking up unmap
> responsibility from the drivers.  It looks "worse" for each client at
> this stage, but the overall effect is:
> 
>34 files changed, 538 insertions(+), 1157 deletions(-)

That is fine.  It can be like this in the short term.

Thanks,
Jon

> 
> --
> Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

[GIT PULL] tip/timers/core: Hopefully last few timekeeping changes for 3.13

[John Stultz]

Hey Thomas, Ingo,
Here are a few last timekeeping changes I've got queued for 3.13,
for tip/timers/core.

This includes:

* An improved ssize_t fix for sysfs_get_uname

* Alarmtimer return fix, since ENOTSUPP isn't exported to userland

* Comment typo fixes

Let me know if you have any thoughts or concerns!

thanks
-john



The following changes since commit 4a7d3e8a9939cf8073c247286d81cbe0ae48eba2:

  clocksource: arch_timer: Do not register arch_sys_counter twice
(2013-10-16 08:30:03 +0200)

are available in the git repository at:

  git://git.linaro.org/people/jstultz/linux.git fortglx/3.13/time

for you to fetch changes up to 891292a767c2453af0e5be9465e95b06b4b29ebe:

  time: Fix signedness bug in sysfs_get_uname() and its callers
(2013-10-18 16:45:58 -0700)


KOSAKI Motohiro (1):
  alarmtimer: return EINVAL instead of ENOTSUPP if rtcdev doesn't exist

Patrick Palka (1):
  time: Fix signedness bug in sysfs_get_uname() and its callers

Xie XiuQi (1):
  timekeeping: Fix some trivial typos in comments

 kernel/time/alarmtimer.c| 4 ++--
 kernel/time/clockevents.c   | 2 +-
 kernel/time/clocksource.c   | 2 +-
 kernel/time/tick-internal.h | 2 +-
 kernel/time/timekeeping.c   | 3 ++-
 5 files changed, 7 insertions(+), 6 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 13/13] dmaengine: remove DMA unmap flags

[Jon Mason]

On Tue, Oct 22, 2013 at 02:08:34PM -0700, Dan Williams wrote:
> From: Bartlomiej Zolnierkiewicz 
> 
> Remove no longer needed DMA unmap flags:
> - DMA_COMPL_SKIP_SRC_UNMAP
> - DMA_COMPL_SKIP_DEST_UNMAP
> - DMA_COMPL_SRC_UNMAP_SINGLE
> - DMA_COMPL_DEST_UNMAP_SINGLE
> 
> Cc: Viresh Kumar 
> Cc: Tejun Heo 
> Cc: Vinod Koul 
> Cc: Mauro Carvalho Chehab 
> Cc: David Woodhouse 
> Cc: Jon Mason 

For NTB relevant parts
Acked-by: Jon Mason 

> Cc: Mark Brown 
> Cc: Tomasz Figa 
> Cc: Dave Jiang 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> Signed-off-by: Kyungmin Park 
> Signed-off-by: Dan Williams 
> ---
> 
>  Resend to:
>   1/ add it to the new dmaengine patchwork
>   2/ cc maintainers of affected drivers
>   3/ fixup some mail addresses
> 
>  crypto/async_tx/async_memcpy.c   |3 +--
>  crypto/async_tx/async_pq.c   |1 -
>  crypto/async_tx/async_raid6_recov.c  |8 ++--
>  crypto/async_tx/async_xor.c  |6 ++
>  drivers/ata/pata_arasan_cf.c |3 +--
>  drivers/dma/dmaengine.c  |3 +--
>  drivers/dma/dmatest.c|3 +--
>  drivers/dma/ioat/dma.c   |3 +--
>  drivers/dma/ioat/dma_v3.c|   12 +++-
>  drivers/media/platform/m2m-deinterlace.c |3 +--
>  drivers/media/platform/timblogiw.c   |2 +-
>  drivers/misc/carma/carma-fpga.c  |3 +--
>  drivers/mtd/nand/atmel_nand.c|3 +--
>  drivers/mtd/nand/fsmc_nand.c |2 --
>  drivers/net/ethernet/micrel/ks8842.c |6 ++
>  drivers/ntb/ntb_transport.c  |3 +--
>  drivers/spi/spi-dw-mid.c |4 ++--
>  include/linux/dmaengine.h|   18 --
>  18 files changed, 25 insertions(+), 61 deletions(-)
> 
> diff --git a/crypto/async_tx/async_memcpy.c b/crypto/async_tx/async_memcpy.c
> index 72750214f779..f8c0b8dbeb75 100644
> --- a/crypto/async_tx/async_memcpy.c
> +++ b/crypto/async_tx/async_memcpy.c
> @@ -56,8 +56,7 @@ async_memcpy(struct page *dest, struct page *src, unsigned 
> int dest_offset,
>   unmap = dmaengine_get_unmap_data(device->dev, 2, GFP_NOIO);
>  
>   if (unmap && is_dma_copy_aligned(device, src_offset, dest_offset, len)) 
> {
> - unsigned long dma_prep_flags = DMA_COMPL_SKIP_SRC_UNMAP |
> -DMA_COMPL_SKIP_DEST_UNMAP;
> + unsigned long dma_prep_flags = 0;
>  
>   if (submit->cb_fn)
>   dma_prep_flags |= DMA_PREP_INTERRUPT;
> diff --git a/crypto/async_tx/async_pq.c b/crypto/async_tx/async_pq.c
> index 4126b56fbc01..d05327caf69d 100644
> --- a/crypto/async_tx/async_pq.c
> +++ b/crypto/async_tx/async_pq.c
> @@ -62,7 +62,6 @@ do_async_gen_syndrome(struct dma_chan *chan,
>   dma_addr_t dma_dest[2];
>   int src_off = 0;
>  
> - dma_flags |= DMA_COMPL_SKIP_SRC_UNMAP | DMA_COMPL_SKIP_DEST_UNMAP;
>   if (submit->flags & ASYNC_TX_FENCE)
>   dma_flags |= DMA_PREP_FENCE;
>  
> diff --git a/crypto/async_tx/async_raid6_recov.c 
> b/crypto/async_tx/async_raid6_recov.c
> index a3a72a784421..934a84981495 100644
> --- a/crypto/async_tx/async_raid6_recov.c
> +++ b/crypto/async_tx/async_raid6_recov.c
> @@ -47,9 +47,7 @@ async_sum_product(struct page *dest, struct page **srcs, 
> unsigned char *coef,
>   struct device *dev = dma->dev;
>   dma_addr_t pq[2];
>   struct dma_async_tx_descriptor *tx;
> - enum dma_ctrl_flags dma_flags = DMA_COMPL_SKIP_SRC_UNMAP |
> - DMA_COMPL_SKIP_DEST_UNMAP |
> - DMA_PREP_PQ_DISABLE_P;
> + enum dma_ctrl_flags dma_flags = DMA_PREP_PQ_DISABLE_P;
>  
>   if (submit->flags & ASYNC_TX_FENCE)
>   dma_flags |= DMA_PREP_FENCE;
> @@ -113,9 +111,7 @@ async_mult(struct page *dest, struct page *src, u8 coef, 
> size_t len,
>   dma_addr_t dma_dest[2];
>   struct device *dev = dma->dev;
>   struct dma_async_tx_descriptor *tx;
> - enum dma_ctrl_flags dma_flags = DMA_COMPL_SKIP_SRC_UNMAP |
> - DMA_COMPL_SKIP_DEST_UNMAP |
> - DMA_PREP_PQ_DISABLE_P;
> + enum dma_ctrl_flags dma_flags = DMA_PREP_PQ_DISABLE_P;
>  
>   if (submit->flags & ASYNC_TX_FENCE)
>   dma_flags |= DMA_PREP_FENCE;
> diff --git a/crypto/async_tx/async_xor.c b/crypto/async_tx/async_xor.c
> index d2cc77d501c7..3c562f5a60bb 100644
> --- a/crypto/async_tx/async_xor.c
> +++ b/crypto/async_tx/async_xor.c
> @@ -41,7 +41,7 @@ do_async_xor(struct dma_chan *chan, struct 
> dmaengine_unmap_data *unmap,
>   dma_async_tx_callback cb_fn_orig = submit->cb_fn;
>   void *cb_param_orig = submit->cb_param;
>   enum async_tx_flags flags_orig = 

Re: [PATCH 2/2] mrst_max3110: fix SPI UART interrupt parameters

[David Cohen]

On 10/22/2013 01:30 PM, David Cohen wrote:

On 10/22/2013 12:46 PM, Alexander Shiyan wrote:

The change in the max3110 driver makes the IRQ handling threaded, now
the handler is called only once per received character. Without that
change, we had many (more than 100) interrupts per one received
character.

Unfortunately, SFI interface does not support IRQ polarity and
triggering modes, so we have to keep the hacks as hard-coded device
names and IRQ numbers until we switch to ACPI.

Edge-triggered IRQ still supported to keep old platforms working.
Use platform data to pass the irq mode argument.

Signed-off-by: Ivan Gorinov 
Signed-off-by: Li Ning 
Signed-off-by: David Cohen 

...

+++ b/include/linux/serial_max3110.h
@@ -0,0 +1,16 @@
+#ifndef _LINUX_SERIAL_MAX3110_H
+#define _LINUX_SERIAL_MAX3110_H
+
+/**
+ * struct plat_max3110 - MAX3110 SPI UART platform data
+ * @irq_edge_trigger: if IRQ is edge triggered
+ *
+ * You should use this structure in your machine description to specify
+ * how the MAX3110 is connected.
+ *
+ */
+struct plat_max3110 {
+int irq_edge_triggered;
+};
+
+#endif
--


Is just resource->flags for IRQ can be reused for handle such case?


I believe your suggestion makes perfect sense. I'll rework it.


Looks like isp_device has no place for 'resource'. In this case pdata 
seems to be the way to go here.

Or maybe there's a better way to recommend?

Br, David Cohen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 01/14] DTS: ARM: OMAP3-N900: Add pinctrl for i2c devices

[Sebastian Reichel]

Add pin muxing support for the Nokia N900 i2c controllers.

Signed-off-by: Sebastian Reichel 
---
 arch/arm/boot/dts/omap3-n900.dts | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index e13b697..ad4edd9 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -28,7 +28,35 @@
 
 };
 
+_pmx_core {
+   pinctrl-names = "default";
+
+   i2c1_pins: pinmux_i2c1_pins {
+   pinctrl-single,pins = <
+   0x18a (PIN_INPUT_PULLUP | MUX_MODE0)/* i2c1_scl */
+   0x18c (PIN_INPUT_PULLUP | MUX_MODE0)/* i2c1_sda */
+   >;
+   };
+
+   i2c2_pins: pinmux_i2c2_pins {
+   pinctrl-single,pins = <
+   0x18e (PIN_INPUT_PULLUP | MUX_MODE0)/* i2c2_scl */
+   0x190 (PIN_INPUT_PULLUP | MUX_MODE0)/* i2c2_sda */
+   >;
+   };
+
+   i2c3_pins: pinmux_i2c3_pins {
+   pinctrl-single,pins = <
+   0x192 (PIN_INPUT_PULLUP | MUX_MODE0)/* i2c3_scl */
+   0x194 (PIN_INPUT_PULLUP | MUX_MODE0)/* i2c3_sda */
+   >;
+   };
+};
+
  {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
clock-frequency = <220>;
 
twl: twl@48 {
@@ -39,6 +67,7 @@
 };
 
 #include "twl4030.dtsi"
+#include "twl4030_omap3.dtsi"
 
 _gpio {
ti,pullups  = <0x0>;
@@ -46,10 +75,16 @@
 };
 
  {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
clock-frequency = <40>;
 };
 
  {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+
clock-frequency = <10>;
 };
 
-- 
1.8.4.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/