Re: 3.15.0-rc2 radeon HD 7480D [Aruba] blank display
On Mon, Apr 21, 2014 at 10:34 PM, Ken Moffat wrote:
> On Tue, Apr 22, 2014 at 03:31:06AM +0100, Ken Moffat wrote:
>
> [ resending, somehow lkml dropped out of the Cc. ]
>
>> On Tue, Apr 22, 2014 at 12:19:40AM +0100, Ken Moffat wrote:
>> > On Mon, Apr 21, 2014 at 05:29:27PM -0400, Ed Tomlinson wrote:
>>
>> > > Ken,
>> > >
>> > > You might want to try reverting:
>> > >
>> > > commit 379dfc25e257ffe10eb53b86d2375f7c0f4f33ef
>> > > Author: Alex Deucher
>> > > Date: Mon Apr 7 10:33:46 2014 -0400
>> > >
>> > > drm/radeon/dp: switch to the common i2c over aux code
>> > >
>> > > Provides a nice cleanup in radeon.
>> > >
>> > > Signed-off-by: Alex Deucher
>> > > Signed-off-by: Christian König
>> > >
>> > > This fixed a similar problem here (see the drm pull thread for rc1)
>> > >
>> > > Thanks
>> > > Ed Tomlinson
>> >
>> > Tried reverting that from rc2, but it didn't help. Thanks anyway.
>> >
>>
>> Well, I *believed* I had created a patch for that commit, and
>> reverted it from -rc2 with patch -R. But I've now bisected through
>> drivers/gpu/drm between v3.14.0 and v3.15-rc2 and the bisection
>> pointed to that same commit, so I guess I did something wrong.
>>
>> There were a couple of other issues along the way (mounting nfs
>> hung on one commit, startx hung on several of the commits, but I've
>> marked those as "good" because I had a display, even if the system
>> was not usable).
>>
>> I've now gone back to linus' tree that I cloned a few hours ago,
>> i.e.
>> commit c089b229dfdd09d59a11d8bc2344bf8196d575ce
>> Merge: 9ac03675010a 0565103d1adb
>> Author: Linus Torvalds
>> Date: Mon Apr 21 10:05:35 2014 -0700
>>
>> Merge branch 'for-linus' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml
>>
>> created a branch, and *definitely* reverted
>> 379dfc25e257ffe10eb53b86d2375f7c0f4f33ef (using git revert) in that
>> branch. And this version works fine.
>>
>> So belatedly I see that I seem to have the same problem as Ed. Or
>> at least that the same commit is causing both our problems.
>>
>> Alex - do you need any more information from me to help with this ?
The attached patch should fix it.
Thanks,
Alex
From 9cd764fd57bb2a4e5f618d0f8a64c8154a820688 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Tue, 22 Apr 2014 01:49:28 -0400
Subject: [PATCH] drm/radeon/aux: fix hpd assignment for aux bus
The hpd (hot plug detect) pin assignment got lost
in the conversion to to the common i2c over aux
code. Without this information, aux transactions
do not work properly. Fixes DP failures.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_dp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c b/drivers/gpu/drm/radeon/atombios_dp.c
index 1593652..bc0119f 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -209,6 +209,7 @@ void radeon_dp_aux_init(struct radeon_connector *radeon_connector)
{
int ret;
+ radeon_connector->ddc_bus->rec.hpd = radeon_connector->hpd.hpd;
radeon_connector->ddc_bus->aux.dev = radeon_connector->base.kdev;
radeon_connector->ddc_bus->aux.transfer = radeon_dp_aux_transfer;
ret = drm_dp_aux_register_i2c_bus(_connector->ddc_bus->aux);
--
1.7.11.7
Re: Ext4: deadlock occurs when running fsstress and ENOSPC errors are seen.
Hi Darrick,
Thanks for the reply, sorry for responding late.
On Wed, Apr 16, 2014 at 11:16 PM, Darrick J. Wong
wrote:
> On Wed, Apr 16, 2014 at 01:21:34PM +0530, Amit Sahrawat wrote:
>> Sorry Ted, if it caused the confusion.
>>
>> There were actually 2 parts to the problem, the logs in the first mail
>> were from the original situation – where in there were many block
>> groups and error prints also showed that.
>>
>> EXT4-fs error (device sda1): ext4_mb_generate_buddy:742: group 1493, 0
>> clusters in bitmap, 58339 in gd
>> EXT4-fs error (device sda1): ext4_mb_generate_buddy:742: group 1000, 0
>> clusters in bitmap, 3 in gd
>> EXT4-fs error (device sda1): ext4_mb_generate_buddy:742: group 1425, 0
>> clusters in bitmap, 1 in gd
>> JBD2: Spotted dirty metadata buffer (dev = sda1, blocknr = 0). There's
>> a risk of filesystem corruption in case of system crash.
>> JBD2: Spotted dirty metadata buffer (dev = sda1, blocknr = 0). There's
>> a risk of filesystem corruption in case of system crash.
>>
>> 1)Original case – when the disk got corrupted and we only had the
>> logs and the hung task messages. But not the HDD on which issue was
>> observed.
>> 2)In order to reproduce the problem as was coming through the logs
>> (which highlighted the problem in the bitmap corruption). To minimize
>> the environment and make a proper case, we created a smaller partition
>> size and with only 2 groups. And intentionally corrupted the group 1
>> (our intention was just to replicate the error scenario).
>
> I'm assuming that the original broken fs simply had a corrupt block bitmap,
> and
> that the dd thing was just to simulate that corruption in a testing
> environment?
Yes, we did so in order to replicate the error scenario.
>
>> 3)After corruption we used ‘fsstress’ - we got the similar problem
>> as was coming the original logs. – We shared our analysis after this
>> point for looping in the writepages part the free blocks mismatch.
>
> Hm. I tried it with 3.15-rc1 and didn't see any hangs. Corrupt bitmaps shut
> down allocations from the block group and the FS continues, as expected.
>
We are using kernel version 3.8, so cannot switch to 3.15-rc1. It is a
limitation currently.
>> 4)We came across ‘Darrick’ patches(in which it also mentioned about
>> how to corrupt to reproduce the problem) and applied on our
>> environment. It solved the initial problem about the looping in
>> writepages, but now we got hangs at other places.
>
> There are hundreds of Darrick patches ... to which one are you referring? :)
> (What was the subject line?)
>
ext4: error out if verifying the block bitmap fails
ext4: fix type declaration of ext4_validate_block_bitmap
ext4: mark block group as corrupt on block bitmap error
ext4: mark block group as corrupt on inode bitmap error
ext4: mark group corrupt on group descriptor checksum
ext4: don't count free clusters from a corrupt block group
So, the patches helps in marking the block group as corrupt and avoids
further allocation. But when we consider the normal write path using
write_begin. Since, there is mismatch between the free cluster count
from the group descriptor and the bitmap. In that case it marks the
pages dirty by copying dirty but later it get ENOSPC from the
writepages when it actually does the allocation.
So, our doubt is if we are marking the block group as corrupt, we
should also subtract the block group count from the
s_freeclusters_counter. This will make sure we have the valid
freecluster count and error ‘ENOSPC’ can be returned from the
write_begin, instead of propagating such paths till the writepages.
We made change like this:
@@ -737,14 +737,18 @@ void ext4_mb_generate_buddy(struct super_block *sb,
grp->bb_fragments = fragments;
if (free != grp->bb_free) {
+ struct ext4_sb_info *sbi = EXT4_SB(sb);
ext4_grp_locked_error(sb, group, 0, 0,
"%u clusters in bitmap, %u in gd; "
"block bitmap corrupt.",
free, grp->bb_free);
/*
* If we intend to continue, we consider group descriptor
* corrupt and update bb_free using bitmap value
*/
+ percpu_counter_sub(>s_freeclusters_counter, grp->bb_free);
grp->bb_free = free;
set_bit(EXT4_GROUP_INFO_BBITMAP_CORRUPT_BIT, >bb_state);
}
mb_set_largest_free_order(sb, grp);
Is this the correct method? Or are missing something in this? Please
share your opinion.
>> Using ‘tune2fs’ is not a viable solution in our case, we can only
>> provide the solution via. the kernel changes. So, we made the changes
>> as shared earlier.
>
> Would it help if you could set errors=remount-ro in mke2fs?
>
Sorry, we cannot reformat or use tune2fs to change the ‘errors’ value.
> --D
>> So the question isn't how the file system got corrupted, but
min() and max() have warning: comparison of distinct pointer types lacks a cast
Hi all Have these warning messages when compiling kernel. Anyone know what's wrong? Regards. In file included from mm/readahead.c:10:0: mm/readahead.c: In function 'max_sane_readahead': include/linux/kernel.h:713:17: warning: comparison of distinct pointer types lacks a cast [enabled by default] (void) (&_min1 == &_min2); \ ^ mm/readahead.c:242:9: note: in expansion of macro 'min' return min(nr, MAX_READAHEAD); ^ --- mm/rmap.c:1279:22: note: in expansion of macro 'min' #define CLUSTER_SIZE min(32*PAGE_SIZE, PMD_SIZE) ^ mm/rmap.c:1280:25: note: in expansion of macro 'CLUSTER_SIZE' #define CLUSTER_MASK (~(CLUSTER_SIZE - 1)) ^ mm/rmap.c:1298:39: note: in expansion of macro 'CLUSTER_MASK' address = (vma->vm_start + cursor) & CLUSTER_MASK; ^ -- 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] cgroup: use uninitialized_var() for may-be uninitialized variable
To suppress this warning:
warning: ‘err’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
int err;
^
Use the uninitialized_var() to decalre err. It also serves to be good
documetation.
Signed-off-by: Jianyu Zhan
---
kernel/cgroup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 24675f5..930569c 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -4144,7 +4144,7 @@ static int create_css(struct cgroup *cgrp, struct
cgroup_subsys *ss)
{
struct cgroup *parent = cgrp->parent;
struct cgroup_subsys_state *css;
- int err;
+ int uninitialized_var(err);
lockdep_assert_held(_mutex);
--
2.0.0-rc0
--
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: LLVMLinux: Wrap -mno-80387 with cc-option
From: Behan Webster Wrap -mno-80387 gcc options with cc-option so they don't break clang. Signed-off-by: Behan Webster --- arch/x86/Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/x86/Makefile b/arch/x86/Makefile index d1b7c37..ce6ad7e 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -83,7 +83,9 @@ else KBUILD_CFLAGS += -m64 # Don't autogenerate traditional x87, MMX or SSE instructions -KBUILD_CFLAGS += -mno-mmx -mno-sse -mno-80387 -mno-fp-ret-in-387 +KBUILD_CFLAGS += -mno-mmx -mno-sse +KBUILD_CFLAGS += $(call cc-option,-mno-80387) +KBUILD_CFLAGS += $(call cc-option,-mno-fp-ret-in-387) # Use -mpreferred-stack-boundary=3 if supported. KBUILD_CFLAGS += $(call cc-option,-mpreferred-stack-boundary=3) -- 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/
[f2fs-dev][PATCH 2/2] f2fs: introduce f2fs_seek_block to support SEEK_{DATA,HOLE} in llseek
In This patch we introduce f2fs_seek_block to support SEEK_{DATA,HOLE} of
lseek(2).
Signed-off-by: Chao Yu
---
fs/f2fs/f2fs.h |6
fs/f2fs/file.c | 96 +++-
2 files changed, 101 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 97da71d..b1d6699 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1074,6 +1074,12 @@ static inline void f2fs_stop_checkpoint(struct
f2fs_sb_info *sbi)
((is_inode_flag_set(F2FS_I(i), FI_ACL_MODE)) ? \
(F2FS_I(i)->i_acl_mode) : ((i)->i_mode))
+/* get offset of first page in next direct node */
+#define PGOFS_OF_NEXT_DNODE(pgofs, fi) \
+ ((pgofs < ADDRS_PER_INODE(fi)) ? ADDRS_PER_INODE(fi) : \
+ (pgofs - ADDRS_PER_INODE(fi) + 2 * ADDRS_PER_BLOCK - 1) / \
+ ADDRS_PER_BLOCK * ADDRS_PER_BLOCK + ADDRS_PER_INODE(fi))
+
/*
* file.c
*/
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 60e7d54..da1c3b7 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -194,6 +194,100 @@ out:
return ret;
}
+static loff_t f2fs_seek_block(struct file *file, loff_t offset, int whence)
+{
+ struct inode *inode = file->f_mapping->host;
+ loff_t maxbytes = inode->i_sb->s_maxbytes;
+ struct dnode_of_data dn;
+ pgoff_t pgofs, end_offset, end;
+ loff_t data_ofs = 0, isize;
+ int err = 0;
+
+ mutex_lock(>i_mutex);
+
+ isize = i_size_read(inode);
+ if (offset >= isize)
+ goto fail;
+
+ /* handle inline data case */
+ if (f2fs_has_inline_data(inode)) {
+ if (whence == SEEK_HOLE)
+ data_ofs = isize;
+ goto found;
+ }
+
+ pgofs = (pgoff_t)(offset >> PAGE_CACHE_SHIFT);
+ end = (pgoff_t)(isize >> PAGE_CACHE_SHIFT);
+
+ while (pgofs < end) {
+ set_new_dnode(, inode, NULL, NULL, 0);
+ err = get_dnode_of_data(, pgofs, LOOKUP_NODE_RA);
+ if (err && err != -ENOENT) {
+ goto fail;
+ } else if (err == -ENOENT) {
+ /* direct node is not exist */
+ if (whence == SEEK_DATA) {
+ pgofs = PGOFS_OF_NEXT_DNODE(pgofs,
+ F2FS_I(inode));
+ continue;
+ } else {
+ data_ofs = pgofs << PAGE_CACHE_SHIFT;
+ goto found;
+ }
+ }
+
+ end_offset = IS_INODE(dn.node_page) ?
+ ADDRS_PER_INODE(F2FS_I(inode)) : ADDRS_PER_BLOCK;
+
+ /* find data/hole in dnode block */
+ for (; dn.ofs_in_node < end_offset; dn.ofs_in_node++, pgofs++) {
+ block_t blkaddr;
+ blkaddr = datablock_addr(dn.node_page, dn.ofs_in_node);
+
+ if ((whence == SEEK_DATA && blkaddr != NULL_ADDR) ||
+ (whence == SEEK_HOLE && blkaddr == NULL_ADDR)) {
+ f2fs_put_dnode();
+ data_ofs = pgofs << PAGE_CACHE_SHIFT;
+ goto found;
+ }
+ }
+ f2fs_put_dnode();
+ }
+
+ data_ofs = pgofs << PAGE_CACHE_SHIFT;
+ if (data_ofs > isize) {
+ if (whence == SEEK_DATA)
+ goto fail;
+ else
+ data_ofs = isize;
+ }
+found:
+ mutex_unlock(>i_mutex);
+ return vfs_setpos(file, data_ofs, maxbytes);
+fail:
+ mutex_unlock(>i_mutex);
+ return -ENXIO;
+}
+
+static loff_t f2fs_llseek(struct file *file, loff_t offset, int whence)
+{
+ struct inode *inode = file->f_mapping->host;
+ loff_t maxbytes = inode->i_sb->s_maxbytes;
+
+ switch (whence) {
+ case SEEK_SET:
+ case SEEK_CUR:
+ case SEEK_END:
+ return generic_file_llseek_size(file, offset, whence,
+ maxbytes, i_size_read(inode));
+ case SEEK_DATA:
+ case SEEK_HOLE:
+ return f2fs_seek_block(file, offset, whence);
+ }
+
+ return -EINVAL;
+}
+
static int f2fs_file_mmap(struct file *file, struct vm_area_struct *vma)
{
file_accessed(file);
@@ -678,7 +772,7 @@ long f2fs_compat_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
#endif
const struct file_operations f2fs_file_operations = {
- .llseek = generic_file_llseek,
+ .llseek = f2fs_llseek,
.read = do_sync_read,
.write = do_sync_write,
.aio_read = generic_file_aio_read,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
[f2fs-dev][PATCH 1/2] f2fs: handle inline data independently in f2fs_bmap
We'd better handle inline data case independently in f2fs_bmap().
It can reduce our handling time in f2fs_bmap().
Signed-off-by: Chao Yu
---
fs/f2fs/data.c |5 +
1 file changed, 5 insertions(+)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 6b89b25..150c12a 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -1058,6 +1058,11 @@ static int f2fs_set_data_page_dirty(struct page *page)
static sector_t f2fs_bmap(struct address_space *mapping, sector_t block)
{
+ struct inode *inode = mapping->host;
+
+ if (f2fs_has_inline_data(inode))
+ return 0;
+
return generic_block_bmap(mapping, block, get_data_block);
}
--
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/
[PATCH] device_cgroup: explicitly init the early_init field
For a cgroup subsystem who should init early, then it should carefully
take care of the implementation of css_alloc, because it will be called
before mm_init() setup the world.
Luckily we don't, and we better explicitly assign the early_init field
to 0, for document reason.
Signed-off-by: Jianyu Zhan
---
security/device_cgroup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/security/device_cgroup.c b/security/device_cgroup.c
index 8365909..dd9614f 100644
--- a/security/device_cgroup.c
+++ b/security/device_cgroup.c
@@ -688,6 +688,7 @@ struct cgroup_subsys devices_cgrp_subsys = {
.css_online = devcgroup_online,
.css_offline = devcgroup_offline,
.base_cftypes = dev_cgroup_files,
+ .early_init = 0,
};
/**
--
2.0.0-rc0
--
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] netprio_cgroup: explicitly init the early_init field
For a cgroup subsystem who should init early, then it should carefully
take care of the implementation of css_alloc, because it will be called
before mm_init() setup the world.
Luckily we don't, and we better explicitly assign the early_init field
to 0, for document reason.
Signed-off-by: Jianyu Zhan
---
net/core/netprio_cgroup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c
index 13ddd68..fc21035 100644
--- a/net/core/netprio_cgroup.c
+++ b/net/core/netprio_cgroup.c
@@ -250,6 +250,7 @@ struct cgroup_subsys net_prio_cgrp_subsys = {
.css_free = cgrp_css_free,
.attach = net_prio_attach,
.base_cftypes = ss_files,
+ .early_init = 0,
};
static int netprio_device_event(struct notifier_block *unused,
--
2.0.0-rc0
--
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] netclassid_cgroup: explicitly init the early_init field
For a cgroup subsystem who should init early, then it should carefully
take care of the implementation of css_alloc, because it will be called
before mm_init() setup the world.
Luckily we don't, and we better explicitly assign the early_init field
to 0, for document reason.
Signed-off-by: Jianyu Zhan
---
net/core/netclassid_cgroup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/netclassid_cgroup.c b/net/core/netclassid_cgroup.c
index 22931e1..1b07dca 100644
--- a/net/core/netclassid_cgroup.c
+++ b/net/core/netclassid_cgroup.c
@@ -108,4 +108,5 @@ struct cgroup_subsys net_cls_cgrp_subsys = {
.css_free = cgrp_css_free,
.attach = cgrp_attach,
.base_cftypes = ss_files,
+ .early_init = 0,
};
--
2.0.0-rc0
--
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: ftrace/kprobes: Warning when insmod two modules
(2014/04/22 12:51), Rusty Russell wrote: > Steven Rostedt writes: >> On Mon, 24 Mar 2014 20:26:05 +0900 >> Masami Hiramatsu wrote: >> >> >>> Thank you for reporting with this pretty backtrace :) >>> Steven, I think this is not the kprobe bug but ftrace (and perhaps, module). >> >> Looks to be more of a module issue than a ftrace issue. >> >>> >>> If the ftrace can set loading module text read only before the module >>> subsystem >>> expected, I think it should be protected by the module subsystem itself >>> (e.g. set_all_modules_text_ro(rw) skips the modules which is >>> MODULE_STATE_COMING) >>> >> >> Does this patch fix it? >> >> In-review-off-by: Steven Rostedt > > Sorry, was on paternity leave. > > I'm always nervous about adding more states, since every place which > examines the state has to be audited. > > We set the mod->state to MOD_STATE_COMING in complete_formation; > why don't we set NX there instead? It also makes more sense to > set NX before we hit parse_args() which can execute code in the module. > > In fact, we should probably call the notifier there too, so people > can breakpoint/tracepoint/etc parameter calls. > > Of course, this means that we set NX before the notifier; does anything > break? This does not work. ftrace_process_locs() is called from the notifier, and it tries to change its text like this. load_module blocking_notifier_call_chain ftrace_module_notify_enter ftrace_init_module ftrace_process_locs sort ftrace_swap_ips But the text is already RO, so it causes panic. We need to call notifier before setting it RO. Or should we unset RO temporarily in ftrace_process_locs()? Thanks, Takao Indoh > > Subject: module: set nx before marking module MODULE_STATE_COMING. > > This prevents a WARN_ON() where ftrace calls set_all_modules_text_ro() > which races with the module setting its own set_section_ro_nx(). > > It also means we're NX protected before we call parse_args(), which > can execute module code. > > This means that the notifiers will be called on a module which > is already NX, so that may cause problems. > > Signed-off-by: Rusty Russell > > diff --git a/kernel/module.c b/kernel/module.c > index 11869408f79b..83a437e5d429 100644 > --- a/kernel/module.c > +++ b/kernel/module.c > @@ -3023,21 +3023,6 @@ static int do_init_module(struct module *mod) >*/ > current->flags &= ~PF_USED_ASYNC; > > - blocking_notifier_call_chain(_notify_list, > - MODULE_STATE_COMING, mod); > - > - /* Set RO and NX regions for core */ > - set_section_ro_nx(mod->module_core, > - mod->core_text_size, > - mod->core_ro_size, > - mod->core_size); > - > - /* Set RO and NX regions for init */ > - set_section_ro_nx(mod->module_init, > - mod->init_text_size, > - mod->init_ro_size, > - mod->init_size); > - > do_mod_ctors(mod); > /* Start the module */ > if (mod->init != NULL) > @@ -3168,9 +3153,26 @@ static int complete_formation(struct module *mod, > struct load_info *info) > /* This relies on module_mutex for list integrity. */ > module_bug_finalize(info->hdr, info->sechdrs, mod); > > + /* Set RO and NX regions for core */ > + set_section_ro_nx(mod->module_core, > + mod->core_text_size, > + mod->core_ro_size, > + mod->core_size); > + > + /* Set RO and NX regions for init */ > + set_section_ro_nx(mod->module_init, > + mod->init_text_size, > + mod->init_ro_size, > + mod->init_size); > + > /* Mark state as coming so strong_try_module_get() ignores us, >* but kallsyms etc. can see us. */ > mod->state = MODULE_STATE_COMING; > + mutex_unlock(_mutex); > + > + blocking_notifier_call_chain(_notify_list, > + MODULE_STATE_COMING, mod); > + return 0; > > out: > mutex_unlock(_mutex); > > -- 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] hugetlb_cgroup: explicitly init the early_init field
For a cgroup subsystem who should init early, then it should carefully
take care of the implementation of css_alloc, because it will be called
before mm_init() setup the world.
Luckily we don't, and we better explicitly assign the early_init field
to 0, for document reason.
Signed-off-by: Jianyu Zhan
---
mm/hugetlb_cgroup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c
index 595d7fd..b5368f8 100644
--- a/mm/hugetlb_cgroup.c
+++ b/mm/hugetlb_cgroup.c
@@ -405,4 +405,5 @@ struct cgroup_subsys hugetlb_cgrp_subsys = {
.css_alloc = hugetlb_cgroup_css_alloc,
.css_offline= hugetlb_cgroup_css_offline,
.css_free = hugetlb_cgroup_css_free,
+ .early_init = 0,
};
--
2.0.0-rc0
--
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: kaslr relocation incompitable with kernel loaded high
On 04/21/14 at 09:58pm, Yinghai Lu wrote:
> On Mon, Apr 21, 2014 at 8:16 PM, WANG Chao wrote:
> > On 04/21/14 at 11:01am, Kees Cook wrote:
> >> On Mon, Apr 21, 2014 at 10:56 AM, Yinghai Lu wrote:
> >> > On Mon, Apr 21, 2014 at 3:52 AM, WANG Chao wrote:
> >> >> Hi, Kees
> >> >>
> >> >> When I'm testing kaslr with kdump, I find that when 2nd kernel is loaded
> >> >> high, it doesn't boot.
> >> >>
> >> >> I reserved 128M memory at high with kernel cmdline
> >> >> "crashkernel=128M,high crashkernel=0,low", and for which I got:
> >> >>
> >> >> [0.00] Reserving 128MB of memory at 6896MB for crashkernel
> >> >> (System RAM: 6013MB)
> >> >>
> >> >> Then I load kdump kernel into the reserved memory region, using a local
> >> >> modified kexec-tools which is passing e820 in boot_params.
> >> >>
> >> >> The e820 map of system RAM passed to 2nd kernel:
> >> >>
> >> >> E820 memmap (of RAM):
> >> >> 1000-0009e3ff (1)
> >> >> 0001af00-0001b6f5dfff (1)
> >> >> 0001b6fff400-0001b6ff (1)
> >> >>
> >> >> In which, 2nd kernel is loaded at 0x1b500.
> >> >>
> >> >> After triggerred a system crash, 2nd kernel doesn't boot even with
> >> >> "nokaslr" cmdline:
> >> >>
> >> >> # echo c > /proc/sysrq-trigger
> >> >> [..]
> >> >>
> >> >> I'm in purgatory
> >> >> early console in decompress_kernel
> >> >> KASLR disabled...
> >> >>
> >> >> Decompressing Linux... Parsing ELF... Performing relocations...
> >> >>
> >> >> 32-bit relocation outside of kernel!
> >> >
> >> > Interesting, when kernel get at "early console in decompress_kernel"
> >> > kernel already in 64 bit...
> >> >
> >> > what does it mean "32-bit relocation outside of kernel" ?
> >> >
> >> > why 32-bit is involved ?
> >>
> >> The 64-bit kernel has both 64 and 32 bit relocations (there are two
> >> tables at the end of the kernel image). The error means that the
> >> resulting relocation is believed to be outside the kernel image:
> >>
> >> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/x86/boot/compressed/misc.c#n283
> >>
> >> Which means there is likely something wrong with this calculation in
> >> your situation:
> >>
> >> /*
> >> * Calculate the delta between where vmlinux was linked to load
> >> * and where it was actually loaded.
> >> */
> >> delta = min_addr - LOAD_PHYSICAL_ADDR;
> >>
> >
> > Probably.
>
> Please check attached that patch that will solve nokaslr.
>
> Somehow I got "KASLR could not find suitable E820 region..."
> so i only have "No relocation needed"
I think it makes sense. If output from choose_kernel_location() doesn't
change (output == output_orig), we shouldn't call relocation code.
There are two situations that makes output == output_orig:
- "nokaslr" case
- "KASLR could not find suitable E820 region" case.
>
> will check that later.
> ---
> arch/x86/boot/compressed/misc.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> Index: linux-2.6/arch/x86/boot/compressed/misc.c
> ===
> --- linux-2.6.orig/arch/x86/boot/compressed/misc.c
> +++ linux-2.6/arch/x86/boot/compressed/misc.c
> @@ -235,8 +235,9 @@ static void error(char *x)
> asm("hlt");
> }
>
> -#if CONFIG_X86_NEED_RELOCS
> -static void handle_relocations(void *output, unsigned long output_len)
> +#ifdef CONFIG_X86_NEED_RELOCS
> +static void handle_relocations(void *output_orig, void *output,
> +unsigned long output_len)
> {
> int *reloc;
> unsigned long delta, map, ptr;
> @@ -247,7 +248,7 @@ static void handle_relocations(void *out
>* Calculate the delta between where vmlinux was linked to load
>* and where it was actually loaded.
>*/
> - delta = min_addr - LOAD_PHYSICAL_ADDR;
> + delta = min_addr - (unsigned long)output_orig;
> if (!delta) {
> debug_putstr("No relocation needed... ");
> return;
> @@ -304,7 +305,8 @@ static void handle_relocations(void *out
> #endif
> }
> #else
> -static inline void handle_relocations(void *output, unsigned long output_len)
> +static inline void handle_relocations(void *output_orig, void *output,
> + unsigned long output_len)
> { }
> #endif
>
> @@ -365,6 +367,8 @@ asmlinkage void *decompress_kernel(void
> unsigned char *output,
> unsigned long output_len)
> {
> + unsigned char *output_orig = output;
> +
> real_mode = rmode;
>
> sanitize_boot_params(real_mode);
> @@ -417,7 +421,7 @@ asmlinkage void *decompress_kernel(void
> debug_putstr("... ");
> decompress(input_data, input_len, NULL, NULL, output, NULL, error);
> parse_elf(output);
> - handle_relocations(output, output_len);
> + handle_relocations(output_orig, output, output_len);
> debug_putstr("done.\nBooting the kernel.\n");
> return
[PATCH] perf-event/cgroup: explicitly init the early_init field
For a cgroup subsystem who should init early, then it should carefully
take care of the implementation of css_alloc, because it will be called
before mm_init() setup the world.
Luckily we don't, and we better explicitly assign the early_init field
to 0, for document reason.
Signed-off-by: Jianyu Zhan
---
kernel/events/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index f83a71a..b3a8916 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -8062,5 +8062,6 @@ struct cgroup_subsys perf_event_cgrp_subsys = {
.css_free = perf_cgroup_css_free,
.exit = perf_cgroup_exit,
.attach = perf_cgroup_attach,
+ .early_init = 0,
};
#endif /* CONFIG_CGROUP_PERF */
--
2.0.0-rc0
--
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] cgroup_freezer: explicitly init the early_init field
For a cgroup subsystem who should init early, then it should carefully
take care of the implementation of css_alloc, because it will be called
before mm_init() setup the world.
Luckily we don't, and we better explicitly assign the early_init field
to 0, for document reason.
Signed-off-by: Jianyu Zhan
---
kernel/cgroup_freezer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/cgroup_freezer.c b/kernel/cgroup_freezer.c
index 2bc4a22..74fe7f7 100644
--- a/kernel/cgroup_freezer.c
+++ b/kernel/cgroup_freezer.c
@@ -501,4 +501,5 @@ struct cgroup_subsys freezer_cgrp_subsys = {
.attach = freezer_attach,
.fork = freezer_fork,
.base_cftypes = files,
+ .early_init = 0,
};
--
2.0.0-rc0
--
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] cgroup: explicitly init the early_init field
For a cgroup subsystem who should init early, then it should carefully
take care of the implementation of css_alloc, because it will be called
before mm_init() setup the world.
Luckily we don't, and we better explicitly assign the early_init field
to 0, for document reason.
Signed-off-by: Jianyu Zhan
---
kernel/cgroup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 559f822..f23cb67 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -5325,5 +5325,6 @@ struct cgroup_subsys debug_cgrp_subsys = {
.css_alloc = debug_css_alloc,
.css_free = debug_css_free,
.base_cftypes = debug_files,
+ .early_init = 0,
};
#endif /* CONFIG_CGROUP_DEBUG */
--
2.0.0-rc0
--
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] blk-cgroup: explicitly init the early_init field
For a cgroup subsystem who should init early, then it should carefully
take care of the implementation of css_alloc, because it will be called
before mm_init() setup the world.
Luckily we don't, and we better explicitly assign the early_init field
to 0, for document reason.
Signed-off-by: Jianyu Zhan
---
block/blk-cgroup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
index e4a4145..941bbc8 100644
--- a/block/blk-cgroup.c
+++ b/block/blk-cgroup.c
@@ -912,6 +912,7 @@ struct cgroup_subsys blkio_cgrp_subsys = {
.css_free = blkcg_css_free,
.can_attach = blkcg_can_attach,
.base_cftypes = blkcg_files,
+ .early_init = 0,
};
EXPORT_SYMBOL_GPL(blkio_cgrp_subsys);
--
2.0.0-rc0
--
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 RESEND] fs/aio.c: Remove ctx parameter in kiocb_cancel
ctx is no longer used in kiocb_cancel since
57282d8fd74407 ("aio: Kill ki_users")
Cc: Alexander Viro
Cc: Andrew Morton
Signed-off-by: Fabian Frederick
---
fs/aio.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index 12a3de0e..b92fdee 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -472,7 +472,7 @@ void kiocb_set_cancel_fn(struct kiocb *req, kiocb_cancel_fn
*cancel)
}
EXPORT_SYMBOL(kiocb_set_cancel_fn);
-static int kiocb_cancel(struct kioctx *ctx, struct kiocb *kiocb)
+static int kiocb_cancel(struct kiocb *kiocb)
{
kiocb_cancel_fn *old, *cancel;
@@ -529,7 +529,7 @@ static void free_ioctx_users(struct percpu_ref *ref)
struct kiocb, ki_list);
list_del_init(>ki_list);
- kiocb_cancel(ctx, req);
+ kiocb_cancel(req);
}
spin_unlock_irq(>ctx_lock);
@@ -1559,7 +1559,7 @@ SYSCALL_DEFINE3(io_cancel, aio_context_t, ctx_id, struct
iocb __user *, iocb,
kiocb = lookup_kiocb(ctx, iocb, key);
if (kiocb)
- ret = kiocb_cancel(ctx, kiocb);
+ ret = kiocb_cancel(kiocb);
else
ret = -EINVAL;
--
--
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/
[Bugfix] sched: fix possible invalid memory access caused by CPU hot-addition
When calling kzalloc_node(size, flags, node), we should first check
whether node is onlined, otherwise it may cause invalid memory access
as below.
[ 3663.324476] BUG: unable to handle kernel paging request at 1f08
[ 3663.332348] IP: [] __alloc_pages_nodemask+0xb9/0x2d0
[ 3663.339719] PGD 82fe10067 PUD 82ebef067 PMD 0
[ 3663.344773] Oops: [#1] SMP
[ 3663.348455] Modules linked in: shpchp gpio_ich x86_pkg_temp_thermal
intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper
cryptd microcode joydev sb_edac edac_core lpc_ich ipmi_si tpm_tis
ipmi_msghandler ioatdma wmi acpi_pad mac_hid lp parport ixgbe isci mpt2sas dca
ahci ptp libsas libahci raid_class pps_core scsi_transport_sas mdio hid_generic
usbhid hid
[ 3663.394393] CPU: 61 PID: 2416 Comm: cron Tainted: GW3.14.0-rc5+
#21
[ 3663.402643] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS
BRIVTIN1.86B.0047.F03.1403031049 03/03/2014
[ 3663.414299] task: 88082fe54b00 ti: 880845fba000 task.ti:
880845fba000
[ 3663.422741] RIP: 0010:[] []
__alloc_pages_nodemask+0xb9/0x2d0
[ 3663.432857] RSP: 0018:880845fbbcd0 EFLAGS: 00010246
[ 3663.439265] RAX: 1f00 RBX: RCX:
[ 3663.447291] RDX: RSI: 0a8d RDI: 81a8d950
[ 3663.455318] RBP: 880845fbbd58 R08: 880823293400 R09: 0001
[ 3663.463345] R10: 0001 R11: R12: 002052d0
[ 3663.471363] R13: 880854c07600 R14: 0002 R15:
[ 3663.479389] FS: 7f2e8b99e800() GS:88105a40()
knlGS:
[ 3663.488514] CS: 0010 DS: ES: CR0: 80050033
[ 3663.495018] CR2: 1f08 CR3: 0008237b1000 CR4: 001407e0
[ 3663.503476] Stack:
[ 3663.505757] 811bd74d 880854c01d98 880854c01df0
880854c01dd0
[ 3663.514167] 0003208ca420 00075a5d84d0 88082fe54b00
811bb35f
[ 3663.522567] 880854c07600 0003 1f00
880845fbbd48
[ 3663.530976] Call Trace:
[ 3663.533753] [] ? deactivate_slab+0x41d/0x4f0
[ 3663.540421] [] ? new_slab+0x3f/0x2d0
[ 3663.546307] [] new_slab+0xa5/0x2d0
[ 3663.552001] [] __slab_alloc+0x35d/0x54a
[ 3663.558185] [] ? local_clock+0x25/0x30
[ 3663.564686] [] ? __do_page_fault+0x4ec/0x5e0
[ 3663.571356] [] ? alloc_fair_sched_group+0xc4/0x190
[ 3663.578609] [] ? __raw_spin_lock_init+0x21/0x60
[ 3663.585570] [] kmem_cache_alloc_node_trace+0xa6/0x1d0
[ 3663.593112] [] ? alloc_fair_sched_group+0xc4/0x190
[ 3663.600363] [] alloc_fair_sched_group+0xc4/0x190
[ 3663.607423] [] sched_create_group+0x3f/0x80
[ 3663.613994] [] sched_autogroup_create_attach+0x3f/0x1b0
[ 3663.621732] [] sys_setsid+0xea/0x110
[ 3663.628020] [] system_call_fastpath+0x1a/0x1f
[ 3663.634780] Code: 00 44 89 e7 e8 b9 f8 f4 ff 41 f6 c4 10 74 18 31 d2 be 8d
0a 00 00 48 c7 c7 50 d9 a8 81 e8 70 6a f2 ff e8 db dd 5f 00 48 8b 45 c8 <48> 83
78 08 00 0f 84 b5 01 00 00 48 83 c0 08 44 89 75 c0 4d 89
[ 3663.657032] RIP [] __alloc_pages_nodemask+0xb9/0x2d0
[ 3663.664491] RSP
[ 3663.668429] CR2: 1f08
[ 3663.672659] ---[ end trace df13f08ed9de18ad ]---
Signed-off-by: Jiang Liu
---
kernel/sched/fair.c | 12 +++-
kernel/sched/rt.c | 11 +++
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7e9bd0b1fa9e..1c093d213b0f 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -7485,7 +7485,7 @@ int alloc_fair_sched_group(struct task_group *tg, struct
task_group *parent)
{
struct cfs_rq *cfs_rq;
struct sched_entity *se;
- int i;
+ int i, nid;
tg->cfs_rq = kzalloc(sizeof(cfs_rq) * nr_cpu_ids, GFP_KERNEL);
if (!tg->cfs_rq)
@@ -7499,13 +7499,15 @@ int alloc_fair_sched_group(struct task_group *tg,
struct task_group *parent)
init_cfs_bandwidth(tg_cfs_bandwidth(tg));
for_each_possible_cpu(i) {
- cfs_rq = kzalloc_node(sizeof(struct cfs_rq),
- GFP_KERNEL, cpu_to_node(i));
+ nid = cpu_to_node(i);
+ if (nid != NUMA_NO_NODE && !node_online(nid))
+ nid = NUMA_NO_NODE;
+
+ cfs_rq = kzalloc_node(sizeof(struct cfs_rq), GFP_KERNEL, nid);
if (!cfs_rq)
goto err;
- se = kzalloc_node(sizeof(struct sched_entity),
- GFP_KERNEL, cpu_to_node(i));
+ se = kzalloc_node(sizeof(struct sched_entity), GFP_KERNEL, nid);
if (!se)
goto err_free_rq;
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index d8cdf1618551..5a5a32e1115c 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -161,7 +161,7 @@ int
[PATCH RESEND] FS: Remove bs paramater in biovec_create_pool
bs is no longer used in biovec_create_pool
since 9f060e2231ca96
("block: Convert integrity to bvec_alloc_bs()")
Cc: Alexander Viro
Cc: Andrew Morton
Signed-off-by: Fabian Frederick
---
fs/bio-integrity.c | 2 +-
fs/bio.c| 4 ++--
include/linux/bio.h | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/bio-integrity.c b/fs/bio-integrity.c
index 1c2ce0c..9e24106 100644
--- a/fs/bio-integrity.c
+++ b/fs/bio-integrity.c
@@ -617,7 +617,7 @@ int bioset_integrity_create(struct bio_set *bs, int
pool_size)
if (!bs->bio_integrity_pool)
return -1;
- bs->bvec_integrity_pool = biovec_create_pool(bs, pool_size);
+ bs->bvec_integrity_pool = biovec_create_pool(pool_size);
if (!bs->bvec_integrity_pool) {
mempool_destroy(bs->bio_integrity_pool);
return -1;
diff --git a/fs/bio.c b/fs/bio.c
index 6f0362b..13a4fab 100644
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -1859,7 +1859,7 @@ EXPORT_SYMBOL_GPL(bio_trim);
* create memory pools for biovec's in a bio_set.
* use the global biovec slabs created for general use.
*/
-mempool_t *biovec_create_pool(struct bio_set *bs, int pool_entries)
+mempool_t *biovec_create_pool(int pool_entries)
{
struct biovec_slab *bp = bvec_slabs + BIOVEC_MAX_IDX;
@@ -1922,7 +1922,7 @@ struct bio_set *bioset_create(unsigned int pool_size,
unsigned int front_pad)
if (!bs->bio_pool)
goto bad;
- bs->bvec_pool = biovec_create_pool(bs, pool_size);
+ bs->bvec_pool = biovec_create_pool(pool_size);
if (!bs->bvec_pool)
goto bad;
diff --git a/include/linux/bio.h b/include/linux/bio.h
index bba5508..5a64576 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -333,7 +333,7 @@ static inline struct bio *bio_next_split(struct bio *bio,
int sectors,
extern struct bio_set *bioset_create(unsigned int, unsigned int);
extern void bioset_free(struct bio_set *);
-extern mempool_t *biovec_create_pool(struct bio_set *bs, int pool_entries);
+extern mempool_t *biovec_create_pool(int pool_entries);
extern struct bio *bio_alloc_bioset(gfp_t, int, struct bio_set *);
extern void bio_put(struct bio *);
--
1.8.4.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/
[PATCH] mbcache: LLVMLinux: Remove double calculation from mbcache
From: Mark Charlebois The call to __builtin_log2 presumes there is a double log2(double x) function defined in the kernel. The call to hash_log is a call to hash_64 which is defined in include/linux/hash.h static __always_inline u64 hash_64(u64 val, unsigned int bits) That means that __builtin_log2(NR_BG_LOCKS) is converting NR_BG_LOCKS to a double and returning a double and then that is converted to an unsigned int. Using ilog2 is much more appropriate and efficient. Another side effect of using __builtin_log2 is that is uses __aeabi_* functions for ARM that require linking with libgcc.a. Author: Mark Charlebois Signed-off-by: Mark Charlebois Signed-off-by: Behan Webster --- fs/mbcache.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/mbcache.c b/fs/mbcache.c index bf166e3..2c0752b 100644 --- a/fs/mbcache.c +++ b/fs/mbcache.c @@ -93,7 +93,7 @@ #define MB_CACHE_WRITER ((unsigned short)~0U >> 1) -#define MB_CACHE_ENTRY_LOCK_BITS __builtin_log2(NR_BG_LOCKS) +#define MB_CACHE_ENTRY_LOCK_BITS ilog2(NR_BG_LOCKS) #defineMB_CACHE_ENTRY_LOCK_INDEX(ce) \ (hash_long((unsigned long)ce, MB_CACHE_ENTRY_LOCK_BITS)) -- 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/
[PATCH RESEND] fs/bio.c: remove nr_segs (unused function parameter)
nr_segs is no longer used in bio_alloc_map_data since
c8db444820a1e3 ("block: Don't save/copy bvec array anymore")
Cc: Alexander Viro
Cc: Andrew Morton
Signed-off-by: Fabian Frederick
---
fs/bio.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/bio.c b/fs/bio.c
index 6f0362b..bd39c5b 100644
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -1011,8 +1011,7 @@ static void bio_set_map_data(struct bio_map_data *bmd,
struct bio *bio,
bio->bi_private = bmd;
}
-static struct bio_map_data *bio_alloc_map_data(int nr_segs,
- unsigned int iov_count,
+static struct bio_map_data *bio_alloc_map_data(unsigned int iov_count,
gfp_t gfp_mask)
{
if (iov_count > UIO_MAXIOV)
@@ -1154,7 +1153,7 @@ struct bio *bio_copy_user_iov(struct request_queue *q,
if (offset)
nr_pages++;
- bmd = bio_alloc_map_data(nr_pages, iov_count, gfp_mask);
+ bmd = bio_alloc_map_data(iov_count, gfp_mask);
if (!bmd)
return ERR_PTR(-ENOMEM);
--
1.8.4.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/
[PATCH] cpufreq: Make linux...@vger.kernel.org official mailing list
There have been confusion all the time about which mailing list to follow for cpufreq activities, linux...@vger.kernel.org or cpuf...@vger.kernel.org. As Maintainers always wanted people to send patches to linux...@vger.kernel.org and kernel source asked them to use cpuf...@vger.kernel.org. Lets make linux...@vger.kernel.org the official mailing list for cpufreq stuff and remove all references of cpuf...@vger.kernel.org from kernel source. Later, we can remove the list as well from vger.kernel.org. Signed-off-by: Viresh Kumar --- Documentation/ABI/testing/sysfs-devices-system-cpu | 4 ++-- Documentation/cpu-freq/index.txt | 4 ++-- MAINTAINERS | 2 -- drivers/cpufreq/speedstep-centrino.c | 2 +- tools/power/cpupower/Makefile| 2 +- tools/power/cpupower/debug/kernel/cpufreq-test_tsc.c | 2 +- 6 files changed, 7 insertions(+), 9 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index d5a0d33..acb9bfc 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -128,7 +128,7 @@ Description:Discover cpuidle policy and mechanism What: /sys/devices/system/cpu/cpu#/cpufreq/* Date: pre-git history -Contact: cpuf...@vger.kernel.org +Contact: linux...@vger.kernel.org Description: Discover and change clock speed of CPUs Clock scaling allows you to change the clock speed of the @@ -146,7 +146,7 @@ Description:Discover and change clock speed of CPUs What: /sys/devices/system/cpu/cpu#/cpufreq/freqdomain_cpus Date: June 2013 -Contact: cpuf...@vger.kernel.org +Contact: linux...@vger.kernel.org Description: Discover CPUs in the same CPU frequency coordination domain freqdomain_cpus is the list of CPUs (online+offline) that share diff --git a/Documentation/cpu-freq/index.txt b/Documentation/cpu-freq/index.txt index 3d0b915..dc024ab 100644 --- a/Documentation/cpu-freq/index.txt +++ b/Documentation/cpu-freq/index.txt @@ -35,8 +35,8 @@ Mailing List There is a CPU frequency changing CVS commit and general list where you can report bugs, problems or submit patches. To post a message, -send an email to cpuf...@vger.kernel.org, to subscribe go to -http://vger.kernel.org/vger-lists.html#cpufreq and follow the +send an email to linux...@vger.kernel.org, to subscribe go to +http://vger.kernel.org/vger-lists.html#linux-pm and follow the instructions there. Links diff --git a/MAINTAINERS b/MAINTAINERS index 6dc67b1..88b60d9 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2415,7 +2415,6 @@ F:drivers/net/ethernet/ti/cpmac.c CPU FREQUENCY DRIVERS M: Rafael J. Wysocki M: Viresh Kumar -L: cpuf...@vger.kernel.org L: linux...@vger.kernel.org S: Maintained T: git git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git @@ -2426,7 +2425,6 @@ F:include/linux/cpufreq.h CPU FREQUENCY DRIVERS - ARM BIG LITTLE M: Viresh Kumar M: Sudeep Holla -L: cpuf...@vger.kernel.org L: linux...@vger.kernel.org W: http://www.arm.com/products/processors/technologies/biglittleprocessing.php S: Maintained diff --git a/drivers/cpufreq/speedstep-centrino.c b/drivers/cpufreq/speedstep-centrino.c index 6723f03..7d4a315 100644 --- a/drivers/cpufreq/speedstep-centrino.c +++ b/drivers/cpufreq/speedstep-centrino.c @@ -28,7 +28,7 @@ #include #define PFX"speedstep-centrino: " -#define MAINTAINER "cpuf...@vger.kernel.org" +#define MAINTAINER "linux...@vger.kernel.org" #define INTEL_MSR_RANGE(0x) diff --git a/tools/power/cpupower/Makefile b/tools/power/cpupower/Makefile index cbfec92..3651db7 100644 --- a/tools/power/cpupower/Makefile +++ b/tools/power/cpupower/Makefile @@ -62,7 +62,7 @@ LIB_MAJ= 0.0.0 LIB_MIN= 0 PACKAGE = cpupower -PACKAGE_BUGREPORT =cpuf...@vger.kernel.org +PACKAGE_BUGREPORT =linux...@vger.kernel.org LANGUAGES =de fr it cs pt diff --git a/tools/power/cpupower/debug/kernel/cpufreq-test_tsc.c b/tools/power/cpupower/debug/kernel/cpufreq-test_tsc.c index 0f10b81..5224ee5 100644 --- a/tools/power/cpupower/debug/kernel/cpufreq-test_tsc.c +++ b/tools/power/cpupower/debug/kernel/cpufreq-test_tsc.c @@ -18,7 +18,7 @@ * 5.) if the third value, "diff_pmtmr", changes between 2. and 4., the * TSC-based delay routine on the Linux kernel does not correctly * handle the cpufreq transition. Please report this to - * cpuf...@vger.kernel.org + * linux...@vger.kernel.org */ #include -- 1.7.12.rc2.18.g61b472e -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
Re: [tip:locking/core] arch,avr32: Convert smp_mb__*()
* Hans-Christian Egtvedt wrote: > Around Fri 18 Apr 2014 06:05:23 -0700 or thereabout, tip-bot for Peter > Zijlstra wrote: > > Commit-ID: 710adaa913169d7183cdf0de41c2a349101ff615 > > Gitweb: > > http://git.kernel.org/tip/710adaa913169d7183cdf0de41c2a349101ff615 > > Author: Peter Zijlstra > > AuthorDate: Thu, 13 Mar 2014 19:00:37 +0100 > > Committer: Ingo Molnar > > CommitDate: Fri, 18 Apr 2014 11:40:33 +0200 > > > > arch,avr32: Convert smp_mb__*() > > > > AVR32's mb() implementation is a compiler barrier(), therefore it all > > doesn't matter, fully rely on whatever asm-generic/barrier.h > > generates. > > Thanks for cleaning, would this go in through some tip-tree? Or would you > prefer if I added it to my for-linus branch? Yeah, the plan would be for this to go via the locking tree (tip:locking/core), for v3.16 - together with similar patches for other architectures. Thanks, Ingo -- 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: kaslr relocation incompitable with kernel loaded high
On Mon, Apr 21, 2014 at 8:16 PM, WANG Chao wrote:
> On 04/21/14 at 11:01am, Kees Cook wrote:
>> On Mon, Apr 21, 2014 at 10:56 AM, Yinghai Lu wrote:
>> > On Mon, Apr 21, 2014 at 3:52 AM, WANG Chao wrote:
>> >> Hi, Kees
>> >>
>> >> When I'm testing kaslr with kdump, I find that when 2nd kernel is loaded
>> >> high, it doesn't boot.
>> >>
>> >> I reserved 128M memory at high with kernel cmdline
>> >> "crashkernel=128M,high crashkernel=0,low", and for which I got:
>> >>
>> >> [0.00] Reserving 128MB of memory at 6896MB for crashkernel
>> >> (System RAM: 6013MB)
>> >>
>> >> Then I load kdump kernel into the reserved memory region, using a local
>> >> modified kexec-tools which is passing e820 in boot_params.
>> >>
>> >> The e820 map of system RAM passed to 2nd kernel:
>> >>
>> >> E820 memmap (of RAM):
>> >> 1000-0009e3ff (1)
>> >> 0001af00-0001b6f5dfff (1)
>> >> 0001b6fff400-0001b6ff (1)
>> >>
>> >> In which, 2nd kernel is loaded at 0x1b500.
>> >>
>> >> After triggerred a system crash, 2nd kernel doesn't boot even with
>> >> "nokaslr" cmdline:
>> >>
>> >> # echo c > /proc/sysrq-trigger
>> >> [..]
>> >>
>> >> I'm in purgatory
>> >> early console in decompress_kernel
>> >> KASLR disabled...
>> >>
>> >> Decompressing Linux... Parsing ELF... Performing relocations...
>> >>
>> >> 32-bit relocation outside of kernel!
>> >
>> > Interesting, when kernel get at "early console in decompress_kernel"
>> > kernel already in 64 bit...
>> >
>> > what does it mean "32-bit relocation outside of kernel" ?
>> >
>> > why 32-bit is involved ?
>>
>> The 64-bit kernel has both 64 and 32 bit relocations (there are two
>> tables at the end of the kernel image). The error means that the
>> resulting relocation is believed to be outside the kernel image:
>>
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/x86/boot/compressed/misc.c#n283
>>
>> Which means there is likely something wrong with this calculation in
>> your situation:
>>
>> /*
>> * Calculate the delta between where vmlinux was linked to load
>> * and where it was actually loaded.
>> */
>> delta = min_addr - LOAD_PHYSICAL_ADDR;
>>
>
> Probably.
Please check attached that patch that will solve nokaslr.
Somehow I got "KASLR could not find suitable E820 region..."
so i only have "No relocation needed"
will check that later.
---
arch/x86/boot/compressed/misc.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
Index: linux-2.6/arch/x86/boot/compressed/misc.c
===
--- linux-2.6.orig/arch/x86/boot/compressed/misc.c
+++ linux-2.6/arch/x86/boot/compressed/misc.c
@@ -235,8 +235,9 @@ static void error(char *x)
asm("hlt");
}
-#if CONFIG_X86_NEED_RELOCS
-static void handle_relocations(void *output, unsigned long output_len)
+#ifdef CONFIG_X86_NEED_RELOCS
+static void handle_relocations(void *output_orig, void *output,
+ unsigned long output_len)
{
int *reloc;
unsigned long delta, map, ptr;
@@ -247,7 +248,7 @@ static void handle_relocations(void *out
* Calculate the delta between where vmlinux was linked to load
* and where it was actually loaded.
*/
- delta = min_addr - LOAD_PHYSICAL_ADDR;
+ delta = min_addr - (unsigned long)output_orig;
if (!delta) {
debug_putstr("No relocation needed... ");
return;
@@ -304,7 +305,8 @@ static void handle_relocations(void *out
#endif
}
#else
-static inline void handle_relocations(void *output, unsigned long output_len)
+static inline void handle_relocations(void *output_orig, void *output,
+ unsigned long output_len)
{ }
#endif
@@ -365,6 +367,8 @@ asmlinkage void *decompress_kernel(void
unsigned char *output,
unsigned long output_len)
{
+ unsigned char *output_orig = output;
+
real_mode = rmode;
sanitize_boot_params(real_mode);
@@ -417,7 +421,7 @@ asmlinkage void *decompress_kernel(void
debug_putstr("... ");
decompress(input_data, input_len, NULL, NULL, output, NULL, error);
parse_elf(output);
- handle_relocations(output, output_len);
+ handle_relocations(output_orig, output, output_len);
debug_putstr("done.\nBooting the kernel.\n");
return output;
}
Re: [PATCH v3 2/2] dt: platform driver: Fill the resources before probe and defer if needed
* Tony Lindgren [140421 20:06]:
> * Tony Lindgren [140421 13:26]:
> > * Rob Herring [140421 12:01]:
> > > Something like this is what you had in mind?
...
> > > --- a/drivers/of/irq.c
> > > +++ b/drivers/of/irq.c
> > > @@ -400,6 +400,26 @@ int of_irq_to_resource(struct device_node *dev, int
> > > index, struct resource *r)
> > > EXPORT_SYMBOL_GPL(of_irq_to_resource);
> > >
> > > /**
> > > + * of_irq_get - Decode a node's IRQ and return it as a Linux irq number
> > > + * @dev: pointer to device tree node
> > > + * @index: zero-based index of the irq
> > > + *
> > > + * Returns Linux irq number on success, or -EPROBE_DEFER if the irq
> > > domain
> > > + * is not yet created.
> > > + *
> > > + */
> > > +int of_irq_get(struct device_node *dev, int index)
> > > +{
> > > + int irq = irq_of_parse_and_map(dev, index);
> > > +
> > > + if (!irq && of_find_irq_domain(dev, index) == NULL)
> > > + return -EPROBE_DEFER;
> > > +
> > > + return irq;
> > > +}
> >
> > Yeah something like that. That might also work as a pretty
> > minimal fix as long as we fix the known broken drivers to use
> > platform_get_irq().
>
> Actually, the above code for of_irq_get() won't help as we're still
> calling irq_of_parse_and_map() before we should. So the nasty warnings
> are still there if the irqdomain is not yet found.
OK so to fix the warning part of the problem we first need to not
try to map uninitialized irqdomains and then downgrade the current
warning to a dev_dbg.
So looks like the current minimal fix to my original problem the
first patch from Jean-Jacques in this series, and the following patch.
This works for drivers that currently do of_irq_parse_and_map(),
then your patch is also needed to make things work properly with
platform_get_irq().
8< --
From: Tony Lindgren
Date: Mon, 21 Apr 2014 19:33:43 -0700
Subject: [PATCH] of/platform: Fix no irq domain found errors when populating
interrupts
Currently we get the following kind of errors if we try to use interrupt
phandles to irqchips that have not yet initialized:
irq: no irq domain found for /ocp/pinmux@48002030 !
[ cut here ]
WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171
of_device_alloc+0x144/0x184()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
(show_stack+0x14/0x1c)
(dump_stack+0x6c/0xa0)
(warn_slowpath_common+0x64/0x84)
(warn_slowpath_null+0x1c/0x24)
(of_device_alloc+0x144/0x184)
(of_platform_device_create_pdata+0x44/0x9c)
(of_platform_bus_create+0xd0/0x170)
(of_platform_bus_create+0x12c/0x170)
(of_platform_populate+0x60/0x98)
This is because we're wrongly trying to populate resources that are not
yet available. It's perfectly valid to create irqchips dynamically, so
let's fix up the issue by populating the interrupt resources at the
driver probe time instead.
Let's fix the problem by using of_find_irq_domain() recently introduced
by Jean-Jacques Hiblot . This way we can
avoid calling irq_of_parse_and_map() unnecesssarily with incomplete
data.
And then we also need to accept the fact that some irqdomains do not
exist that early on, and only get initialized later on. So we can
make the current WARN_ON into just into a pr_debug().
Note that this patch only solves the problem for drivers that are
currently doing of_irq_parse_and_map(). A follow-up patch is needed
to make platform_get_irq() to work without relying on the populated
resources.
Signed-off-by: Tony Lindgren
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -425,13 +425,17 @@ int of_irq_count(struct device_node *dev)
int of_irq_to_resource_table(struct device_node *dev, struct resource *res,
int nr_irqs)
{
- int i;
+ int i, found = 0;
- for (i = 0; i < nr_irqs; i++, res++)
+ for (i = 0; i < nr_irqs; i++, res++) {
+ if (!of_find_irq_domain(dev, i))
+ continue;
if (!of_irq_to_resource(dev, i, res))
break;
+ found++;
+ }
- return i;
+ return found;
}
EXPORT_SYMBOL_GPL(of_irq_to_resource_table);
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -168,7 +168,9 @@ struct platform_device *of_device_alloc(struct device_node
*np,
rc = of_address_to_resource(np, i, res);
WARN_ON(rc);
}
- WARN_ON(of_irq_to_resource_table(np, res, num_irq) != num_irq);
+ if (of_irq_to_resource_table(np, res, num_irq) != num_irq)
+ pr_debug("not all legacy IRQ resources mapped for %s\n",
+np->name);
}
dev->dev.of_node = of_node_get(np);
--
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: linux-next: build failure after merge of the mmc tree
On Tue, April 22, 2014, Stephen Rothwell wrote:
> Hi Chris,
>
> After merging the mmc tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/net/wireless/rsi/rsi_91x_sdio.c: In function 'rsi_reset_card':
> drivers/net/wireless/rsi/rsi_91x_sdio.c:288:20: error: 'MMC_STATE_HIGHSPEED'
> undeclared (first use in
> this function)
> card->state &= ~MMC_STATE_HIGHSPEED;
> ^
> drivers/net/wireless/rsi/rsi_91x_sdio.c:288:20: note: each undeclared
> identifier is reported only once
> for each function it appears in
> drivers/net/wireless/rsi/rsi_91x_sdio.c:299:4: error: implicit declaration of
> function
> 'mmc_card_set_highspeed' [-Werror=implicit-function-declaration]
> mmc_card_set_highspeed(card);
> ^
> drivers/net/wireless/rsi/rsi_91x_sdio.c:306:2: error: implicit declaration of
> function
> 'mmc_card_highspeed' [-Werror=implicit-function-declaration]
> if (mmc_card_highspeed(card))
> ^
>
> Caused by commit 395784826a81 ("mmc: drop the speed mode of card's state").
>
> I have used the version of the mmc tree from next-20140417 for today.
I didn't detect usage out of mmc-sub for that.
Let me fix and send a patch.
Thanks,
Seungwon Jeon
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
--
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] locks: rename file-private locks to file-description locks
On 04/21/2014 11:15 PM, Stefan (metze) Metzmacher wrote: > Am 21.04.2014 21:55, schrieb Jeff Layton: >> On Mon, 21 Apr 2014 21:39:12 +0200 >> "Michael Kerrisk (man-pages)" wrote: >> >>> On 04/21/2014 08:46 PM, Rich Felker wrote: On Mon, Apr 21, 2014 at 08:32:44PM +0200, Michael Kerrisk (man-pages) wrote: > On 04/21/2014 06:10 PM, Rich Felker wrote: >> I'm well aware of that. The problem is that the proposed API is using >> the two-letter abbreviation FD, which ALWAYS means file descriptor and >> NEVER means file description (in existing usage) to mean file >> description. That's what's wrong. > > So, can you *please* answer this question: what do you call (i.e., > what everyday technical language term do use for) the thing > that sits between a file descriptor and an i-node? > > (Please don't say 'struct file' -- that is not is an implementation > detail, and does not qualify as the kind of term that I could use > when documenting this feature in man pages.) "Open file description". >>> >>> Oh! I didn't realize we agreed :-). >>> > POSIX uses (or invented, I am not sure which) the term file description > for a good reason: it is unambiguous, and therefore precise. I do agree > that there's a risk of confusion between 'open file descriptor" and > 'and file description'--it's the same kind of risk as between English > terms such as 'arbitrator' and 'arbitration' (and any number of other > examples), and as language speakers we deal with this every day. There's not a problem when the full word is used. On the other hand, if you use "arb" as an abbreviation for "arbitration" in a context where it was already universally understood as meaning "arbitrator", that would be a big problem. Likewise the problem here isn't that "open file description" is a bad term. It's that using "FD" to mean "[open] file description" is utterly confusing, even moreso than just making up a new completely random word. >>> >>> Ohh -- I had thought you a problem not just with "FD" but also >>> "(open) file description". >>> >>> 2) The new API constants (F_SETLKP, F_SETLKPW, F_GETLKP) have names >>>that are visually very close to the traditional POSIX lock names >>>(F_SETLK, F_SETLKW, F_GETLK). That's an accident waiting to happen >>>when someone mistypes in code and/or misses such a misttyping >>>when reading code. That really must be fixed. >> >> I agree, but I don't think making it worse is a solution. > > I don't agree that it's making it worse. The real problem here is > that people use no good unambiguous term for the thing between a file > descriptor and an inode. POSIX provides us with a solution that may > not seem perfect, but it is unambiguous, and I think it might feel > more comfortable if we used it often enough. I would like to see it used more too, and in particular, I think it belongs in the documentation for these new locking interfaces. But that still doesn't answer the question of what to call them (the macros) unless you want: F_OPEN_FILE_DESCRIPTION_GETLK F_OPEN_FILE_DESCRIPTION_SETLK F_OPEN_FILE_DESCRIPTION_SETLKW >>> >>> Or just 'F_OFD_*'? >>> Perhaps "OP" (for open-private, i.e. private to the particular open) would be a sensible choice; OTOH people are likely to misread it as OPeration. The general principle I have in mind though is that it might be nice to highlight the word "open" in "open file description" >>> >>> (Fair enough.) >>> since it (1) contrasts with file descriptor, despite file descriptors also dealing with open files, and (2) contrasts well with legacy fcntl locks, which are (this is the whole bug) associated with the underlying file and not the open file description. >>> >>> Makes sense to me. (We are in more agreement that I realized.) >>> >>> Cheers, >>> >>> Michael >>> >>> >>> >> >> So the motion is to call them "open file description locks" and change >> the macros to read *_OFD_*. Does anyone object? > > Works fine for me... And works for me. -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- 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 3/4] sysctl: allow for strict write position handling
On Mon, Apr 21, 2014 at 3:45 PM, Andrew Morton
wrote:
> On Thu, 17 Apr 2014 17:16:22 -0700 Kees Cook wrote:
>
>> When writing to a sysctl string, each write, regardless of VFS position,
>> begins writing the string from the start. This means the contents of
>> the last write to the sysctl controls the string contents instead of
>> the first:
>>
>> open("/proc/sys/kernel/modprobe", O_WRONLY) = 1
>> write(1, ""..., 4096) = 4096
>> write(1, "/bin/true", 9)= 9
>> close(1)= 0
>>
>> $ cat /proc/sys/kernel/modprobe
>> /bin/true
>>
>> Expected behaviour would be to have the sysctl be "..." capped at
>> maxlen (in this case KMOD_PATH_LEN: 256), instead of truncating to the
>> contents of the second write. Similarly, multiple short writes would not
>> append to the sysctl.
>>
>> This provides CONFIG_PROC_SYSCTL_STRICT_WRITES as a way to make this
>> behavior act in a less surprising manner for strings, and disallows
>> non-zero file position when writing numeric sysctls (similar to what is
>> already done when reading from non-zero file positions).
>
> Adding a Kconfig knob to alter the behavior of procfs writes creeps me
> out. I wonder why.
>
> - I doubt if many people have a sufficient amount of control over
> their entire systems to be able to confidently set
> CONFIG_PROC_SYSCTL_STRICT_WRITES.
>
> - Software will be shipped which runs OK with one setting but breaks
> with the other setting.
>
> So what to do?
>
> I think we can *detect* this situation easily enough. So some options are
>
> a) change the behaviour and add code which detects when userspace is
>doing a write whose behaviour is now altered. Print a warning. Or
>
> b) leave the behaviour as-is. Add a detector which tells people
>"hey, your userspace is probably broken - please fix". Wait N
>years. Then alter the behaviour as in a).
>
> In either case the detector should display current->comm, the procfs
> pathname and the contents of the write, to aid people in hunting down
> and fixing their userspace.
How about a tri-state sysctl (har har control sysctl behavior with a
sysctl) that defaults ("1") to existing behavior (to not break
anything) with a warning. Mode "2" uses new behavior, and mode "0"
uses existing behavior without a warning? Then we can wait N years and
switch the default to "2"?
-Kees
--
Kees Cook
Chrome OS Security
--
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] ipc/shm.c: increase the limits for SHMMAX, SHMALL
On 04/21/2014 07:25 PM, Davidlohr Bueso wrote: On Mon, 2014-04-21 at 16:26 +0200, Manfred Spraul wrote: Hi all, the increase of SHMMAX/SHMALL is now a 4 patch series. I don't have ideas how to improve it further. Manfred, is there any difference between this set and the one you sent a couple of days ago? a) I updated the comments. b) the initial set used TASK_SIZE, not I switch to ULONG_MAX-(1L<<24) - Using "0" as a magic value for infinity is even worse, because right now 0 means 0, i.e. fail all allocations. Sorry but I don't quite get this. Using 0 eliminates the need for all these patches, no? I mean overflows have existed since forever, and taking this route would naturally solve the problem. 0 allocations are a no no anyways. No. The patches are required to handle e.g. shmget(,ULONG_MAX,): Right now, shmget(,ULONG_MAX,) results in a 0-byte segment. The risk of using 0 is that it reverses the current behavior: Up to now, # sysctl kernel.shmall=0 disables allocations. If we define 0 a infinity, then the same configuration would allow unlimited allocations. -- Manfred -- 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] Kbuild, lto: Avoid reported warning with strtoul
On 21 April 2014 22:20, Andi Kleen wrote: > Hmm that's odd. I guess could assign it to a dummy variable That produces this: scripts/mod/modpost.c: In function ‘remove_dot’: scripts/mod/modpost.c:1708:16: warning: variable ‘ignore’ set but not used [-Wunused-but-set-variable] > or use viro's variant. It looks fine but can't test if works exactly the same way as current implementation. -- 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 2/7] of: introduce of_dma_get_range() helper
On 04/19/2014 09:32 AM, Santosh Shilimkar wrote:
> From: Grygorii Strashko
[..]
> + * Look in bottom up direction for the first "dma-range" property
> + * and parse it.
> + * dma-ranges format:
> + * DMA addr (dma_addr) : naddr cells
> + * CPU addr (phys_addr_t) : pna cells
> + * size: nsize cells
> + *
> + * It returns -ENODEV if "dma-ranges" property was not found
> + * for this device in DT.
> + */
> +extern int of_dma_get_range(struct device_node *np, dma_addr_t *dma_addr,
> + phys_addr_t *paddr, phys_addr_t *size)
> +{
> + struct device_node *node = np;
> + const u32 *ranges = NULL;
> + int len, naddr, nsize, pna;
> + int ret = 0;
> +
> + if (!node)
> + return -EINVAL;
> +
> + while (1) {
> + naddr = of_n_addr_cells(node);
> + nsize = of_n_size_cells(node);
> + node = of_get_next_parent(node);
> + if (!node)
> + break;
> +
> + ranges = of_get_property(node, "dma-ranges", );
> +
> + /* Ignore empty ranges, they imply no translation required */
> + if (ranges && len > 0)
> + break;
> +
> + /*
> + * At least empty ranges has to be defined for parent node if
> + * DMA is supported
> + */
> + if (!ranges)
> + break;
> + }
> +
> + if (!ranges) {
> + pr_debug("%s: no dma-ranges found for node(%s)\n",
> + __func__, np->full_name);
> + ret = -ENODEV;
> + goto out;
> + }
> +
> + len /= sizeof(u32);
> +
> + pna = of_n_addr_cells(node);
> +
> + /* dma-ranges format:
> + * DMA addr : naddr cells
> + * CPU addr : pna cells
> + * size : nsize cells
> + */
> + *dma_addr = of_read_number(ranges, naddr);
> + *paddr = of_translate_dma_address(np, ranges);
I am probably missing something but I'm wondering the need for a
translate step here instead of doing something like:
*paddr = of_read_number(ranges + naddr, pna);
Perhaps there is a need to do a translate step of the DMA Address in
dma-ranges all the way to the parent, which can be different from the
CPU Address (second address in dma-ranges).
in which case the format of dma-ranges after parsing looks like
to the caller, and not,
But for keystone if something like the following is used,
dma-ranges = <0x8000 0x8 0x 0x8000>;
Then, the above fragment I proposed would return 0x8 0x which is
sufficient?
thanks,
-Joel
> + if (*paddr == OF_BAD_ADDR) {
> + pr_err("%s: translation of DMA address(%pad) to CPU address
> failed node(%s)\n",
> +__func__, dma_addr, np->full_name);
> + ret = -EINVAL;
> + }
> +
> + *size = of_read_number(ranges + naddr + pna, nsize);
> +
> + pr_debug("dma_addr(%pad) cpu_addr(%pa) size(%pa)\n",
> + dma_addr, paddr, size);
> +
> +out:
> + of_node_put(node);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(of_dma_get_range);
> #endif /* CONFIG_OF_ADDRESS */
> diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
> index 05cb4a9..ba7d3dc 100644
> --- a/include/linux/of_platform.h
> +++ b/include/linux/of_platform.h
> @@ -72,6 +72,8 @@ extern int of_platform_populate(struct device_node *root,
> const struct of_device_id *matches,
> const struct of_dev_auxdata *lookup,
> struct device *parent);
> +extern int of_dma_get_range(struct device_node *np, dma_addr_t *dma_addr,
> + phys_addr_t *paddr, phys_addr_t *size);
> #else
> static inline int of_platform_populate(struct device_node *root,
> const struct of_device_id *matches,
> @@ -80,6 +82,12 @@ static inline int of_platform_populate(struct device_node
> *root,
> {
> return -ENODEV;
> }
> +
> +static inline int of_dma_get_range(struct device_node *np, dma_addr_t
> *dma_addr,
> + phys_addr_t *paddr, phys_addr_t *size)
> +{
> + return -ENODEV;
> +}
> #endif
>
> #endif /* _LINUX_OF_PLATFORM_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 V2 14/19] tick-sched: add comment about 'idle_active' in tick_nohz_idle_exit()
On Tuesday 22 April 2014 04:50 AM, Frederic Weisbecker wrote: > It's still over-detailed. Much of the above is easily deduced after common > review. OTOH > I proposed to summarize there: https://lkml.org/lkml/2014/4/11/334 > The below disambiguates it a bit further. Hmm.. Something broke for sure in my repo. I do remember updating this patch with your comments and something went wrong while playing with patches. Sorry for that. Fixed my repo now. > Now it's eventually getting as big as your comment ;-) > > > /* >* ts->idle_active drives the idle time which typically elapses in > the idle loop >* but breaks on IRQs interrupting idle loop. >* >* Hence ts->idle_active can be 1 here if we exit the idle loop > without the help of >* an IRQ. OTOH it can be 0 on idle exit if a wake up IPI pulled > the CPU out of >* the idle loop. Since we know that we'll be exiting the idle task > after the wake >* up IPI, all the pending idle sleep time is flushed on irq entry > and no more is >* accounted further thanks to the need_resched() check on > irq_exit(). >*/ @Thomas: Please consider this patch instead: Author: Viresh Kumar Date: Mon Apr 21 15:25:10 2014 +0530 tick-sched: add comment about 'idle_active' in tick_nohz_idle_exit() The sequence of calls for dynticks CPUs is a bit confusing. Add a comment in tick_nohz_idle_exit() to mention it clearly. All information required is in commit and this conversation with Frederic. https://lkml.org/lkml/2014/4/10/355 Suggested-by: Frederic Weisbecker Signed-off-by: Viresh Kumar --- kernel/time/tick-sched.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c index 71f64ee..b2f024f 100644 --- a/kernel/time/tick-sched.c +++ b/kernel/time/tick-sched.c @@ -922,6 +922,17 @@ void tick_nohz_idle_exit(void) ts->inidle = 0; + /* +* ts->idle_active drives the idle time which typically elapses in the +* idle loop but breaks on IRQs interrupting idle loop. +* +* Hence ts->idle_active can be 1 here if we exit the idle loop without +* the help of an IRQ. OTOH it can be 0 on idle exit if a wake up IPI +* pulled the CPU out of the idle loop. Since we know that we'll be +* exiting the idle task after the wake up IPI, all the pending idle +* sleep time is flushed on irq entry and no more is accounted further +* thanks to the need_resched() check on irq_exit(). +*/ if (ts->idle_active || ts->tick_stopped) now = ktime_get(); -- 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 9/9] sysfs: disallow world-writable files.
This check was introduced in 2006 by Alexey Dobriyan (9774a1f54f173)
for module parameters; we removed it when we unified the check into
VERIFY_OCTAL_PERMISSIONS() as sysfs didn't have the same requirement.
Now all those users are fixed, reintroduce it.
Cc: Alexey Dobriyan
Cc: Dave Jones
Cc: Joe Perches
Signed-off-by: Rusty Russell
---
include/linux/kernel.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 4c52907a6d8b..43e1c6a9683e 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -849,5 +849,7 @@ static inline void ftrace_dump(enum ftrace_dump_mode
oops_dump_mode) { }
/* User perms >= group perms >= other perms */ \
BUILD_BUG_ON_ZERO(((perms) >> 6) < (((perms) >> 3) & 7)) + \
BUILD_BUG_ON_ZEROperms) >> 3) & 7) < ((perms) & 7)) + \
+/* Other writable? Generally considered a bad idea. */\
+BUILD_BUG_ON_ZERO((perms) & 2) + \
(perms))
#endif
--
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/
[PATCH 0/9] Avoid world-writable sysfs files.
This adds checking for world-writable sysfs files, after cleaning up all the users. This check has been in module sysfs params since 2006. If you have a reason for being world-writable, please tell me now! Rusty Russell (9): drivers/mtd/devices/docg3.c: avoid world-writable sysfs files. drivers/video/fbdev/sm501fb.c: avoid world-writable sysfs files. drivers/hid/hid-lg4ff.c: avoid world-writable sysfs files. drivers/scsi/pm8001/pm8001_ctl.c: avoid world-writable sysfs files. drivers/regulator/virtual: avoid world-writable sysfs files. drivers/staging/speakup/: avoid world-writable sysfs files. drivers/hid/hid-picolcd_fb: avoid world-writable sysfs files. samples/kobject/: avoid world-writable sysfs files. sysfs: disallow world-writable files. drivers/hid/hid-lg4ff.c | 2 +- drivers/hid/hid-picolcd_fb.c | 2 +- drivers/mtd/devices/docg3.c | 4 +-- drivers/regulator/virtual.c | 10 +++--- drivers/scsi/pm8001/pm8001_ctl.c | 2 +- drivers/staging/speakup/kobjects.c | 60 drivers/staging/speakup/speakup_acntpc.c | 14 drivers/staging/speakup/speakup_acntsa.c | 14 drivers/staging/speakup/speakup_apollo.c | 16 - drivers/staging/speakup/speakup_audptr.c | 16 - drivers/staging/speakup/speakup_bns.c| 14 drivers/staging/speakup/speakup_decext.c | 16 - drivers/staging/speakup/speakup_decpc.c | 16 - drivers/staging/speakup/speakup_dectlk.c | 16 - drivers/staging/speakup/speakup_dtlk.c | 20 +-- drivers/staging/speakup/speakup_dummy.c | 14 drivers/staging/speakup/speakup_keypc.c | 10 +++--- drivers/staging/speakup/speakup_ltlk.c | 20 +-- drivers/staging/speakup/speakup_soft.c | 22 ++-- drivers/staging/speakup/speakup_spkout.c | 16 - drivers/staging/speakup/speakup_txprt.c | 14 drivers/video/fbdev/sm501fb.c| 2 +- include/linux/kernel.h | 2 ++ samples/kobject/kobject-example.c| 7 ++-- samples/kobject/kset-example.c | 7 ++-- 25 files changed, 170 insertions(+), 166 deletions(-) -- 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/
[PATCH 3/9] drivers/hid/hid-lg4ff.c: avoid world-writable sysfs files.
In line with practice for module parameters, we're adding a build-time
check that sysfs files aren't world-writable.
Cc: Simon Wood
Signed-off-by: Rusty Russell
---
drivers/hid/hid-lg4ff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/hid-lg4ff.c b/drivers/hid/hid-lg4ff.c
index 24883b4d1a49..cc2bd2022198 100644
--- a/drivers/hid/hid-lg4ff.c
+++ b/drivers/hid/hid-lg4ff.c
@@ -52,7 +52,7 @@ static void hid_lg4ff_set_range_g25(struct hid_device *hid,
u16 range);
static ssize_t lg4ff_range_show(struct device *dev, struct device_attribute
*attr, char *buf);
static ssize_t lg4ff_range_store(struct device *dev, struct device_attribute
*attr, const char *buf, size_t count);
-static DEVICE_ATTR(range, S_IRWXU | S_IRWXG | S_IRWXO, lg4ff_range_show,
lg4ff_range_store);
+static DEVICE_ATTR(range, S_IRWXU | S_IRWXG | S_IROTH, lg4ff_range_show,
lg4ff_range_store);
struct lg4ff_device_entry {
__u32 product_id;
--
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: ftrace/kprobes: Warning when insmod two modules
Steven Rostedt writes: > On Mon, 24 Mar 2014 20:26:05 +0900 > Masami Hiramatsu wrote: > > >> Thank you for reporting with this pretty backtrace :) >> Steven, I think this is not the kprobe bug but ftrace (and perhaps, module). > > Looks to be more of a module issue than a ftrace issue. > >> >> If the ftrace can set loading module text read only before the module >> subsystem >> expected, I think it should be protected by the module subsystem itself >> (e.g. set_all_modules_text_ro(rw) skips the modules which is >> MODULE_STATE_COMING) >> > > Does this patch fix it? > > In-review-off-by: Steven Rostedt Sorry, was on paternity leave. I'm always nervous about adding more states, since every place which examines the state has to be audited. We set the mod->state to MOD_STATE_COMING in complete_formation; why don't we set NX there instead? It also makes more sense to set NX before we hit parse_args() which can execute code in the module. In fact, we should probably call the notifier there too, so people can breakpoint/tracepoint/etc parameter calls. Of course, this means that we set NX before the notifier; does anything break? Subject: module: set nx before marking module MODULE_STATE_COMING. This prevents a WARN_ON() where ftrace calls set_all_modules_text_ro() which races with the module setting its own set_section_ro_nx(). It also means we're NX protected before we call parse_args(), which can execute module code. This means that the notifiers will be called on a module which is already NX, so that may cause problems. Signed-off-by: Rusty Russell diff --git a/kernel/module.c b/kernel/module.c index 11869408f79b..83a437e5d429 100644 --- a/kernel/module.c +++ b/kernel/module.c @@ -3023,21 +3023,6 @@ static int do_init_module(struct module *mod) */ current->flags &= ~PF_USED_ASYNC; - blocking_notifier_call_chain(_notify_list, - MODULE_STATE_COMING, mod); - - /* Set RO and NX regions for core */ - set_section_ro_nx(mod->module_core, - mod->core_text_size, - mod->core_ro_size, - mod->core_size); - - /* Set RO and NX regions for init */ - set_section_ro_nx(mod->module_init, - mod->init_text_size, - mod->init_ro_size, - mod->init_size); - do_mod_ctors(mod); /* Start the module */ if (mod->init != NULL) @@ -3168,9 +3153,26 @@ static int complete_formation(struct module *mod, struct load_info *info) /* This relies on module_mutex for list integrity. */ module_bug_finalize(info->hdr, info->sechdrs, mod); + /* Set RO and NX regions for core */ + set_section_ro_nx(mod->module_core, + mod->core_text_size, + mod->core_ro_size, + mod->core_size); + + /* Set RO and NX regions for init */ + set_section_ro_nx(mod->module_init, + mod->init_text_size, + mod->init_ro_size, + mod->init_size); + /* Mark state as coming so strong_try_module_get() ignores us, * but kallsyms etc. can see us. */ mod->state = MODULE_STATE_COMING; + mutex_unlock(_mutex); + + blocking_notifier_call_chain(_notify_list, +MODULE_STATE_COMING, mod); + return 0; out: mutex_unlock(_mutex); -- 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/9] drivers/video/fbdev/sm501fb.c: avoid world-writable sysfs files.
In line with practice for module parameters, we're adding a build-time check that sysfs files aren't world-writable. Cc: Vincent Sanders Cc: Ben Dooks Signed-off-by: Rusty Russell --- drivers/video/fbdev/sm501fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/sm501fb.c b/drivers/video/fbdev/sm501fb.c index 1501979099dc..c2c8eb668784 100644 --- a/drivers/video/fbdev/sm501fb.c +++ b/drivers/video/fbdev/sm501fb.c @@ -1215,7 +1215,7 @@ static ssize_t sm501fb_crtsrc_store(struct device *dev, } /* Prepare the device_attr for registration with sysfs later */ -static DEVICE_ATTR(crt_src, 0666, sm501fb_crtsrc_show, sm501fb_crtsrc_store); +static DEVICE_ATTR(crt_src, 0664, sm501fb_crtsrc_show, sm501fb_crtsrc_store); /* sm501fb_show_regs * -- 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/
[PATCH 8/9] samples/kobject/: avoid world-writable sysfs files.
In line with practice for module parameters, we're adding a build-time check that sysfs files aren't world-writable. Cc: Greg Kroah-Hartman Signed-off-by: Rusty Russell --- samples/kobject/kobject-example.c | 7 --- samples/kobject/kset-example.c| 7 --- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/samples/kobject/kobject-example.c b/samples/kobject/kobject-example.c index 86ea0c3ad975..01562e0d4992 100644 --- a/samples/kobject/kobject-example.c +++ b/samples/kobject/kobject-example.c @@ -40,8 +40,9 @@ static ssize_t foo_store(struct kobject *kobj, struct kobj_attribute *attr, return count; } +/* Sysfs attributes cannot be world-writable. */ static struct kobj_attribute foo_attribute = - __ATTR(foo, 0666, foo_show, foo_store); + __ATTR(foo, 0664, foo_show, foo_store); /* * More complex function where we determine which variable is being accessed by @@ -73,9 +74,9 @@ static ssize_t b_store(struct kobject *kobj, struct kobj_attribute *attr, } static struct kobj_attribute baz_attribute = - __ATTR(baz, 0666, b_show, b_store); + __ATTR(baz, 0664, b_show, b_store); static struct kobj_attribute bar_attribute = - __ATTR(bar, 0666, b_show, b_store); + __ATTR(bar, 0664, b_show, b_store); /* diff --git a/samples/kobject/kset-example.c b/samples/kobject/kset-example.c index 5dce351f131f..ab5e447ec238 100644 --- a/samples/kobject/kset-example.c +++ b/samples/kobject/kset-example.c @@ -124,8 +124,9 @@ static ssize_t foo_store(struct foo_obj *foo_obj, struct foo_attribute *attr, return count; } +/* Sysfs attributes cannot be world-writable. */ static struct foo_attribute foo_attribute = - __ATTR(foo, 0666, foo_show, foo_store); + __ATTR(foo, 0664, foo_show, foo_store); /* * More complex function where we determine which variable is being accessed by @@ -157,9 +158,9 @@ static ssize_t b_store(struct foo_obj *foo_obj, struct foo_attribute *attr, } static struct foo_attribute baz_attribute = - __ATTR(baz, 0666, b_show, b_store); + __ATTR(baz, 0664, b_show, b_store); static struct foo_attribute bar_attribute = - __ATTR(bar, 0666, b_show, b_store); + __ATTR(bar, 0664, b_show, b_store); /* * Create a group of attributes so that we can create and destroy them all -- 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/
[PATCH 6/9] drivers/staging/speakup/: avoid world-writable sysfs files.
In line with practice for module parameters, we're adding a build-time check that sysfs files aren't world-writable. Cc: Christopher Brannon Cc: Samuel Thibault Cc: Greg Kroah-Hartman Signed-off-by: Rusty Russell --- drivers/staging/speakup/kobjects.c | 60 drivers/staging/speakup/speakup_acntpc.c | 14 drivers/staging/speakup/speakup_acntsa.c | 14 drivers/staging/speakup/speakup_apollo.c | 16 - drivers/staging/speakup/speakup_audptr.c | 16 - drivers/staging/speakup/speakup_bns.c| 14 drivers/staging/speakup/speakup_decext.c | 16 - drivers/staging/speakup/speakup_decpc.c | 16 - drivers/staging/speakup/speakup_dectlk.c | 16 - drivers/staging/speakup/speakup_dtlk.c | 20 +-- drivers/staging/speakup/speakup_dummy.c | 14 drivers/staging/speakup/speakup_keypc.c | 10 +++--- drivers/staging/speakup/speakup_ltlk.c | 20 +-- drivers/staging/speakup/speakup_soft.c | 22 ++-- drivers/staging/speakup/speakup_spkout.c | 16 - drivers/staging/speakup/speakup_txprt.c | 14 16 files changed, 149 insertions(+), 149 deletions(-) diff --git a/drivers/staging/speakup/kobjects.c b/drivers/staging/speakup/kobjects.c index 1ca91f7092b1..c4aa13fc2d13 100644 --- a/drivers/staging/speakup/kobjects.c +++ b/drivers/staging/speakup/kobjects.c @@ -853,73 +853,73 @@ static ssize_t message_store(struct kobject *kobj, struct kobj_attribute *attr, static struct kobj_attribute keymap_attribute = __ATTR(keymap, S_IWUSR|S_IRUGO, keymap_show, keymap_store); static struct kobj_attribute silent_attribute = - __ATTR(silent, S_IWUGO, NULL, silent_store); + __ATTR(silent, S_IWUSR|S_IWGRP, NULL, silent_store); static struct kobj_attribute synth_attribute = - __ATTR(synth, S_IWUGO|S_IRUGO, synth_show, synth_store); + __ATTR(synth, S_IWUSR|S_IWGRP|S_IRUGO, synth_show, synth_store); static struct kobj_attribute synth_direct_attribute = - __ATTR(synth_direct, S_IWUGO, NULL, synth_direct_store); + __ATTR(synth_direct, S_IWUSR|S_IWGRP, NULL, synth_direct_store); static struct kobj_attribute version_attribute = __ATTR_RO(version); static struct kobj_attribute delimiters_attribute = - __ATTR(delimiters, S_IWUGO|S_IRUGO, punc_show, punc_store); + __ATTR(delimiters, S_IWUSR|S_IWGRP|S_IRUGO, punc_show, punc_store); static struct kobj_attribute ex_num_attribute = - __ATTR(ex_num, S_IWUGO|S_IRUGO, punc_show, punc_store); + __ATTR(ex_num, S_IWUSR|S_IWGRP|S_IRUGO, punc_show, punc_store); static struct kobj_attribute punc_all_attribute = - __ATTR(punc_all, S_IWUGO|S_IRUGO, punc_show, punc_store); + __ATTR(punc_all, S_IWUSR|S_IWGRP|S_IRUGO, punc_show, punc_store); static struct kobj_attribute punc_most_attribute = - __ATTR(punc_most, S_IWUGO|S_IRUGO, punc_show, punc_store); + __ATTR(punc_most, S_IWUSR|S_IWGRP|S_IRUGO, punc_show, punc_store); static struct kobj_attribute punc_some_attribute = - __ATTR(punc_some, S_IWUGO|S_IRUGO, punc_show, punc_store); + __ATTR(punc_some, S_IWUSR|S_IWGRP|S_IRUGO, punc_show, punc_store); static struct kobj_attribute repeats_attribute = - __ATTR(repeats, S_IWUGO|S_IRUGO, punc_show, punc_store); + __ATTR(repeats, S_IWUSR|S_IWGRP|S_IRUGO, punc_show, punc_store); static struct kobj_attribute attrib_bleep_attribute = - __ATTR(attrib_bleep, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store); + __ATTR(attrib_bleep, S_IWUSR|S_IWGRP|S_IRUGO, spk_var_show, spk_var_store); static struct kobj_attribute bell_pos_attribute = - __ATTR(bell_pos, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store); + __ATTR(bell_pos, S_IWUSR|S_IWGRP|S_IRUGO, spk_var_show, spk_var_store); static struct kobj_attribute bleep_time_attribute = - __ATTR(bleep_time, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store); + __ATTR(bleep_time, S_IWUSR|S_IWGRP|S_IRUGO, spk_var_show, spk_var_store); static struct kobj_attribute bleeps_attribute = - __ATTR(bleeps, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store); + __ATTR(bleeps, S_IWUSR|S_IWGRP|S_IRUGO, spk_var_show, spk_var_store); static struct kobj_attribute cursor_time_attribute = - __ATTR(cursor_time, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store); + __ATTR(cursor_time, S_IWUSR|S_IWGRP|S_IRUGO, spk_var_show, spk_var_store); static struct kobj_attribute key_echo_attribute = - __ATTR(key_echo, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store); + __ATTR(key_echo, S_IWUSR|S_IWGRP|S_IRUGO, spk_var_show, spk_var_store); static struct kobj_attribute no_interrupt_attribute = - __ATTR(no_interrupt, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store); + __ATTR(no_interrupt, S_IWUSR|S_IWGRP|S_IRUGO, spk_var_show, spk_var_store); static struct kobj_attribute punc_level_attribute = - __ATTR(punc_level, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store);
[PATCH 1/9] drivers/mtd/devices/docg3.c: avoid world-writable sysfs files.
In line with practice for module parameters, we're adding a build-time
check that sysfs files aren't world-writable.
Cc: Robert Jarzmik
Signed-off-by: Rusty Russell
---
drivers/mtd/devices/docg3.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/devices/docg3.c b/drivers/mtd/devices/docg3.c
index dd5e1018d37b..91a169c44b39 100644
--- a/drivers/mtd/devices/docg3.c
+++ b/drivers/mtd/devices/docg3.c
@@ -1608,8 +1608,8 @@ static ssize_t dps1_insert_key(struct device *dev,
#define FLOOR_SYSFS(id) { \
__ATTR(f##id##_dps0_is_keylocked, S_IRUGO, dps0_is_key_locked, NULL), \
__ATTR(f##id##_dps1_is_keylocked, S_IRUGO, dps1_is_key_locked, NULL), \
- __ATTR(f##id##_dps0_protection_key, S_IWUGO, NULL, dps0_insert_key), \
- __ATTR(f##id##_dps1_protection_key, S_IWUGO, NULL, dps1_insert_key), \
+ __ATTR(f##id##_dps0_protection_key, S_IWUSR|S_IWGRP, NULL,
dps0_insert_key), \
+ __ATTR(f##id##_dps1_protection_key, S_IWUSR|S_IWGRP, NULL,
dps1_insert_key), \
}
static struct device_attribute doc_sys_attrs[DOC_MAX_NBFLOORS][4] = {
--
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/
[PATCH 4/9] drivers/scsi/pm8001/pm8001_ctl.c: avoid world-writable sysfs files.
In line with practice for module parameters, we're adding a build-time
check that sysfs files aren't world-writable.
Cc: Lindar Liu
Cc: James Bottomley
Signed-off-by: Rusty Russell
---
drivers/scsi/pm8001/pm8001_ctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/pm8001/pm8001_ctl.c b/drivers/scsi/pm8001/pm8001_ctl.c
index 28b4e8139153..62c884e79409 100644
--- a/drivers/scsi/pm8001/pm8001_ctl.c
+++ b/drivers/scsi/pm8001/pm8001_ctl.c
@@ -729,7 +729,7 @@ static ssize_t pm8001_show_update_fw(struct device *cdev,
flash_error_table[i].reason);
}
-static DEVICE_ATTR(update_fw, S_IRUGO|S_IWUGO,
+static DEVICE_ATTR(update_fw, S_IRUGO|S_IWUSR|S_IWGRP,
pm8001_show_update_fw, pm8001_store_update_fw);
struct device_attribute *pm8001_host_attrs[] = {
_attr_interface_rev,
--
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/
[PATCH 5/9] drivers/regulator/virtual: avoid world-writable sysfs files.
In line with practice for module parameters, we're adding a build-time
check that sysfs files aren't world-writable.
Cc: Mark Brown
Signed-off-by: Rusty Russell
---
drivers/regulator/virtual.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/regulator/virtual.c b/drivers/regulator/virtual.c
index f53e78b9a84e..6ff95b045984 100644
--- a/drivers/regulator/virtual.c
+++ b/drivers/regulator/virtual.c
@@ -266,11 +266,11 @@ static ssize_t set_mode(struct device *dev, struct
device_attribute *attr,
return count;
}
-static DEVICE_ATTR(min_microvolts, 0666, show_min_uV, set_min_uV);
-static DEVICE_ATTR(max_microvolts, 0666, show_max_uV, set_max_uV);
-static DEVICE_ATTR(min_microamps, 0666, show_min_uA, set_min_uA);
-static DEVICE_ATTR(max_microamps, 0666, show_max_uA, set_max_uA);
-static DEVICE_ATTR(mode, 0666, show_mode, set_mode);
+static DEVICE_ATTR(min_microvolts, 0664, show_min_uV, set_min_uV);
+static DEVICE_ATTR(max_microvolts, 0664, show_max_uV, set_max_uV);
+static DEVICE_ATTR(min_microamps, 0664, show_min_uA, set_min_uA);
+static DEVICE_ATTR(max_microamps, 0664, show_max_uA, set_max_uA);
+static DEVICE_ATTR(mode, 0664, show_mode, set_mode);
static struct attribute *regulator_virtual_attributes[] = {
_attr_min_microvolts.attr,
--
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/
[PATCH 7/9] drivers/hid/hid-picolcd_fb: avoid world-writable sysfs files.
In line with practice for module parameters, we're adding a build-time check that sysfs files aren't world-writable. Cc: Bruno Prémont Signed-off-by: Rusty Russell --- drivers/hid/hid-picolcd_fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hid/hid-picolcd_fb.c b/drivers/hid/hid-picolcd_fb.c index c930ab8554ea..7f965e231433 100644 --- a/drivers/hid/hid-picolcd_fb.c +++ b/drivers/hid/hid-picolcd_fb.c @@ -501,7 +501,7 @@ static ssize_t picolcd_fb_update_rate_store(struct device *dev, return count; } -static DEVICE_ATTR(fb_update_rate, 0666, picolcd_fb_update_rate_show, +static DEVICE_ATTR(fb_update_rate, 0664, picolcd_fb_update_rate_show, picolcd_fb_update_rate_store); /* initialize Framebuffer device */ -- 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/
linux-next: manual merge of the audit tree with Linus' tree
Hi Eric,
Today's linux-next merge of the audit tree got a conflict in
arch/mips/kernel/ptrace.c between commits 6e34574603f6 ("MIPS: asm:
syscall: Define syscall_get_arch") and 1225eb825208("MIPS: ptrace: Move
away from secure_computing_strict") from Linus' tree and commit
8ea408a0c1e7 ("ARCH: AUDIT: audit_syscall_entry() should not require the
arch") from the audit tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/mips/kernel/ptrace.c
index 71f85f427034,8b393bcf7919..
--- a/arch/mips/kernel/ptrace.c
+++ b/arch/mips/kernel/ptrace.c
@@@ -649,11 -677,8 +649,9 @@@ asmlinkage long syscall_trace_enter(str
if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT)))
trace_sys_enter(regs, regs->regs[2]);
- audit_syscall_entry(syscall_get_arch(),
- syscall,
- regs->regs[4], regs->regs[5],
- audit_syscall_entry(regs->regs[2], regs->regs[4], regs->regs[5],
++ audit_syscall_entry(syscall, regs->regs[4], regs->regs[5],
regs->regs[6], regs->regs[7]);
+ return syscall;
}
/*
pgpm_h4k4dA2y.pgp
Description: PGP signature
Re: [PATCH 1/2] gpio: pl061: get gpio base from alias id
Hi Haojian Zhuang,
On Tue, Apr 22, 2014 at 09:35:42AM +0800, Haojian Zhuang wrote:
> If gpio base number isn't specified, the gpio base will be find from
> the end of gpio number. In order to keep with schematics, use alias
> to get the ID of gpio chip.
>
> Signed-off-by: Haojian Zhuang
> ---
> .../devicetree/bindings/gpio/gpio-pl061.txt| 31
> ++
Binding documentation should be done in a separate patch.
> drivers/gpio/gpio-pl061.c | 14 +-
> 2 files changed, 44 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-pl061.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-pl061.txt
> b/Documentation/devicetree/bindings/gpio/gpio-pl061.txt
> new file mode 100644
> index 000..164b5ba
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-pl061.txt
> @@ -0,0 +1,31 @@
> +PL061 GPIO controller bindings
> +
> +Required properties:
> +- compatible:
> + - "arm,pl061", "arm,primecell".
> +- #gpio-cells : Should be two.
> + - first cell is the gpio pin number
> + - second cell is used to specify the gpio polarity:
> + 0 = active high
> + 1 = active low
> +- gpio-controller : Marks the device node as a GPIO controller.
> +- interrupt-controller : Marks the device node as an interrupt controller.
> +- #interrupt-cells : Should be two.
> + - first cell is the hw irq number
> + - second cell is used to specify the interrupt type:
> + 0 = default, unspecified type
> + 1 = rising edge triggered
> + 2 = falling edge triggered
> + 4 = high level triggered
> + 8 = low level triggered
> +
> +Example:
> + gpio0: gpio@fc806000 {
> + compatible = "arm,pl061", "arm,primecell";
> + reg = <0xfc806000 0x1000>;
> + interrupts = <0 64 0x4>;
The "interrupts" property should be mentioned above.
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
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.14 Regression, kernel panic when suspend, looks ath9k / wireless related
On Sat, Apr 19, 2014 at 12:32 PM, Michael Leun wrote: > 2a901468c221e778af52603e006a53 Odd -- its unclear how you ended up with this bisect given that REGULATORY_COUNTRY_IE_IGNORE is not set for any driver currently. To see this you can try: mcgrof@ergon ~/linux-stable (git::linux-3.14.y)$ git grep REGULATORY_COUNTRY_IE_IGNORE drivers/net/wireless/ That said, I'm happy to revert this as no driver is using it anyway. Folks who care for it can help fix this when they get the Fisher Price (TM) driver upstream. I however don't think however this is the issue though, this may be a timing issue and by reverting this commit you just so happen to not get it triggered. I'll Cc you on some series of fixes and if you can test one of those patches on top of v3.14.1 that'd be appreciated as an alternative. I'm also very curious to hear no one else would have run into the same regression as you have. Luis -- 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 Resend] defconfig: sama5_defconfig: updated
due to enabling -- CONFIG_REGULATOR -- CONFIG_REGULATOR_ACT8865 Signed-off-by: Wenyou Yang --- Hi Nicolas, It is a typo. This patch is based on the branch: at91-3.16-dt, not at91-3.10-dt of git://github.com/at91linux/linux-at91.git Best Regards, Wenyou Yang arch/arm/configs/sama5_defconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/sama5_defconfig b/arch/arm/configs/sama5_defconfig index dc3881e..2b9891e 100644 --- a/arch/arm/configs/sama5_defconfig +++ b/arch/arm/configs/sama5_defconfig @@ -201,3 +201,5 @@ CONFIG_CRYPTO_DEV_ATMEL_TDES=y CONFIG_CRYPTO_DEV_ATMEL_SHA=y CONFIG_CRC_CCITT=m CONFIG_CRC_ITU_T=m +CONFIG_REGULATOR=y +CONFIG_REGULATOR_ACT8865=y -- 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 V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Jingoo, On Tue, Apr 22, 2014 at 7:48 AM, Jingoo Han wrote: > On Wednesday, April 16, 2014 11:49 PM, Vivek Gautam wrote: >> On Wed, Apr 16, 2014 at 7:14 PM, Tomasz Figa wrote: >> > On 15.04.2014 08:09, Vivek Gautam wrote: >> >> On Thu, Apr 10, 2014 at 5:09 PM, Vivek Gautam wrote: >> >>> On Wed, Apr 9, 2014 at 7:03 PM, Tomasz Figa wrote: >> On 09.04.2014 13:49, Vivek Gautam wrote: >> >>> >> >>> So, USB30_SCLK_100M is the SCLK that we are talking in the driver. I >> >>> don't see any reference to XXTI in the USB 3.0 DRD controller chapter >> >>> (in both Exynos5250 and 5420) >> >>> In addition to this there's one more point to be noticed here. >> >>> On Exynos5420 system, the sclk_usbphy300 (which is the sclk_usbphy30 >> >>> for USB DRD channel 0), is also the PICO phy clock, i.e. USB 2.0 phy >> >>> clock. >> >>> So we should add a similar clk_get() for this clock in the >> >>> phy-exynos5250-usb2 driver too, to support Exynos5420. >> >> >> >> >> >> Is something clear from the above block diagram ? (although the >> >> diagram looks weird - space and tabs problem :-( ) >> >> Basically there's the clock USB30_SCLK_100M which is going into the >> >> USB 3.0 DRD PHY controller. >> >> And this is the only sclk mentioned in the block diagram for USB 3.0 >> >> DRD controller in Exynos5420. >> >> Same is not there in the block diagram in Exynos5250 UM. >> > >> > >> > From what I can see in the documentation, there are 4 USB 3.0 related >> > clocks >> > generated in CMU: >> > >> > - sclk_usbphy300, >> > - sclk_usbphy301, >> > - sclk_usbdrd300, >> > - sclk_usbdrd301, >> > >> > They are all rated to max. 24 MHz and the recommended operating frequency >> > is >> > 24 MHz, so it looks exactly like USB PHY reference, which is usually a 24 >> > MHz clock. >> > >> > To me, this looks like on Exynos5420 a separate special clock path is used >> > instead of xusbxti as reference of USB 3.0 PHY and so the sclk should be >> > simply passed as the "ref" clock. >> >> Ok, i will clear on this with the hardware engineer also once. >> May be Jingoo can help me with this. >> >> Jingoo, >> Can you please enquire about the clock path of usbphy30 reference >> clocks on Exynos5420. >> As mentioned by Tomasz above, we have sclk_usbphy300 and >> sclk_usbphy301 as the reference clocks for USB3.0 DRD phy. *Also* >> sclk_usbphy300 is used for Pico phy (which is the USb 2.0 phy used by >> ehci/ohci controller on Exynos5420). >> It will be of great help. > > Hi Vevek, Tomasz > > Long time no see. > > I asked USB S/W engineer and USB H/W engineer. > > There are two USB3.0 on Exynos5420; thus there are two sclks > such as 'sclk_usbphy300 and sclk_usbphy301'. > > As Tomasz mentioned, 'sclk_usbphy300 and sclk_usbphy301' can > be used instead of 'xusbxti' as reference of USB 3.0 PHY. Thank you so much for getting this information. I can re-spin the patch. :-) > > However, on Exynos5420, "ONLY" 'sclk_usbphy300' can be used > for USB2.0 pico phy. (so, '301' CANNOT support USB2.0 pico phy.) True, for USB 2.0 pico phy, only sclk_usbphy300 can be used. -- 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 v2.0] ARM: dts: at91-sama5d3_xplained: add the regulator device node
Signed-off-by: Wenyou Yang
---
Hi Nicolas,
This patch is based on the branch: at91-3.16-dt
git://github.com/at91linux/linux-at91.git
Best Regards,
Wenyou Yang
Changelog:
v2.0
1./ Remove vddana_reg's property: regulator-always-on.
arch/arm/boot/dts/at91-sama5d3_xplained.dts | 41 +++
1 file changed, 41 insertions(+)
diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
index ce13755..8361617 100644
--- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
@@ -48,6 +48,47 @@
i2c1: i2c@f0018000 {
status = "okay";
+
+ pmic: act8865@5b {
+ compatible = "active-semi,act8865";
+ reg = <0x5b>;
+ status = "okay";
+
+ regulators {
+ vcc_1v8_reg: DCDC_REG1 {
+ regulator-name =
"VCC_1V8";
+ regulator-min-microvolt
= <180>;
+ regulator-max-microvolt
= <180>;
+ regulator-always-on;
+ };
+
+ vcc_1v2_reg: DCDC_REG2 {
+ regulator-name =
"VCC_1V2";
+ regulator-min-microvolt
= <120>;
+ regulator-max-microvolt
= <120>;
+ regulator-always-on;
+ };
+
+ vcc_3v3_reg: DCDC_REG3 {
+ regulator-name =
"VCC_3V3";
+ regulator-min-microvolt
= <330>;
+ regulator-max-microvolt
= <330>;
+ regulator-always-on;
+ };
+
+ vddfuse_reg: LDO_REG1 {
+ regulator-name =
"FUSE_2V5";
+ regulator-min-microvolt
= <250>;
+ regulator-max-microvolt
= <250>;
+ };
+
+ vddana_reg: LDO_REG2 {
+ regulator-name =
"VDDANA";
+ regulator-min-microvolt
= <330>;
+ regulator-max-microvolt
= <330>;
+ };
+ };
+ };
};
macb0: ethernet@f0028000 {
--
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: [RFC PATCH v5 2/2] Use kernfs_break_active_protection() for device online store callbacks
On Mon, 2014-04-21 at 18:46 -0400, Tejun Heo wrote:
> Hello,
>
> On Mon, Apr 21, 2014 at 05:23:50PM +0800, Li Zhong wrote:
>
> Proper /** function comment would be nice.
Ok, will try to write some in next version.
>
> > +struct kernfs_node *lock_device_hotplug_sysfs(struct device *dev,
> > + struct device_attribute *attr)
>
> I can see why you did this but let's please not require the user of
> this function to see how the thing is working internally. Let's
> return int and keep track of (or look up again) the kernfs_node
> internally.
Ok, it also makes the prototype of lock and unlock look more consistent
and comfortable.
>
> > {
> ...
> > + /*
> > +* We assume device_hotplug_lock must be acquired before removing
>
> Is this assumption true? If so, can we add lockdep assertions in
> places to verify and enforce this? If not, aren't we just feeling
> good when the reality is broken?
It seems not true ... I think there are devices that don't have the
online/offline concept, we just need to add it, remove it, like ethernet
cards.
Maybe we could change the comments above, like:
/* We assume device_hotplug_lock must be acquired before
* removing devices, which have online/offline sysfs knob,
* and some locks are needed to serialize the online/offline
* callbacks and device removing. ...
?
And we could add lockdep assertions in cpu and memory related code? e.g.
remove_memory(), unregister_cpu()
Currently, remove_memory() has comments for the function:
* NOTE: The caller must call lock_device_hotplug() to serialize hotplug
* and online/offline operations before this call, as required by
* try_offline_node().
*/
maybe it could be removed with the lockdep assertion.
> ...
>
> Function comment please.
OK.
Thanks, Zhong
> > +void unlock_device_hotplug_sysfs(struct device *dev,
> > +struct kernfs_node *kn)
> > +{
> > + unlock_device_hotplug();
> > + kernfs_unbreak_active_protection(kn);
> > + put_device(dev);
> > + kernfs_put(kn);
> > }
>
> 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 v2] KVM: x86: Check for host supported fields in shadow vmcs
Il 21/04/2014 15:20, Bandan Das ha scritto:
+ for (i = j = 0; i < max_shadow_read_write_fields; i++) {
+
Extra empty line. Not a big deal, but...
+ switch (shadow_read_write_fields[i]) {
+ case GUEST_BNDCFGS:
+ if (!vmx_mpx_supported())
+ continue;
+ break;
+ default:
+ break;
+ }
+
+ if (j < i)
+ shadow_read_write_fields[j] =
+ shadow_read_write_fields[i];
+ j++;
... you need to respin anyway because the j++ is wrong. It should be
inside the "if". If you prefer, you can put it in the lhs of the
assignment, otherwise a separate statement is fine by me too.
Paolo
--
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/5] KVM: vmx: speed up emulation of invalid guest state
Il 20/04/2014 22:13, Marcelo Tosatti ha scritto: The same code which resets it to false inside the handle_invalid_guest_state loop (so you would stop emulating at the same point as you do with this patch). So (barring any bugs where we fail to set vmx->emulation_required to true) the "vmx->emulation_required = true;" on vmentry error would be dead code. Advantage would be that failure to set vmx->emulation_required to true would not cause VM-entry failure. A place where we fail to set vmx->emulation_required to true is quite likely to also be wrong when setting vmx->emulation_required to false. Since this is not something that has ever seen much churn, I think it's better to code it in a way that shows bugs easily. The bugs do not affect the host anyway. Paolo -- 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] perf tools: Remove extra '/' character in events file path
The array debugfs_known_mountpoints[] will cause extra '/'
character output.
Remove it.
pre:
$ perf probe -l
/sys/kernel/debug//tracing/uprobe_events file does not exist -
please rebuild kernel with CONFIG_UPROBE_EVENTS.
post:
$ perf probe -l
/sys/kernel/debug/tracing/uprobe_events file does not exist -
please rebuild kernel with CONFIG_UPROBE_EVENTS.
Signed-off-by: Xia Kaixu
---
tools/lib/api/fs/debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/lib/api/fs/debugfs.c b/tools/lib/api/fs/debugfs.c
index 7c43479..a74fba6 100644
--- a/tools/lib/api/fs/debugfs.c
+++ b/tools/lib/api/fs/debugfs.c
@@ -12,8 +12,8 @@
char debugfs_mountpoint[PATH_MAX + 1] = "/sys/kernel/debug";
static const char * const debugfs_known_mountpoints[] = {
- "/sys/kernel/debug/",
- "/debug/",
+ "/sys/kernel/debug",
+ "/debug",
0,
};
--
1.8.5.5
.
.
___
kernel.openeuler mailing list
kernel.openeu...@huawei.com
http://rnd-openeuler.huawei.com/mailman/listinfo/kernel.openeuler
--
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: kaslr relocation incompitable with kernel loaded high
On 04/21/14 at 11:01am, Kees Cook wrote: > On Mon, Apr 21, 2014 at 10:56 AM, Yinghai Lu wrote: > > On Mon, Apr 21, 2014 at 3:52 AM, WANG Chao wrote: > >> Hi, Kees > >> > >> When I'm testing kaslr with kdump, I find that when 2nd kernel is loaded > >> high, it doesn't boot. > >> > >> I reserved 128M memory at high with kernel cmdline > >> "crashkernel=128M,high crashkernel=0,low", and for which I got: > >> > >> [0.00] Reserving 128MB of memory at 6896MB for crashkernel (System > >> RAM: 6013MB) > >> > >> Then I load kdump kernel into the reserved memory region, using a local > >> modified kexec-tools which is passing e820 in boot_params. > >> > >> The e820 map of system RAM passed to 2nd kernel: > >> > >> E820 memmap (of RAM): > >> 1000-0009e3ff (1) > >> 0001af00-0001b6f5dfff (1) > >> 0001b6fff400-0001b6ff (1) > >> > >> In which, 2nd kernel is loaded at 0x1b500. > >> > >> After triggerred a system crash, 2nd kernel doesn't boot even with > >> "nokaslr" cmdline: > >> > >> # echo c > /proc/sysrq-trigger > >> [..] > >> > >> I'm in purgatory > >> early console in decompress_kernel > >> KASLR disabled... > >> > >> Decompressing Linux... Parsing ELF... Performing relocations... > >> > >> 32-bit relocation outside of kernel! > > > > Interesting, when kernel get at "early console in decompress_kernel" > > kernel already in 64 bit... > > > > what does it mean "32-bit relocation outside of kernel" ? > > > > why 32-bit is involved ? > > The 64-bit kernel has both 64 and 32 bit relocations (there are two > tables at the end of the kernel image). The error means that the > resulting relocation is believed to be outside the kernel image: > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/x86/boot/compressed/misc.c#n283 > > Which means there is likely something wrong with this calculation in > your situation: > > /* > * Calculate the delta between where vmlinux was linked to load > * and where it was actually loaded. > */ > delta = min_addr - LOAD_PHYSICAL_ADDR; > Probably. I'm wondering why such relocation is still needed when kaslr is disabled in 64bit path. I think the relocation work is already handled in head_64.S. FWIW, I got these following relocation info: # arch/x86/tools/relocs --text vmlinux .section ".data.reloc","a" .balign 4 .long 0x .long 0x81004687 [..] .long 0x81e6b018 .long 0x .long 0x810a [..] .long 0x81e6c9fc Thanks WANG Chao -- 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] zram: correct offset usage in zram_bio_discard
we want to skip the logical block which is partially covered by
the discard bio, so check the remaining size and subtract it if
there is a need to goto the next logical block.
This patch corrects the offset usage in zram_bio_discard.
Signed-off-by: Weijie Yang
---
drivers/block/zram/zram_drv.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 9849b52..48eccb3 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -572,10 +572,10 @@ static void zram_bio_discard(struct zram *zram, u32 index,
* skipping this logical block is appropriate here.
*/
if (offset) {
- if (n < offset)
+ if (n <= (PAGE_SIZE - offset))
return;
- n -= offset;
+ n -= (PAGE_SIZE - offset);
index++;
}
--
1.7.10.4
--
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/
linux-next: build failure after merge of the mmc tree
Hi Chris,
After merging the mmc tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/net/wireless/rsi/rsi_91x_sdio.c: In function 'rsi_reset_card':
drivers/net/wireless/rsi/rsi_91x_sdio.c:288:20: error: 'MMC_STATE_HIGHSPEED'
undeclared (first use in this function)
card->state &= ~MMC_STATE_HIGHSPEED;
^
drivers/net/wireless/rsi/rsi_91x_sdio.c:288:20: note: each undeclared
identifier is reported only once for each function it appears in
drivers/net/wireless/rsi/rsi_91x_sdio.c:299:4: error: implicit declaration of
function 'mmc_card_set_highspeed' [-Werror=implicit-function-declaration]
mmc_card_set_highspeed(card);
^
drivers/net/wireless/rsi/rsi_91x_sdio.c:306:2: error: implicit declaration of
function 'mmc_card_highspeed' [-Werror=implicit-function-declaration]
if (mmc_card_highspeed(card))
^
Caused by commit 395784826a81 ("mmc: drop the speed mode of card's state").
I have used the version of the mmc tree from next-20140417 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgplr9bhmIoha.pgp
Description: PGP signature
Re: [PATCH 1/6] blackfin/ptrace: call find_vma with the mmap_sem held
Hi Davidlohr,
On Sun, Apr 20, 2014 at 10:26 AM, Davidlohr Bueso wrote:
> Performing vma lookups without taking the mm->mmap_sem is asking
> for trouble. While doing the search, the vma in question can be
> modified or even removed before returning to the caller. Take the
> lock (shared) in order to avoid races while iterating through the
> vmacache and/or rbtree.
Yes, mm->mmap_sem should lock here. Applied, thanks.
>
> This patch is completely *untested*.
>
> Signed-off-by: Davidlohr Bueso
> Cc: Steven Miao
> Cc: adi-buildroot-de...@lists.sourceforge.net
> ---
> arch/blackfin/kernel/ptrace.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/blackfin/kernel/ptrace.c b/arch/blackfin/kernel/ptrace.c
> index e1f88e0..8b8fe67 100644
> --- a/arch/blackfin/kernel/ptrace.c
> +++ b/arch/blackfin/kernel/ptrace.c
> @@ -117,6 +117,7 @@ put_reg(struct task_struct *task, unsigned long regno,
> unsigned long data)
> int
> is_user_addr_valid(struct task_struct *child, unsigned long start, unsigned
> long len)
> {
> + bool valid;
> struct vm_area_struct *vma;
> struct sram_list_struct *sraml;
>
> @@ -124,9 +125,12 @@ is_user_addr_valid(struct task_struct *child, unsigned
> long start, unsigned long
> if (start + len < start)
> return -EIO;
>
> + down_read(>mm->mmap_sem);
> vma = find_vma(child->mm, start);
> - if (vma && start >= vma->vm_start && start + len <= vma->vm_end)
> - return 0;
> + valid = vma && start >= vma->vm_start && start + len <= vma->vm_end;
> + up_read(>mm->mmap_sem);
> + if (valid)
> + return 0;
>
> for (sraml = child->mm->context.sram_list; sraml; sraml = sraml->next)
> if (start >= (unsigned long)sraml->addr
> --
> 1.8.1.4
>
-steven
--
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 v3 2/2] dt: platform driver: Fill the resources before probe and defer if needed
* Tony Lindgren [140421 13:26]: > * Rob Herring [140421 12:01]: > > On Mon, Apr 21, 2014 at 10:54 AM, Tony Lindgren wrote: > > > * Rob Herring [140421 06:47]: > > >> On Fri, Apr 18, 2014 at 6:24 PM, Tony Lindgren wrote: > > >> > * Russell King - ARM Linux [140418 16:04]: > > >> >> On Fri, Apr 18, 2014 at 02:58:48PM -0700, Tony Lindgren wrote: > > >> >> > Oh come on, let's stop pretending it's not broken. And it's way > > >> >> > worse with > > >> >> > device tree as there's nothing making sure the resources for a > > >> >> > driver > > >> >> > are set up before the driver probes. And we've been unable to fix > > >> >> > just > > >> >> > this issue alone for about six months now. It's also broken beyond > > >> >> > that. > > >> >> > It's called of_platform_bus yet it won't even pass the platform_data > > >> >> > as auxdata to the devices on a sub-bus instantatiated like I2C. > > >> >> > > >> >> Isn't there a much simpler solution to the platform device IRQ > > >> >> problem? > > >> >> > > >> >> Rather than trying to fix it at the point where the resources are > > >> >> created, why not just *not* have DT create the IRQ resources in the > > >> >> first place, and instead have platform_get_irq() (which is the > > >> >> function > > >> >> which should be used to get an IRQ) be the actor to do whatever is > > >> >> necessary to return the IRQ(s) ? > > >> > > > >> > Yeah why not. I don't see why we would need to do all this of_* special > > >> > trickery for much anything beyond parsing the binding. > > >> > > >> That can work, but it will still need something like > > >> of_find_irq_domain() to determine whether to return -EPROBE_DEFER or > > >> not. > > > > > > Right. Naturally let's do whatever it takes to first fix this issue > > > in a minimal way first for the -rc cycle so we can do the longer term > > > changes needed. > > > > I'm not really convinced there is a simple and safe enough solution for > > 3.15. We should also be willing to tag a solution for stable if we take > > it for -rc (although that decision could be deferred). > > Yes the fix needs to also go to stable. And this is a regression > between legacy booting and DT based booting so we do have good > reasons to fix this for the -rc cycle. Who knows how many people are > hitting this and are tinkering with the driver initcall levels to > work around it. Ideally the fix, even if intrusive, would already > get us a little bit into the right direction. > > > >> You could also go in the other direction and don't create the device > > >> until the resources can be resolved. Unlike any of the other > > >> solutions, that would work for amba bus as well although we may never > > >> have a case where we need this with the amba bus. This would require > > >> making of_platform_populate be callable multiple times, but there are > > >> already some other reasons for wanting to do that. Specifically, I > > >> would like the core code to call of_platform_populate with default > > >> options and then only platforms with non-default options need a call > > >> to of_platform_populate. > > > > > > I like this idea as this would also probably remove the the numerous > > > dmesg errors we are currently getting for drivers reprobing with > > > -EPROBE_DEFER. > > > > One issue with my proposal is with supporting modules. IIUC, deferred > > probe will continue trying forever and loading modules can cause probe > > to succeed. If devices are not created and on the deferred probe list, > > then they will not get probed when a module load fixes the dependency. > > > > > In the long term we should have platform bus just call a set of > > > standardized functions implemented by whatever the data source might > > > be. That way we can limit the use of of_* functions in device drivers > > > to just parsing of custom bindings in the drivers and use bus specific > > > functions for everything else. > > > > > >> >> Yes, I know we have some drivers which use platform_get_resources() > > >> >> with > > >> >> IORESOURCE_IRQ, but they should really use the right accessor. And > > >> >> those > > >> >> who just dereference the resource array directly... get what's coming > > >> >> (though of course they have to be fixed.) > > >> > > > >> > $ git grep IORESOURCE_IRQ drivers/ | grep platform_get_resource | wc -l > > >> > 179 > > >> > > >> Certainly, this is worthwhile clean-up no matter what the solution. > > > > > > Yeah agreed. But let's also consider the IORESOURCE_IRQ as just another > > > source for for the bus or driver data in addition to the DT parsed data. > > > Both sources of data should work just fine with platform_bus even > > > without cleaning up the drivers > > > > Ah, right. Except for those drivers you need to work with deferred probe > > would have to use platform_get_irq. That fact makes this solution quite > > a bit easier. > > Yes fixing up the known broken drivers is also doable for the -rc > cycle. > > > Something like this is what
Re: [PATCH] Save PG_head_mask in VMCOREINFO
On 04/11/14 at 05:50pm, Petr Tesarik wrote: > To allow filtering of huge pages, makedumpfile must be able to > identify them in the dump. This can be done by checking the > appropriate page flag, so communicate its value to makedumpfile > through the VMCOREINFO interface. > > There's only one small catch. Depending on how many page flags > are available on a given architecture, this bit can be called > PG_head or PG_compound. > > I sent a similar patch back in 2012, but Eric Biederman did not > like using an #ifdef. So, this time I'm adding a common symbol > (PG_head_mask) instead. > > See https://lkml.org/lkml/2012/11/28/91 for the previous version. > > Signed-off-by: Petr Tesarik > --- > include/linux/page-flags.h | 3 +++ > kernel/kexec.c | 1 + > 2 files changed, 4 insertions(+) > > diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h > index d1fe1a7..bc2007e 100644 > --- a/include/linux/page-flags.h > +++ b/include/linux/page-flags.h > @@ -348,6 +348,9 @@ static inline void ClearPageCompound(struct page > *page) ClearPageHead(page); > } > #endif > + > +#define PG_head_mask ((1L << PG_head)) Hi Petr, I am fine with this trick which define one name PG_head_mask, but can stands for both PG_head and PG_compound. I guess Eric may suggest the implementation like it done in mm/memory-failure.c . In that file it explicitly defines both of them. Thanks Baoquan > + > #else > /* > * Reduce page flag use as much as possible by overlapping > diff --git a/kernel/kexec.c b/kernel/kexec.c > index c8380ad..e6f3aec 100644 > --- a/kernel/kexec.c > +++ b/kernel/kexec.c > @@ -1622,6 +1622,7 @@ static int __init crash_save_vmcoreinfo_init(void) > #ifdef CONFIG_MEMORY_FAILURE > VMCOREINFO_NUMBER(PG_hwpoison); > #endif > + VMCOREINFO_NUMBER(PG_head_mask); > VMCOREINFO_NUMBER(PAGE_BUDDY_MAPCOUNT_VALUE); > > arch_crash_save_vmcoreinfo(); > -- > 1.8.4.5 > > ___ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec -- 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] cpuidle: governor: menu: move repeated correction factor check to init
ping
On 10 April 2014 19:57, Tuukka Tikkanen wrote:
> On 10 April 2014 16:43, Chander Kashyap wrote:
>> In menu_select function we check for correction factor every time.
>> If it is zero we are initializing to unity. Hence move it to init function
>> and initialise by unity, hence avoid repeated comparisons.
>>
>> Signed-off-by: Chander Kashyap
>> ---
>> drivers/cpuidle/governors/menu.c | 15 ---
>> 1 file changed, 8 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/cpuidle/governors/menu.c
>> b/drivers/cpuidle/governors/menu.c
>> index cf7f2f0..048f6d9 100644
>> --- a/drivers/cpuidle/governors/menu.c
>> +++ b/drivers/cpuidle/governors/menu.c
>> @@ -315,13 +315,6 @@ static int menu_select(struct cpuidle_driver *drv,
>> struct cpuidle_device *dev)
>> multiplier = performance_multiplier();
>>
>> /*
>> -* if the correction factor is 0 (eg first time init or cpu hotplug
>> -* etc), we actually want to start out with a unity factor.
>> -*/
>> - if (data->correction_factor[data->bucket] == 0)
>> - data->correction_factor[data->bucket] = RESOLUTION * DECAY;
>> -
>> - /*
>> * Force the result of multiplication to be 64 bits even if both
>> * operands are 32 bits.
>> * Make sure to round up for half microseconds.
>> @@ -453,9 +446,17 @@ static int menu_enable_device(struct cpuidle_driver
>> *drv,
>> struct cpuidle_device *dev)
>> {
>> struct menu_device *data = _cpu(menu_devices, dev->cpu);
>> + int i;
>>
>> memset(data, 0, sizeof(struct menu_device));
>>
>> + /*
>> +* if the correction factor is 0 (eg first time init or cpu hotplug
>> +* etc), we actually want to start out with a unity factor.
>> +*/
>> + for(i = 0; i < BUCKETS; i++)
>> + data->correction_factor[i] = RESOLUTION * DECAY;
>> +
>> return 0;
>> }
>>
>> --
>> 1.7.9.5
>>
>
> Reviewed-by: Tuukka Tikkanen
--
with warm regards,
Chander Kashyap
--
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,rcu] 9234566d3a3: +1.6% will-it-scale.scalability, +1302.6% time.involuntary_context_switches
On 04/22/2014 09:59 AM, Paul E. McKenney wrote:
On Mon, Apr 21, 2014 at 02:28:21PM +0800, Jet Chen wrote:
Hi Paul,
we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
torture.2014.04.18a
commit 9234566d3a36c0aead8852e3c2ca94cd8ebfe219 ("sched,rcu: Make cond_resched()
report RCU quiescent states")
My impression of these statistics is that this commit results in huge
numbers of additional context switches and interrupts, but has a slightly
positive effect on performance and a larger negative effect on
scalability.
Is this a reasonable interpretation?
Yes, you're right.
Thanx, Paul
Comparison 1 - parent commit of 9234566d3a36c0aead8852e3c2ca94cd8ebfe219 vs
9234566d3a36c0aead8852e3c2ca94cd8ebfe219
e119454e74a852f 9234566d3a36c0aead8852e3c
--- -
1035948 ~ 0% +1.6%1052990 ~ 0% TOTAL will-it-scale.per_thread_ops
1271322 ~ 0% +1.8%1294004 ~ 0% TOTAL
will-it-scale.per_process_ops
0.63 ~ 0% -5.2% 0.60 ~ 0% TOTAL will-it-scale.scalability
22470 ~ 2% +1302.6% 315168 ~ 2% TOTAL
time.involuntary_context_switches
84265 ~ 5% +1047.1% 966581 ~ 1% TOTAL interrupts.IWI
1828 ~44%+189.6% 5295 ~13% TOTAL
time.voluntary_context_switches
5337 ~ 1% +82.1% 9720 ~ 1% TOTAL vmstat.system.cs
118599 ~ 0% -30.4% 82545 ~ 0% TOTAL
interrupts.0:IO-APIC-edge.timer
224021 ~ 4% +34.7% 301858 ~ 2% TOTAL interrupts.RES
25148 ~ 0% +7.0% 26917 ~ 0% TOTAL vmstat.system.in
7063439 ~ 0% -5.2%6694536 ~ 0% TOTAL interrupts.LOC
188866 ~ 0% -3.1% 183008 ~ 0% TOTAL interrupts.NMI
188866 ~ 0% -3.1% 183008 ~ 0% TOTAL interrupts.PMI
3720 ~ 0% -1.5% 3665 ~ 0% TOTAL time.system_time
1215 ~ 0% -1.4% 1198 ~ 0% TOTAL
time.percent_of_cpu_this_job_got
Comparison 2 - b84c4e08143c98dad4b4d139f08db0b98b0d3ec4 vs
9234566d3a36c0aead8852e3c2ca94cd8ebfe219
Fengguang has reported stats changes about
b84c4e08143c98dad4b4d139f08db0b98b0d3ec4 to you days ago.
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
dev.2014.04.14a
commit b84c4e08143c98dad4b4d139f08db0b98b0d3ec4 ("sched,rcu: Make cond_resched()
report RCU quiescent states")
Let's have a compare here.
b84c4e08143c98d 9234566d3a36c0aead8852e3c
--- -
809309 ~ 0% -2.6% 788400 ~ 0% TOTAL
will-it-scale.per_process_ops
0.61 ~ 0% -1.9% 0.60 ~ 0% TOTAL will-it-scale.scalability
434080 ~ 0% -1.5% 427643 ~ 0% TOTAL will-it-scale.per_thread_ops
4 ~11% +1.2e+05% 5249 ~ 2% TOTAL interrupts.IWI
607 ~ 7% +28.0%778 ~14% TOTAL
interrupts.47:PCI-MSI-edge.eth0
12349 ~ 2% -14.6% 10548 ~ 1% TOTAL
interrupts.0:IO-APIC-edge.timer
3078 ~ 3% +20.9% 3722 ~ 6% TOTAL interrupts.RES
Comparison 3 - parent commit of b84c4e08143c98dad4b4d139f08db0b98b0d3ec4 vs
b84c4e08143c98dad4b4d139f08db0b98b0d3ec4
Duplicated with Fengguang's report. Help you to see these info in a page :)
ad86a04266f9b49 b84c4e08143c98dad4b4d139f
--- -
676264 ~ 0% +3.3% 698461 ~ 0% TOTAL will-it-scale.per_thread_ops
1174547 ~ 0% +3.0%1209307 ~ 0% TOTAL
will-it-scale.per_process_ops
1.67 ~ 0% -2.3% 1.63 ~ 0% TOTAL will-it-scale.scalability
10522 ~ 2%+921.2% 107463 ~ 1% TOTAL
time.involuntary_context_switches
77671 ~ 3% +67.0% 129688 ~ 3% TOTAL interrupts.RES
99502 ~ 0% -27.8% 71813 ~ 0% TOTAL
interrupts.0:IO-APIC-edge.timer
2554 ~ 0% +49.1% 3809 ~ 1% TOTAL vmstat.system.cs
11524 ~ 0% -2.3% 11259 ~ 0% TOTAL vmstat.system.in
213 ~ 0% -4.3%204 ~ 0% TOTAL time.system_time
74 ~ 0% -4.1% 71 ~ 0% TOTAL
time.percent_of_cpu_this_job_got
3495099 ~ 0% -3.1%3387173 ~ 0% TOTAL interrupts.LOC
Thanks,
Jet
./runtest.py open2 32 1 4 6 8
--
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.15.0-rc2 radeon HD 7480D [Aruba] blank display
On Tue, Apr 22, 2014 at 03:31:06AM +0100, Ken Moffat wrote: [ resending, somehow lkml dropped out of the Cc. ] > On Tue, Apr 22, 2014 at 12:19:40AM +0100, Ken Moffat wrote: > > On Mon, Apr 21, 2014 at 05:29:27PM -0400, Ed Tomlinson wrote: > > > > Ken, > > > > > > You might want to try reverting: > > > > > > commit 379dfc25e257ffe10eb53b86d2375f7c0f4f33ef > > > Author: Alex Deucher > > > Date: Mon Apr 7 10:33:46 2014 -0400 > > > > > > drm/radeon/dp: switch to the common i2c over aux code > > > > > > Provides a nice cleanup in radeon. > > > > > > Signed-off-by: Alex Deucher > > > Signed-off-by: Christian König > > > > > > This fixed a similar problem here (see the drm pull thread for rc1) > > > > > > Thanks > > > Ed Tomlinson > > > > Tried reverting that from rc2, but it didn't help. Thanks anyway. > > > > Well, I *believed* I had created a patch for that commit, and > reverted it from -rc2 with patch -R. But I've now bisected through > drivers/gpu/drm between v3.14.0 and v3.15-rc2 and the bisection > pointed to that same commit, so I guess I did something wrong. > > There were a couple of other issues along the way (mounting nfs > hung on one commit, startx hung on several of the commits, but I've > marked those as "good" because I had a display, even if the system > was not usable). > > I've now gone back to linus' tree that I cloned a few hours ago, > i.e. > commit c089b229dfdd09d59a11d8bc2344bf8196d575ce > Merge: 9ac03675010a 0565103d1adb > Author: Linus Torvalds > Date: Mon Apr 21 10:05:35 2014 -0700 > > Merge branch 'for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml > > created a branch, and *definitely* reverted > 379dfc25e257ffe10eb53b86d2375f7c0f4f33ef (using git revert) in that > branch. And this version works fine. > > So belatedly I see that I seem to have the same problem as Ed. Or > at least that the same commit is causing both our problems. > > Alex - do you need any more information from me to help with this ? > > ĸen > -- > das eine Mal als Tragödie, dieses Mal als Farce -- das eine Mal als Tragödie, dieses Mal als Farce -- 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: [Nouveau] [PATCH v2 09/10] drm/nouveau: support GK20A in nouveau_accel_init()
On 04/22/2014 03:07 AM, Ilia Mirkin wrote:
On Mon, Apr 21, 2014 at 2:02 AM, Alexandre Courbot wrote:
Skip the creation of a software channel for GK20A as software methods
are not yet supported.
How is GK20A different from a nvc0+ card that lacks PDISPLAY (like all
the 3D Controller ones, and I guess even some that come up as VGA
controller in PCI but don't have any outputs in their VBIOS)? i.e.
what's wrong with just doing the same thing that GK1xx does? Note that
there are sw methods that don't deal with display as well.
Well, as it turns out... I have tried reverting this patch and enabling
nvc0_software_oclass for GK20A and things worked like a charm. 0_o
This is definitely different from when I first drafted this patch
series, where a software class could not be used on GK20A due to hard
dependencies on display. But it seems like today's code can accommodate
much better with that situation.
That's great - this will allow us to get rid of this ungraceful patch.
Thanks for making me check it again.
Probably a v3 will be necessary to enable the software class in patch 10
(and fix the byte/word typo in patch 7). I will just wait a bit to see
if this v2 gets more comments before sending it.
-ilia
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index ddd83756b9a2..5b46148ffd32 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -208,6 +208,10 @@ nouveau_accel_init(struct nouveau_drm *drm)
return;
}
+ /* Need to figure out how to handle sw for gk20a */
+ if (device->chipset == 0xea)
+ goto skip_sw_init;
+
ret = nouveau_object_new(nv_object(drm), NVDRM_CHAN, NVDRM_NVSW,
nouveau_abi16_swclass(drm), NULL, 0, );
if (ret == 0) {
@@ -234,6 +238,7 @@ nouveau_accel_init(struct nouveau_drm *drm)
return;
}
+skip_sw_init:
if (device->card_type < NV_C0) {
ret = nouveau_gpuobj_new(drm->device, NULL, 32, 0, 0,
>notify);
--
1.9.2
___
Nouveau mailing list
nouv...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
--
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 v5 1/2] Use lock_device_hotplug() in cpu_probe_store() and cpu_release_store()
On Mon, 2014-04-21 at 18:38 -0400, Tejun Heo wrote: > Hello, > > On Mon, Apr 21, 2014 at 05:20:59PM +0800, Li Zhong wrote: > > While auditing the usage of lock_device_hotplug_sysfs() for implementing > > it in another way in following patch, it seems to me that the code here > > is to add/remove device, and the files probe/release for cpu bus > > themselves won't be removed. > > > > So it seems to me there is no s_active related deadlock here, and we > > could just use lock_device_hotplug(). > > It may still cause issue if offlining ends up removing sysfs files or > gets involved with the same lock used during cpu hot[un]plug > operations (e.g. offlining racing against cpu hotunplug) and offlining > a cpu does remove files. Has this change been tested? The probe/release files are attribute files for cpu subsys, looks like following in sysfs dirs $ cd /sys/devices/system/cpu/ $ ls -l total 0 drwxr-xr-x. 7 root root 0 Apr 17 19:00 cpu0 drwxr-xr-x. 4 root root 0 Apr 17 19:00 cpu1 drwxr-xr-x. 4 root root 0 Apr 17 19:00 cpu10 .. drwxr-xr-x. 3 root root 0 Apr 20 08:00 cpufreq drwxr-xr-x. 2 root root 0 Apr 20 08:00 cpuidle -rw---. 1 root root 65536 Apr 21 00:28 dscr_default -r--r--r--. 1 root root 65536 Apr 21 00:28 kernel_max -r--r--r--. 1 root root 65536 Apr 21 00:28 offline -r--r--r--. 1 root root 65536 Sep 4 2014 online -r--r--r--. 1 root root 65536 Apr 21 00:28 possible drwxr-xr-x. 2 root root 0 Apr 20 08:00 power -r--r--r--. 1 root root 65536 Apr 17 20:46 present --w---. 1 root root 65536 Apr 21 00:28 probe<- --w---. 1 root root 65536 Apr 21 00:28 release <- -rw---. 1 root root 65536 Apr 21 00:28 subcores_per_core -rw-r--r--. 1 root root 65536 Apr 21 00:28 uevent >From the code, it seems cpu subsys won't be unregistered, and it doesn't make sense to remove all the cpus in the system. Thanks, Zhong > > 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 v3] ARM: perf: save/restore pmu registers in pm notifier
> -Original Message-
> From: Neil Zhang [mailto:zhan...@marvell.com]
> Sent: 2014年4月21日 19:09
> To: will.dea...@arm.com; li...@arm.linux.org.uk
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Neil
> Zhang; Sudeep KarkadaNagesha
> Subject: [PATCH v3] ARM: perf: save/restore pmu registers in pm notifier
>
> This adds core support for saving and restoring CPU PMU registers for
> suspend/resume support i.e. deeper C-states in cpuidle terms.
> This patch adds support only to ARMv7 PMU registers save/restore.
> It needs to be extended to xscale and ARMv6 if needed.
>
> I make this patch because of DS-5 not work on our CA7 based SoCs.
> And it is based on Sudeep KarkadaNagesha's patch set for multiple PMUs.
>
> Thanks Will and Sudeep's suggestion to only save / restore used events.
>
> Cc: Sudeep KarkadaNagesha
> Signed-off-by: Neil Zhang
> ---
> arch/arm/include/asm/pmu.h |4 ++
> arch/arm/kernel/perf_event.c |2 +
> arch/arm/kernel/perf_event_cpu.c | 28 ++
> arch/arm/kernel/perf_event_v7.c | 75
> ++
> 4 files changed, 109 insertions(+)
>
> diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
> index ae1919b..3de3db7 100644
> --- a/arch/arm/include/asm/pmu.h
> +++ b/arch/arm/include/asm/pmu.h
> @@ -83,6 +83,10 @@ struct arm_pmu {
> int (*request_irq)(struct arm_pmu *, irq_handler_t handler);
> void(*free_irq)(struct arm_pmu *);
> int (*map_event)(struct perf_event *event);
> + int (*register_pm_notifier)(struct arm_pmu *);
> + void(*unregister_pm_notifier)(struct arm_pmu *);
> + void(*save_regs)(struct arm_pmu *);
> + void(*restore_regs)(struct arm_pmu *);
> int num_events;
> atomic_tactive_events;
> struct mutexreserve_mutex;
> diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
> index a6bc431..08822de 100644
> --- a/arch/arm/kernel/perf_event.c
> +++ b/arch/arm/kernel/perf_event.c
> @@ -326,6 +326,7 @@ static void
> armpmu_release_hardware(struct arm_pmu *armpmu) {
> armpmu->free_irq(armpmu);
> + armpmu->unregister_pm_notifier(armpmu);
> pm_runtime_put_sync(>plat_device->dev);
> }
>
> @@ -339,6 +340,7 @@ armpmu_reserve_hardware(struct arm_pmu
> *armpmu)
> return -ENODEV;
>
> pm_runtime_get_sync(_device->dev);
> + armpmu->register_pm_notifier(armpmu);
> err = armpmu->request_irq(armpmu, armpmu_dispatch_irq);
> if (err) {
> armpmu_release_hardware(armpmu);
> diff --git a/arch/arm/kernel/perf_event_cpu.c
> b/arch/arm/kernel/perf_event_cpu.c
> index 51798d7..79e1c06 100644
> --- a/arch/arm/kernel/perf_event_cpu.c
> +++ b/arch/arm/kernel/perf_event_cpu.c
> @@ -19,6 +19,7 @@
> #define pr_fmt(fmt) "CPU PMU: " fmt
>
> #include
> +#include
> #include
> #include
> #include
> @@ -173,6 +174,31 @@ static int cpu_pmu_request_irq(struct arm_pmu
> *cpu_pmu, irq_handler_t handler)
> return 0;
> }
>
> +static int cpu_pmu_pm_notify(struct notifier_block *b,
> + unsigned long action, void *v)
> +{
> + if (action == CPU_PM_ENTER && cpu_pmu->save_regs)
> + cpu_pmu->save_regs(cpu_pmu);
> + else if (action == CPU_PM_EXIT && cpu_pmu->restore_regs)
> + cpu_pmu->restore_regs(cpu_pmu);
> +
> + return NOTIFY_OK;
> +}
> +
> +static struct notifier_block cpu_pmu_pm_notifier = {
> + .notifier_call = cpu_pmu_pm_notify,
> +};
> +
> +static int cpu_pmu_register_pm_notifier(struct arm_pmu *cpu_pmu) {
> + return cpu_pm_register_notifier(_pmu_pm_notifier);
> +}
> +
> +static void cpu_pmu_unregister_pm_notifier(struct arm_pmu *cpu_pmu) {
> + cpu_pm_unregister_notifier(_pmu_pm_notifier);
> +}
> +
> static void cpu_pmu_init(struct arm_pmu *cpu_pmu) {
> int cpu;
> @@ -187,6 +213,8 @@ static void cpu_pmu_init(struct arm_pmu *cpu_pmu)
> cpu_pmu->get_hw_events = cpu_pmu_get_cpu_events;
> cpu_pmu->request_irq= cpu_pmu_request_irq;
> cpu_pmu->free_irq = cpu_pmu_free_irq;
> + cpu_pmu->register_pm_notifier = cpu_pmu_register_pm_notifier;
> + cpu_pmu->unregister_pm_notifier = cpu_pmu_unregister_pm_notifier;
>
> /* Ensure the PMU has sane values out of reset. */
> if (cpu_pmu->reset)
> diff --git a/arch/arm/kernel/perf_event_v7.c
> b/arch/arm/kernel/perf_event_v7.c index f4ef398..8898b4d 100644
> --- a/arch/arm/kernel/perf_event_v7.c
> +++ b/arch/arm/kernel/perf_event_v7.c
> @@ -1237,6 +1237,79 @@ static void armv7_pmnc_dump_regs(struct
> arm_pmu *cpu_pmu) } #endif
>
> +struct armv7_pmuregs {
> + u32 pmc;
> + u32 pmcntenset;
> + u32 pmuseren;
> + u32 pmintenset;
> + u32 pmxevttype[8];
> + u32 pmxevtcnt[8];
> +};
> +
> +static DEFINE_PER_CPU(struct armv7_pmuregs, pmu_regs);
> +
> +static void
[PATCH v4] ARM: perf: save/restore pmu registers in pm notifier
This adds core support for saving and restoring CPU PMU registers
for suspend/resume support i.e. deeper C-states in cpuidle terms.
This patch adds support only to ARMv7 PMU registers save/restore.
It needs to be extended to xscale and ARMv6 if needed.
I made this patch because DS-5 is not working on Marvell's CA7 based SoCs.
And it has consulted Sudeep KarkadaNagesha's patch set for multiple PMUs.
Thanks Will and Sudeep's suggestion to only save / restore used events.
Cc: Sudeep KarkadaNagesha
Signed-off-by: Neil Zhang
---
arch/arm/include/asm/pmu.h |4 +++
arch/arm/kernel/perf_event.c |2 ++
arch/arm/kernel/perf_event_cpu.c | 28 +++
arch/arm/kernel/perf_event_v7.c | 74 ++
4 files changed, 108 insertions(+)
diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
index ae1919b..3de3db7 100644
--- a/arch/arm/include/asm/pmu.h
+++ b/arch/arm/include/asm/pmu.h
@@ -83,6 +83,10 @@ struct arm_pmu {
int (*request_irq)(struct arm_pmu *, irq_handler_t handler);
void(*free_irq)(struct arm_pmu *);
int (*map_event)(struct perf_event *event);
+ int (*register_pm_notifier)(struct arm_pmu *);
+ void(*unregister_pm_notifier)(struct arm_pmu *);
+ void(*save_regs)(struct arm_pmu *);
+ void(*restore_regs)(struct arm_pmu *);
int num_events;
atomic_tactive_events;
struct mutexreserve_mutex;
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index a6bc431..08822de 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -326,6 +326,7 @@ static void
armpmu_release_hardware(struct arm_pmu *armpmu)
{
armpmu->free_irq(armpmu);
+ armpmu->unregister_pm_notifier(armpmu);
pm_runtime_put_sync(>plat_device->dev);
}
@@ -339,6 +340,7 @@ armpmu_reserve_hardware(struct arm_pmu *armpmu)
return -ENODEV;
pm_runtime_get_sync(_device->dev);
+ armpmu->register_pm_notifier(armpmu);
err = armpmu->request_irq(armpmu, armpmu_dispatch_irq);
if (err) {
armpmu_release_hardware(armpmu);
diff --git a/arch/arm/kernel/perf_event_cpu.c b/arch/arm/kernel/perf_event_cpu.c
index 51798d7..79e1c06 100644
--- a/arch/arm/kernel/perf_event_cpu.c
+++ b/arch/arm/kernel/perf_event_cpu.c
@@ -19,6 +19,7 @@
#define pr_fmt(fmt) "CPU PMU: " fmt
#include
+#include
#include
#include
#include
@@ -173,6 +174,31 @@ static int cpu_pmu_request_irq(struct arm_pmu *cpu_pmu,
irq_handler_t handler)
return 0;
}
+static int cpu_pmu_pm_notify(struct notifier_block *b,
+ unsigned long action, void *v)
+{
+ if (action == CPU_PM_ENTER && cpu_pmu->save_regs)
+ cpu_pmu->save_regs(cpu_pmu);
+ else if (action == CPU_PM_EXIT && cpu_pmu->restore_regs)
+ cpu_pmu->restore_regs(cpu_pmu);
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block cpu_pmu_pm_notifier = {
+ .notifier_call = cpu_pmu_pm_notify,
+};
+
+static int cpu_pmu_register_pm_notifier(struct arm_pmu *cpu_pmu)
+{
+ return cpu_pm_register_notifier(_pmu_pm_notifier);
+}
+
+static void cpu_pmu_unregister_pm_notifier(struct arm_pmu *cpu_pmu)
+{
+ cpu_pm_unregister_notifier(_pmu_pm_notifier);
+}
+
static void cpu_pmu_init(struct arm_pmu *cpu_pmu)
{
int cpu;
@@ -187,6 +213,8 @@ static void cpu_pmu_init(struct arm_pmu *cpu_pmu)
cpu_pmu->get_hw_events = cpu_pmu_get_cpu_events;
cpu_pmu->request_irq= cpu_pmu_request_irq;
cpu_pmu->free_irq = cpu_pmu_free_irq;
+ cpu_pmu->register_pm_notifier = cpu_pmu_register_pm_notifier;
+ cpu_pmu->unregister_pm_notifier = cpu_pmu_unregister_pm_notifier;
/* Ensure the PMU has sane values out of reset. */
if (cpu_pmu->reset)
diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index f4ef398..9069310 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -1237,6 +1237,78 @@ static void armv7_pmnc_dump_regs(struct arm_pmu *cpu_pmu)
}
#endif
+struct armv7_pmuregs {
+ u32 pmc;
+ u32 pmcntenset;
+ u32 pmintenset;
+ u32 pmxevttype[8];
+ u32 pmxevtcnt[8];
+};
+
+static DEFINE_PER_CPU(struct armv7_pmuregs, pmu_regs);
+
+static void armv7pmu_reset(void *info);
+
+static void armv7pmu_save_regs(struct arm_pmu *cpu_pmu)
+{
+ struct pmu_hw_events *events = cpu_pmu->get_hw_events();
+ struct armv7_pmuregs *regs;
+ int bit;
+
+ /* Check whether there are events used */
+ bit = find_first_bit(events->used_mask, cpu_pmu->num_events);
+ if (bit >= cpu_pmu->num_events)
+ return;
+
+ regs = this_cpu_ptr(_regs);
+ for_each_set_bit(bit, events->used_mask, cpu_pmu->num_events) {
+
[PATCH] tools lib traceevent: Fix backward compatibility macros for pevent filter enums
The return value for pevent_filter_match() is suppose to return FILTER_NONE
if the event doesn't have a filter, and FILTER_NOEXIST if there is no filter
at all. But the change 41e12e580a7 "tools lib traceevent: Refactor
pevent_filter_match() to get rid of die()" replaced the return value
with PEVENT_ERRNO__* values and added "backward compatibility" macros
that used the old names. Unfortunately, the NOEXIST and NONE macros were
swapped, and this broke users that use the old return names.
Signed-off-by: Steven Rostedt
---
tools/lib/traceevent/event-parse.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/lib/traceevent/event-parse.h
b/tools/lib/traceevent/event-parse.h
index 9c38181..d6c610a 100644
--- a/tools/lib/traceevent/event-parse.h
+++ b/tools/lib/traceevent/event-parse.h
@@ -886,8 +886,8 @@ struct event_filter {
struct event_filter *pevent_filter_alloc(struct pevent *pevent);
/* for backward compatibility */
-#define FILTER_NONEPEVENT_ERRNO__FILTER_NOT_FOUND
-#define FILTER_NOEXIST PEVENT_ERRNO__NO_FILTER
+#define FILTER_NONEPEVENT_ERRNO__NO_FILTER
+#define FILTER_NOEXIST PEVENT_ERRNO__FILTER_NOT_FOUND
#define FILTER_MISSPEVENT_ERRNO__FILTER_MISS
#define FILTER_MATCH PEVENT_ERRNO__FILTER_MATCH
--
1.8.1.4
--
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 V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
On Wednesday, April 16, 2014 11:49 PM, Vivek Gautam wrote: > On Wed, Apr 16, 2014 at 7:14 PM, Tomasz Figa wrote: > > On 15.04.2014 08:09, Vivek Gautam wrote: > >> On Thu, Apr 10, 2014 at 5:09 PM, Vivek Gautam wrote: > >>> On Wed, Apr 9, 2014 at 7:03 PM, Tomasz Figa wrote: > On 09.04.2014 13:49, Vivek Gautam wrote: > >>> > >>> So, USB30_SCLK_100M is the SCLK that we are talking in the driver. I > >>> don't see any reference to XXTI in the USB 3.0 DRD controller chapter > >>> (in both Exynos5250 and 5420) > >>> In addition to this there's one more point to be noticed here. > >>> On Exynos5420 system, the sclk_usbphy300 (which is the sclk_usbphy30 > >>> for USB DRD channel 0), is also the PICO phy clock, i.e. USB 2.0 phy > >>> clock. > >>> So we should add a similar clk_get() for this clock in the > >>> phy-exynos5250-usb2 driver too, to support Exynos5420. > >> > >> > >> Is something clear from the above block diagram ? (although the > >> diagram looks weird - space and tabs problem :-( ) > >> Basically there's the clock USB30_SCLK_100M which is going into the > >> USB 3.0 DRD PHY controller. > >> And this is the only sclk mentioned in the block diagram for USB 3.0 > >> DRD controller in Exynos5420. > >> Same is not there in the block diagram in Exynos5250 UM. > > > > > > From what I can see in the documentation, there are 4 USB 3.0 related clocks > > generated in CMU: > > > > - sclk_usbphy300, > > - sclk_usbphy301, > > - sclk_usbdrd300, > > - sclk_usbdrd301, > > > > They are all rated to max. 24 MHz and the recommended operating frequency is > > 24 MHz, so it looks exactly like USB PHY reference, which is usually a 24 > > MHz clock. > > > > To me, this looks like on Exynos5420 a separate special clock path is used > > instead of xusbxti as reference of USB 3.0 PHY and so the sclk should be > > simply passed as the "ref" clock. > > Ok, i will clear on this with the hardware engineer also once. > May be Jingoo can help me with this. > > Jingoo, > Can you please enquire about the clock path of usbphy30 reference > clocks on Exynos5420. > As mentioned by Tomasz above, we have sclk_usbphy300 and > sclk_usbphy301 as the reference clocks for USB3.0 DRD phy. *Also* > sclk_usbphy300 is used for Pico phy (which is the USb 2.0 phy used by > ehci/ohci controller on Exynos5420). > It will be of great help. Hi Vevek, Tomasz Long time no see. I asked USB S/W engineer and USB H/W engineer. There are two USB3.0 on Exynos5420; thus there are two sclks such as 'sclk_usbphy300 and sclk_usbphy301'. As Tomasz mentioned, 'sclk_usbphy300 and sclk_usbphy301' can be used instead of 'xusbxti' as reference of USB 3.0 PHY. However, on Exynos5420, "ONLY" 'sclk_usbphy300' can be used for USB2.0 pico phy. (so, '301' CANNOT support USB2.0 pico phy.) 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 v2 07/10] drm/nouveau/graph: pad firmware code at load time
On 04/22/2014 08:48 AM, Ben Skeggs wrote: On Tue, Apr 22, 2014 at 4:03 AM, Ilia Mirkin wrote: On Mon, Apr 21, 2014 at 2:02 AM, Alexandre Courbot wrote: Pad the microcode to a multiple of 0x40 bytes, otherwise firmware will bytes or u32's? From the code, I'm guessing the latter. (Similar concern about comment in the code.) fail to run from non-prepadded firmware files. Signed-off-by: Alexandre Courbot Reviewed-by: Thierry Reding --- drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c index e5b75f189988..013475c62986 100644 --- a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c +++ b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c @@ -894,6 +894,10 @@ nvc0_graph_init_fw(struct nvc0_graph_priv *priv, u32 fuc_base, nv_wr32(priv, fuc_base + 0x0188, i >> 6); nv_wr32(priv, fuc_base + 0x0184, code->data[i]); } + + /* code must be padded to 0x40 bytes */ + for (; i & 0x3f; i++) + nv_wr32(priv, fuc_base + 0x0184, 0); It's 256 bytes indeed. Fixed, 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 1/4] ACPICA: Add to remove mis-ordered inclusion of from .
Hi,
> > +#define ACPI_NATIVE_INTERFACE_HEADER
>
> This is not good.
>
> We don't do things like this in the kernel, because they are confusing and
> hard
> to debug if necessary, so please find a different way to make this work.
I use this extra header file to collect:
1. static inline OSL functions
2. divergences of prototypes that haven't been back ported to ACPICA.
This file is useful for ACPICA release automation.
There are the following concerns that lead to the use of this solution:
1. for this extra header file itself
A. The new header file is OSPM specific, thus it needn't be upstreamed to
ACPICA;
B. Since it needn't be upstreamed to ACPICA, ACPICA needn't determine the
name of this extra header;
C. It has to be the last file included by .
2. for the file that includes this extra header file
A. Currently there is no OSPM specific code in .
Thus I use a macro so that there is still no OSPM specific code in
and the name of the extra header can be determined by OSPM.
If you want another solution, is the following acceptable?
1. In
#define ACPI_INCLUDE_EXTRA_NATIVE_HEADER1
2. In <- this is an ACPICA header file,
#ifdef ACPI_INCLUDE_EXTRA_NATIVE_HEADER
#include
#endif
Note that in this solution, the name of the extra header file will be
determined by ACPICA.
> And the name aclinuxxf.h is not one of my favourite.
Since this file needn't be upstreamed into ACPICA, could you help to determine
it if the acextra.h was still not acceptable?
Thanks and best regards
-Lv
>
> Thanks!
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [sched,rcu] 9234566d3a3: +1.6% will-it-scale.scalability, +1302.6% time.involuntary_context_switches
On Mon, Apr 21, 2014 at 02:28:21PM +0800, Jet Chen wrote:
> Hi Paul,
>
> we noticed the below changes on
> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> torture.2014.04.18a
> commit 9234566d3a36c0aead8852e3c2ca94cd8ebfe219 ("sched,rcu: Make
> cond_resched() report RCU quiescent states")
My impression of these statistics is that this commit results in huge
numbers of additional context switches and interrupts, but has a slightly
positive effect on performance and a larger negative effect on
scalability.
Is this a reasonable interpretation?
Thanx, Paul
> Comparison 1 - parent commit of 9234566d3a36c0aead8852e3c2ca94cd8ebfe219 vs
> 9234566d3a36c0aead8852e3c2ca94cd8ebfe219
>
> e119454e74a852f 9234566d3a36c0aead8852e3c
> --- -
> 1035948 ~ 0% +1.6%1052990 ~ 0% TOTAL
> will-it-scale.per_thread_ops
> 1271322 ~ 0% +1.8%1294004 ~ 0% TOTAL
> will-it-scale.per_process_ops
>0.63 ~ 0% -5.2% 0.60 ~ 0% TOTAL will-it-scale.scalability
> 22470 ~ 2% +1302.6% 315168 ~ 2% TOTAL
> time.involuntary_context_switches
> 84265 ~ 5% +1047.1% 966581 ~ 1% TOTAL interrupts.IWI
>1828 ~44%+189.6% 5295 ~13% TOTAL
> time.voluntary_context_switches
>5337 ~ 1% +82.1% 9720 ~ 1% TOTAL vmstat.system.cs
> 118599 ~ 0% -30.4% 82545 ~ 0% TOTAL
> interrupts.0:IO-APIC-edge.timer
> 224021 ~ 4% +34.7% 301858 ~ 2% TOTAL interrupts.RES
> 25148 ~ 0% +7.0% 26917 ~ 0% TOTAL vmstat.system.in
> 7063439 ~ 0% -5.2%6694536 ~ 0% TOTAL interrupts.LOC
> 188866 ~ 0% -3.1% 183008 ~ 0% TOTAL interrupts.NMI
> 188866 ~ 0% -3.1% 183008 ~ 0% TOTAL interrupts.PMI
>3720 ~ 0% -1.5% 3665 ~ 0% TOTAL time.system_time
>1215 ~ 0% -1.4% 1198 ~ 0% TOTAL
> time.percent_of_cpu_this_job_got
>
>
> Comparison 2 - b84c4e08143c98dad4b4d139f08db0b98b0d3ec4 vs
> 9234566d3a36c0aead8852e3c2ca94cd8ebfe219
>
> Fengguang has reported stats changes about
> b84c4e08143c98dad4b4d139f08db0b98b0d3ec4 to you days ago.
> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> dev.2014.04.14a
> commit b84c4e08143c98dad4b4d139f08db0b98b0d3ec4 ("sched,rcu: Make
> cond_resched() report RCU quiescent states")
>
> Let's have a compare here.
>
> b84c4e08143c98d 9234566d3a36c0aead8852e3c
> --- -
> 809309 ~ 0% -2.6% 788400 ~ 0% TOTAL
> will-it-scale.per_process_ops
>0.61 ~ 0% -1.9% 0.60 ~ 0% TOTAL will-it-scale.scalability
> 434080 ~ 0% -1.5% 427643 ~ 0% TOTAL
> will-it-scale.per_thread_ops
> 4 ~11% +1.2e+05% 5249 ~ 2% TOTAL interrupts.IWI
> 607 ~ 7% +28.0%778 ~14% TOTAL
> interrupts.47:PCI-MSI-edge.eth0
> 12349 ~ 2% -14.6% 10548 ~ 1% TOTAL
> interrupts.0:IO-APIC-edge.timer
>3078 ~ 3% +20.9% 3722 ~ 6% TOTAL interrupts.RES
>
>
> Comparison 3 - parent commit of b84c4e08143c98dad4b4d139f08db0b98b0d3ec4 vs
> b84c4e08143c98dad4b4d139f08db0b98b0d3ec4
>
> Duplicated with Fengguang's report. Help you to see these info in a page :)
>
> ad86a04266f9b49 b84c4e08143c98dad4b4d139f
> --- -
> 676264 ~ 0% +3.3% 698461 ~ 0% TOTAL
> will-it-scale.per_thread_ops
> 1174547 ~ 0% +3.0%1209307 ~ 0% TOTAL
> will-it-scale.per_process_ops
>1.67 ~ 0% -2.3% 1.63 ~ 0% TOTAL will-it-scale.scalability
> 10522 ~ 2%+921.2% 107463 ~ 1% TOTAL
> time.involuntary_context_switches
> 77671 ~ 3% +67.0% 129688 ~ 3% TOTAL interrupts.RES
> 99502 ~ 0% -27.8% 71813 ~ 0% TOTAL
> interrupts.0:IO-APIC-edge.timer
>2554 ~ 0% +49.1% 3809 ~ 1% TOTAL vmstat.system.cs
> 11524 ~ 0% -2.3% 11259 ~ 0% TOTAL vmstat.system.in
> 213 ~ 0% -4.3%204 ~ 0% TOTAL time.system_time
> 74 ~ 0% -4.1% 71 ~ 0% TOTAL
> time.percent_of_cpu_this_job_got
> 3495099 ~ 0% -3.1%3387173 ~ 0% TOTAL interrupts.LOC
>
>
>
>
> Thanks,
> Jet
>
>
>
> ./runtest.py open2 32 1 4 6 8
>
>
--
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: [Nouveau] [PATCH v2 09/10] drm/nouveau: support GK20A in nouveau_accel_init()
On Tue, Apr 22, 2014 at 4:07 AM, Ilia Mirkin wrote:
> On Mon, Apr 21, 2014 at 2:02 AM, Alexandre Courbot
> wrote:
>> Skip the creation of a software channel for GK20A as software methods
>> are not yet supported.
>
> How is GK20A different from a nvc0+ card that lacks PDISPLAY (like all
> the 3D Controller ones, and I guess even some that come up as VGA
> controller in PCI but don't have any outputs in their VBIOS)? i.e.
> what's wrong with just doing the same thing that GK1xx does? Note that
> there are sw methods that don't deal with display as well.
The mp_control() methods are the only ones I see, and, in my opinion,
they should really have been implemented using reserved methods on a
graphics class, and *not* in a purely software object.. If we need
them on GK20A too, we should reimplement them in gr, and bump the
minor version number so userspace knows.
Ben.
>
> -ilia
>
>>
>> Signed-off-by: Alexandre Courbot
>> ---
>> drivers/gpu/drm/nouveau/nouveau_drm.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
>> b/drivers/gpu/drm/nouveau/nouveau_drm.c
>> index ddd83756b9a2..5b46148ffd32 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
>> @@ -208,6 +208,10 @@ nouveau_accel_init(struct nouveau_drm *drm)
>> return;
>> }
>>
>> + /* Need to figure out how to handle sw for gk20a */
>> + if (device->chipset == 0xea)
>> + goto skip_sw_init;
>> +
>> ret = nouveau_object_new(nv_object(drm), NVDRM_CHAN, NVDRM_NVSW,
>> nouveau_abi16_swclass(drm), NULL, 0,
>> );
>> if (ret == 0) {
>> @@ -234,6 +238,7 @@ nouveau_accel_init(struct nouveau_drm *drm)
>> return;
>> }
>>
>> +skip_sw_init:
>> if (device->card_type < NV_C0) {
>> ret = nouveau_gpuobj_new(drm->device, NULL, 32, 0, 0,
>> >notify);
>> --
>> 1.9.2
>>
>> ___
>> Nouveau mailing list
>> nouv...@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/nouveau
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
--
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: [rcu] 10a94227ba2: -2.0% will-it-scale.per_process_ops
On Sat, Apr 19, 2014 at 04:26:22PM +0800, Fengguang Wu wrote:
> Paul,
>
> FYI, we noticed the below changes on
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> next.2014.04.16b
> commit 10a94227ba229f1b05672754dc318a8fe7982c95 ("rcu: Update
> cpu_needs_another_gp() for futures from non-NOCB CPUs")
>
> test case: nhm4/micro/will-it-scale/lseek1
>
> 11ba5ab363b9359 10a94227ba229f1b05672754d
> --- -
> 11210675 ~ 0% -2.0% 10985451 ~ 0% TOTAL
> will-it-scale.per_process_ops
> 1.24 ~ 5% -33.4% 0.83 ~ 5% TOTAL
> perf-profile.cpu-cycles.trace_hardirqs_off_caller.lseek64
> 3.88 ~ 2% +49.0% 5.79 ~ 0% TOTAL
> perf-profile.cpu-cycles.trace_hardirqs_on_thunk.lseek64
>295 ~16% +27.0%375 ~ 8% TOTAL cpuidle.C1E-NHM.usage
> 45061 ~ 2% +16.7% 52590 ~ 2% TOTAL cpuidle.C6-NHM.usage
> 1.21 ~ 4% +5.8% 1.28 ~ 4% TOTAL
> perf-profile.cpu-cycles.shmem_file_llseek.sys_lseek.system_call_fastpath.lseek64
> 4206 ~ 1% -78.6%900 ~ 8% TOTAL interrupts.IWI
> 14303 ~ 1% +26.7% 18120 ~ 1% TOTAL
> interrupts.0:IO-APIC-edge.timer
> 3228 ~ 4% -17.2% 2672 ~ 6% TOTAL interrupts.RES
>182 ~ 2% -8.1%167 ~ 3% TOTAL time.user_time
>235 ~ 2% +6.2%250 ~ 2% TOTAL time.system_time
> 379471 ~ 0% +1.2% 384127 ~ 0% TOTAL interrupts.LOC
>
> Legend:
> ~XX%- stddev percent
> [+-]XX% - change percent
>
> It does effectively eliminate interrupts.IWI:
>
>interrupts.IWI
>
>4500 ++-*-*---*--+
> |.. *. + .*. .*..*. .*..*..*.. .*..*..*..*.*..*..*
>4000 *+ *. *. *. *.. .*..*. |
>3500 ++ *|
> | |
>3000 ++ |
>2500 ++ |
> | |
>2000 ++ |
>1500 ++ |
> | |
>1000 ++ O O O OO O O
> 500 ++ O |
> | |
> 0 O+-O--O--O-O--O--O--O--O--O-O--O--O--O--O--O-O--+
>
>
> [*] bisect-good sample
> [O] bisect-bad sample
OK, so we get rid of interrupts.IWI (not sure what those are), and
we also seem to increase the idle time (cpuidle.C1E-NHM.usage and
cpuidle.C6-NHM.usage), which also seem like good things. The overall
benchmark number looks to get a bit worse, though. Not sure why lseek()
would incur more hardirqs, but also unsure what the units are (3.88 of
what exactly?). Not sure why there would be more timer interrutpts,
unless my interpretation of the cpuidle stats is backwards, in which
case it would be a natural consequence of there being less idle time.
Any of this speculation at all relevant? ;-)
Thanx, Paul
--
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-64: espfix for 64-bit mode *PROTOTYPE*
On Mon, Apr 21, 2014 at 6:47 PM, H. Peter Anvin wrote: > Race condition (although with x86 being globally ordered, it probably can't > actually happen.) The bitmask is probably the way to go. Does the race matter? In the worst case you take the lock unnecessarily. But yes, the bitmask is easy. --Andy -- 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,rcu] b84c4e08143: +3.1% will-it-scale.per_thread_ops
On Sat, Apr 19, 2014 at 04:11:46PM +0800, Fengguang Wu wrote:
> On Thu, Apr 17, 2014 at 06:55:03AM -0700, Paul E. McKenney wrote:
> > On Thu, Apr 17, 2014 at 12:03:53PM +0800, Fengguang Wu wrote:
> > > Hi Paul,
> > >
> > > FYI, this improves will-it-scale/open1 throughput.
> >
> > Cool! Not a planned benefit, but I will take it. ;-)
> >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
> > > dev.2014.04.14a
> > > commit b84c4e08143c98dad4b4d139f08db0b98b0d3ec4 ("sched,rcu: Make
> > > cond_resched() report RCU quiescent states")
> >
> > But how should I read the data below? I see lots of positive percentages
> > and lots of negative percentages for the delta, and all near zero for
> > standard deviation. Is the overall improvement an average of these or
> > some such? What is being measured?
>
> There are a lot of things being measured, which are shown after each
> "TOTAL". For example, to get an overview of the report:
OK, let me see if I understand this...
> grep "TOTAL" this_email
>
> 563496 ~ 0% +3.1% 581059 ~ 0% TOTAL
> will-it-scale.per_thread_ops
> 756894 ~ 0% +2.8% 778452 ~ 0% TOTAL
> will-it-scale.per_process_ops
These two look like improvements, albeit small ones.
>0.57 ~ 0% -2.7% 0.55 ~ 0% TOTAL will-it-scale.scalability
This one looks like a degradation, again small.
> 346764 ~ 2% -74.0% 90164 ~ 1% TOTAL
> slabinfo.kmalloc-256.active_objs
> 10837 ~ 2% -73.9% 2824 ~ 1% TOTAL
> slabinfo.kmalloc-256.active_slabs
> 10837 ~ 2% -73.9% 2824 ~ 1% TOTAL
> slabinfo.kmalloc-256.num_slabs
> 346821 ~ 2% -73.9% 90393 ~ 1% TOTAL
> slabinfo.kmalloc-256.num_objs
> 105961 ~ 1% -63.0% 39153 ~ 1% TOTAL meminfo.SUnreclaim
> 26432 ~ 1% -62.9% 9814 ~ 1% TOTAL
> proc-vmstat.nr_slab_unreclaimable
The above all look great -- about the same amount of work done with a
lot less work on the part of the Linux kernel's memory-management system.
> 87318 ~ 0%+130.0% 200809 ~ 0% TOTAL softirqs.RCU
This one is not so good, as RCU is consuming more time an energy for
roughly the same amount of work.
> 140354 ~ 1% -47.6% 73490 ~ 0% TOTAL meminfo.Slab
> 77391 ~ 1% -46.7% 41235 ~ 2% TOTAL cpuidle.C6-NHM.usage
> 38368 ~ 2% -37.6% 23954 ~ 2% TOTAL softirqs.SCHED
>1.24 ~ 4% -35.4% 0.80 ~ 3% TOTAL
> perf-profile.cpu-cycles.do_notify_resume.int_signal.close
These look like improvements, again less work for a given level of
throughput.
>1.43 ~ 4% +41.9% 2.03 ~ 4% TOTAL
> perf-profile.cpu-cycles.rcu_process_callbacks.__do_softirq.irq_exit.smp_apic_timer_in
This is another aspect of RCU working harder. One good thing is that
there is less work per invocation. This could be consistent with shorter
RCU grace-period latencies, which would generally be a good thing.
(And yes, I still owe you RCU grace-period-latency measurements!)
> rupt.apic_timer_interrupt
>1.27 ~ 3% -30.0% 0.89 ~ 6% TOTAL
> perf-profile.cpu-cycles.setup_object.isra.46.new_slab.__slab_alloc.kmem_cache_alloc.g
Less memory-allocation work, goodness.
> empty_filp
>1.54 ~ 7% +35.6% 2.09 ~ 8% TOTAL
> perf-profile.cpu-cycles.kmem_cache_alloc.getname_flags.getname.do_sys_open.sys_open
But more of whatever this turns out to be. More allocations from within
the open() system call?
>4.21 ~ 2% -29.1% 2.98 ~ 3% TOTAL
> perf-profile.cpu-cycles.link_path_walk.path_openat.do_filp_open.do_sys_open.sys_open
>1.37 ~ 4% -23.1% 1.05 ~ 7% TOTAL
> perf-profile.cpu-cycles.__d_lookup_rcu.lookup_fast.link_path_walk.path_openat.do_filp
> en
>0.88 ~17% +29.1% 1.14 ~ 9% TOTAL
> perf-profile.cpu-cycles.path_init.path_openat.do_filp_open.do_sys_open.sys_open
Mixed results on other aspects of the open() system call?
>0.67 ~16% +33.6% 0.90 ~10% TOTAL
> perf-profile.cpu-cycles.restore_sigcontext.sys_rt_sigreturn.stub_rt_sigreturn.raise
I confess to being lost on this one.
>3.19 ~ 1% +17.4% 3.74 ~ 5% TOTAL
> perf-profile.cpu-cycles.file_free_rcu.rcu_process_callbacks.__do_softirq.irq_exit.smp
More RCU softirqs means more softirq exit overhead, presumably.
> ic_timer_interrupt
???
>4329 ~ 7% +15.2% 4986 ~ 5% TOTAL
> slabinfo.vm_area_struct.active_objs
But increased number of active objects would seem to hint at longer
RCU grace-period latencies, in contradiction with the previous hints
in the other direction.
>2536 ~ 1% -75.8%614 ~ 9% TOTAL
> time.involuntary_context_switches
> 32593 ~ 1% -62.1% 12349 ~ 2% TOTAL
> interrupts.0:IO-APIC-edge.timer
These look like improvements.
>6934 ~ 9% +86.2% 12908 ~ 7% TOTAL interrupts.RES
Looks like a degradation. Caused by the increase in
Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*
Race condition (although with x86 being globally ordered, it probably can't
actually happen.) The bitmask is probably the way to go.
On April 21, 2014 6:28:12 PM PDT, Andrew Lutomirski wrote:
>On Mon, Apr 21, 2014 at 6:14 PM, H. Peter Anvin wrote:
>> I wanted to avoid the "another cpu made this allocation, now I have
>to free" crap, but I also didn't want to grab the lock if there was no
>work needed.
>
>I guess you also want to avoid bouncing all these cachelines around on
>boot on bit multicore machines.
>
>I'd advocate using the bitmap approach or simplifying the existing
>code. For example:
>
>+ for (n = 0; n < ESPFIX_PUD_CLONES; n++) {
>+ pud = ACCESS_ONCE(pud_p[n]);
>+ if (!pud_present(pud))
>+ return false;
>+ }
>
>I don't see why that needs to be a loop. How can one clone exist but
>not the others?
>
>--Andy
--
Sent from my mobile phone. Please pardon brevity and lack of formatting.
--
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 V3] workqueue: substitute POOL_FREEZING with __WQ_FREEZING
On 04/22/2014 06:20 AM, Tejun Heo wrote: > On Mon, Apr 21, 2014 at 07:59:20PM +0800, Lai Jiangshan wrote: >> Only workqueues have freezable or freezing attribution/state, not worker >> pools. >> But POOL_FREEZING adds a suspicious state and makes reviewers confused. >> >> And it causes freeze_workqueues_begin() and thaw_workqueues() much >> complicated, >> they need to travel all the pools besides wqs. >> >> Since freezable is workqueue instance's attribution, and freezing >> is workqueue instance's state, so we introduce __WQ_FREEZING >> to wq->flags instead and remove POOL_FREEZING. >> >> It is different from POOL_FREEZING, POOL_FREEZING is simply set >> all over the world(all pools), while __WQ_FREEZING is only set for freezable >> wq. >> freeze_workqueues_begin()/thaw_workqueues() skip to handle non-freezable wqs >> and don't touch the non-freezable wqs' flags. > > I was about to apply the patch and have updated the patch description. > > While freezing takes place globally, its execution is per-workqueue; > however, the current implementation makes use of the per-worker_pool > POOL_FREEZING flag. While it's not broken, the flag makes the code > more confusing and complicates freeze_workqueues_begin() and > thaw_workqueues() by requiring them to walk through all pools. > > Since freezable is a workqueue's attribute, and freezing is a > workqueue's state, let's introduce __WQ_FREEZING to wq->flags instead > and remove POOL_FREEZING. > > It is different from POOL_FREEZING in that __WQ_FREEZING is only set > for freezable workqueues while POOL_FREEZING is set globally over all > pools. freeze_workqueues_begin() and thaw_workqueues() now skip > non-freezable workqueues. > > But looking at the patch, why do we need __WQ_FREEZING at all? We > should be able to test workqueue_freezing in pwq_adjust_max_active(), > right? The only requirement there would be that Testing workqueue_freezing requires wq_pool_mutex held. Although almost-all pwq_adjust_max_active() are called with wq_pool_mutex held, except workqueue_set_max_active(). But I hope pwq_adjust_max_active() don't require the heavy wq_pool_mutex. > pwq_adjust_max_active() is invoked at least once after > workqueue_freezing is changed, which is already guaranteed. > > 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] ARM: dts: at91-sama5d3_xplained: add the regulator device node
Hi,
> -Original Message-
> From: Alexandre Belloni [mailto:alexandre.bell...@free-electrons.com]
> Sent: Monday, April 21, 2014 8:22 PM
> To: Yang, Wenyou
> Cc: devicet...@vger.kernel.org; Ferre, Nicolas; linux-
> ker...@vger.kernel.org; robh...@kernel.org; broo...@kernel.org; linux-
> arm-ker...@lists.infradead.org
> Subject: Re: [PATCH] ARM: dts: at91-sama5d3_xplained: add the regulator
> device node
>
> On 21/04/2014 at 11:54:43 +0200, Alexandre Belloni wrote :
> > Hi,
> >
> > On 21/04/2014 at 12:29:07 +0800, Wenyou Yang wrote :
> > > +
> > > + vddana_reg: LDO_REG2 {
> > > + regulator-name =
> > > "VDDANA";
> > > + regulator-min-microvolt
> > > =
> <330>;
> > > + regulator-max-microvolt
> > > =
> <330>;
> > > + regulator-always-on;
> >
> > I'm pretty sure that one is not always on as you actually have to
> > configure it to get any voltage. Are you sure you want to set the
> > regulator-always-on property here ?
> >
>
> Just to clarify my though, wouldn't it be better to make the ADC driver
> handle that regulator instead of using regulator-always-on ?
Yes, you are right.
It should not use regulator-always-on property for this regulator. It is ADC
driver and ISI driver to handle it(The ISI takes PCK for clock).
I will send new version patch.
Thanks
>
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering http://free-
> electrons.com
Best Regards,
Wenyou Yang
--
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: linux-next: manual merge of the userns tree with Linus' tree
On Thu, 17 Apr 2014 01:44:21 -0700 ebied...@xmission.com (Eric W. Biederman) wrote: > > Al Viro writes: > > > On Thu, Apr 17, 2014 at 03:06:57PM +1000, Stephen Rothwell wrote: > >> Hi Eric, > >> > >> Today's linux-next merge of the userns tree got a conflict in > >> fs/namespace.c between various commits from Linus' tree and various > >> commits from the userns tree. > >> > >> I fixed it up (hopefully - see below) and can carry the fix as necessary > >> (no action is required). > > > > Various commits include this: > > commit 38129a13e6e71f666e0468e99fdd932a687b4d7e > > Author: Al Viro > > Date: Thu Mar 20 21:10:51 2014 -0400 > > > > switch mnt_hash to hlist > > > > present in v3.14... It's been there since before the merge window. > > And the code that is in conflict is even older. > > I just figured out of an abundance of caution I would make certain the > code was out there for automatic and semi-automatic things to pound on > before I resent my pull request to Linus, now that I have fixed the > stack overflow issue you were complaining about. > > I suspect something about fixing mntput caused Stephen to loose his > trivial resolution for this trivial conflict. That would be the three extra commits you added that touched that file - it throws "git rerere" off and I didn't recognise the source of the problem. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp_MMBSMluWc.pgp Description: PGP signature
[PATCH 2/2] ARM: dts: add gpio alias in hi3620 dts file
Use gpio alias to identify the index of gpio chip. Then we can keep the
same gpio number as schematics. Otherwise, gpio number is countered from
bottom to top.
Signed-off-by: Haojian Zhuang
---
arch/arm/boot/dts/hi3620.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/hi3620.dtsi b/arch/arm/boot/dts/hi3620.dtsi
index 6836795..2aaae09 100644
--- a/arch/arm/boot/dts/hi3620.dtsi
+++ b/arch/arm/boot/dts/hi3620.dtsi
@@ -21,6 +21,28 @@
serial2 =
serial3 =
serial4 =
+ gpio0 =
+ gpio1 =
+ gpio2 =
+ gpio3 =
+ gpio4 =
+ gpio5 =
+ gpio6 =
+ gpio7 =
+ gpio8 =
+ gpio9 =
+ gpio10 =
+ gpio11 =
+ gpio12 =
+ gpio13 =
+ gpio14 =
+ gpio15 =
+ gpio16 =
+ gpio17 =
+ gpio18 =
+ gpio19 =
+ gpio20 =
+ gpio21 =
};
pclk: clk {
--
1.9.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 1/2] gpio: pl061: get gpio base from alias id
If gpio base number isn't specified, the gpio base will be find from
the end of gpio number. In order to keep with schematics, use alias
to get the ID of gpio chip.
Signed-off-by: Haojian Zhuang
---
.../devicetree/bindings/gpio/gpio-pl061.txt| 31 ++
drivers/gpio/gpio-pl061.c | 14 +-
2 files changed, 44 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-pl061.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-pl061.txt
b/Documentation/devicetree/bindings/gpio/gpio-pl061.txt
new file mode 100644
index 000..164b5ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-pl061.txt
@@ -0,0 +1,31 @@
+PL061 GPIO controller bindings
+
+Required properties:
+- compatible:
+ - "arm,pl061", "arm,primecell".
+- #gpio-cells : Should be two.
+ - first cell is the gpio pin number
+ - second cell is used to specify the gpio polarity:
+ 0 = active high
+ 1 = active low
+- gpio-controller : Marks the device node as a GPIO controller.
+- interrupt-controller : Marks the device node as an interrupt controller.
+- #interrupt-cells : Should be two.
+ - first cell is the hw irq number
+ - second cell is used to specify the interrupt type:
+ 0 = default, unspecified type
+ 1 = rising edge triggered
+ 2 = falling edge triggered
+ 4 = high level triggered
+ 8 = low level triggered
+
+Example:
+ gpio0: gpio@fc806000 {
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0xfc806000 0x1000>;
+ interrupts = <0 64 0x4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
diff --git a/drivers/gpio/gpio-pl061.c b/drivers/gpio/gpio-pl061.c
index b0f4752..14f3ab5 100644
--- a/drivers/gpio/gpio-pl061.c
+++ b/drivers/gpio/gpio-pl061.c
@@ -236,6 +236,18 @@ static struct irq_chip pl061_irqchip = {
.irq_set_type = pl061_irq_type,
};
+/* Parse gpio base from DT */
+static int pl061_parse_gpio_base(struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+ int ret, id;
+
+ id = of_alias_get_id(np, "gpio");
+ if (id < 0)
+ return id;
+ return (id * PL061_GPIO_NR);
+}
+
static int pl061_probe(struct amba_device *adev, const struct amba_id *id)
{
struct device *dev = >dev;
@@ -255,7 +267,7 @@ static int pl061_probe(struct amba_device *adev, const
struct amba_id *id)
return -ENODEV;
}
} else {
- chip->gc.base = -1;
+ chip->gc.base = pl061_parse_gpio_base(dev);
irq_base = 0;
}
--
1.9.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: linux-next: manual merge of the vfs tree with Linus' and te ext4 trees
On Mon, Apr 21, 2014 at 09:19:19PM -0400, Theodore Ts'o wrote: > On Tue, Apr 22, 2014 at 11:04:59AM +1000, Stephen Rothwell wrote: > > > > Today's linux-next merge of the vfs tree got a conflict in > > fs/ext4/extents.c between rebased versions of commits from Linus' and the > > ext4 trees and the same commits from the vfs tree. > > > > I fixed it up (I just used the version from Linus' and the ext4 trees) > > and can carry the fix as necessary (no action is required). > > > > Al, this is why I asked you about checking with Ted about his tree being > > rebased after you merged it into yours ... > > Sorry, Al, I hadn't been aware you wanted to carrying some of these > changes. I had mentioned that I was planning on carrying them in the > ext4 tree and including them for 3.15 because some of them were fixing > bugs that had been introduced in the merge window. Since no one > objected, I thought everyone was on the same page about that plan. *rechecks* I have Cc'd you on this: Subject: Re: linus-next stats (Re: Linux 3.15-rc1 out, merge window closed) Message-ID: <20140417203412.gb18...@zeniv.linux.org.uk> [snip] one non-trivial in ext4 that I've dealt with by merging a piece of ext4 branch up to the relevant point. As long as ext4.git#dev isn't rebased, everything should remain fine, when/if it does I'll just redo that merge. BTW, ext4 side of that thing is *still* not quite right - playing with rlimit allows one to smuggle an unaligned write past that check... I'll rebase that thing... -- 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: linux-next: build failure after merge of the userns tree
Hi Eric, On Thu, 17 Apr 2014 00:18:44 -0700 ebied...@xmission.com (Eric W. Biederman) wrote: > > Stephen Rothwell writes: > > > After merging the userns tree, today's linux-next build (powerpc > > ppc64_defconfig) failed like this: > > > > fs/namespace.c: In function 'new_mountpoint': > > fs/namespace.c:725:9: error: implicit declaration of function 'hash' > > [-Werror=implicit-function-declaration] > > struct list_head *chain = mountpoint_hashtable + hash(NULL, dentry); > > ^ > > fs/namespace.c:725:28: warning: initialization from incompatible pointer > > type [enabled by default] > > struct list_head *chain = mountpoint_hashtable + hash(NULL, dentry); > > ^ > > fs/namespace.c:741:2: warning: passing argument 2 of 'hlist_add_head' from > > incompatible pointer type [enabled by default] > > hlist_add_head(>m_hash, chain); > > ^ > > In file included from include/linux/signal.h:4:0, > > from include/linux/syscalls.h:72, > > from fs/namespace.c:11: > > include/linux/list.h:637:20: note: expected 'struct hlist_head *' but > > argument is of type 'struct list_head *' > > static inline void hlist_add_head(struct hlist_node *n, struct hlist_head > > *h) > > ^ > > > > So clearly my merge conflict resolution was not sufficient. > > > > I will just drop the userns tree for today. Please give me some help > > with the resolutions - or fix this stuff up yourselves. > > You had this exact conflict succesfully resolved yesterday. Sigh. > > Line 725 of fs/namespace.c: Simply need to read. > struct hlist_head *chain = mp_hash(dentry); Yes, sorry about that - fixed for today (hopefully). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpFVTeqE_Z6J.pgp Description: PGP signature
Re: [PATCH 1/1] block/blk-throttle.c: add static to blk_throtl_dispatch_work_fn
On 2014-04-17 13:41, Fabian Frederick wrote: blk_throtl_dispatch_work_fn is only used in blk-throttle.c Thanks, applied for 3.16. -- Jens Axboe -- 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 v2] kernel/power/hibernate.c: use 'u64' instead of 's64' to avoid warning
For do_div(), it need 'u64' type, which means the outside must be sure
of 'start' is not bigger than 'stop', or it will report warning.
Even if 'start' was really bigger than 'stop', it would print incorrect
information, but for kernel, it still can continue, so use WARN_ON() is
enough.
The related warning (with allmodconfig for unicore32):
CC kernel/power/hibernate.o
kernel/power/hibernate.c: In function ‘swsusp_show_speed’:
kernel/power/hibernate.c:237: warning: comparison of distinct pointer types
lacks a cast
Signed-off-by: Chen Gang
---
kernel/power/hibernate.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index f4f2073..d5117d5 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -228,12 +228,13 @@ static void platform_recover(int platform_mode)
void swsusp_show_speed(struct timeval *start, struct timeval *stop,
unsigned nr_pages, char *msg)
{
- s64 elapsed_centisecs64;
+ u64 elapsed_centisecs64;
int centisecs;
int k;
int kps;
elapsed_centisecs64 = timeval_to_ns(stop) - timeval_to_ns(start);
+ WARN_ON((s64)elapsed_centisecs64 < 0);
do_div(elapsed_centisecs64, NSEC_PER_SEC / 100);
centisecs = elapsed_centisecs64;
if (centisecs == 0)
--
1.9.2.459.g68773ac
--
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-64: espfix for 64-bit mode *PROTOTYPE*
On Mon, Apr 21, 2014 at 6:14 PM, H. Peter Anvin wrote:
> I wanted to avoid the "another cpu made this allocation, now I have to free"
> crap, but I also didn't want to grab the lock if there was no work needed.
I guess you also want to avoid bouncing all these cachelines around on
boot on bit multicore machines.
I'd advocate using the bitmap approach or simplifying the existing
code. For example:
+ for (n = 0; n < ESPFIX_PUD_CLONES; n++) {
+ pud = ACCESS_ONCE(pud_p[n]);
+ if (!pud_present(pud))
+ return false;
+ }
I don't see why that needs to be a loop. How can one clone exist but
not the others?
--Andy
--
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/
linux-next: build failure after merge of the vfs tree
Hi Al,
After merging the vfs tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
fs/nfs/direct.c: In function 'nfs_direct_read_schedule_iovec':
fs/nfs/direct.c:382:4: error: implicit declaration of function 'vfree'
[-Werror=implicit-function-declaration]
vfree(pagevec);
^
Caused by commit 2703e4cd2d57 ("new helper: iov_iter_get_pages_alloc()").
I have used the vfs tree from next-20140417 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpBQBDjOZyv4.pgp
Description: PGP signature
Re: [PATCH v1 next 0/4] blk-mq: misc changes
On Tue, Apr 22, 2014 at 9:03 AM, Jens Axboe wrote: > On 2014-04-19 04:00, Ming Lei wrote: >> >> Hi, >> >> Three of them are fixes, another one is cleanup. >> >> V1: >> - line break(2/4) >> - use explicit cast(3/4) > > > I believe this is v2, but I guess your first posting was v0 :-) > Applied for testing for 3.16, thanks. Yeah, it is the C programming style, :-) 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/9] ACPICA: Executer: Fix buffer allocation issue for generic_serial_bus region field accesses.
On 2014年04月22日 05:38, Rafael J. Wysocki wrote:
> Hi,
>
> On Wednesday, April 16, 2014 09:24:34 PM Lan Tianyu wrote:
>> From: Lv Zheng
>>
>> The size of the buffer allocated for generic_serial_bus region access
>> is not correct. This patch introduces acpi_ex_get_serial_access_length()
>> to be invoked to obtain correct data buffer length. Reported by
>> Lan Tianyu, Fixed by Lv Zheng.
>>
>> Signed-off-by: Lv Zheng
>> Signed-off-by: Lan Tianyu
>
> I'm queueing up this patch as a fix for 3.15, but can you please resend the
> whole series with a CC to linux-acpi?
>
Ok. I will do that.
>
>> ---
>> drivers/acpi/acpica/exfield.c | 104
>> +++---
>> 1 file changed, 97 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/acpi/acpica/exfield.c b/drivers/acpi/acpica/exfield.c
>> index 68d9744..12878e1 100644
>> --- a/drivers/acpi/acpica/exfield.c
>> +++ b/drivers/acpi/acpica/exfield.c
>> @@ -45,10 +45,71 @@
>> #include "accommon.h"
>> #include "acdispat.h"
>> #include "acinterp.h"
>> +#include "amlcode.h"
>>
>> #define _COMPONENT ACPI_EXECUTER
>> ACPI_MODULE_NAME("exfield")
>>
>> +/* Local prototypes */
>> +static u32
>> +acpi_ex_get_serial_access_length(u32 accessor_type, u32 access_length);
>> +
>> +/***
>> + *
>> + * FUNCTION:acpi_get_serial_access_bytes
>> + *
>> + * PARAMETERS: accessor_type - The type of the protocol indicated by
>> region
>> + *field access attributes
>> + * access_length - The access length of the region field
>> + *
>> + * RETURN: Decoded access length
>> + *
>> + * DESCRIPTION: This routine returns the length of the generic_serial_bus
>> + * protocol bytes
>> + *
>> +
>> **/
>> +
>> +static u32
>> +acpi_ex_get_serial_access_length(u32 accessor_type, u32 access_length)
>> +{
>> +u32 length;
>> +
>> +switch (accessor_type) {
>> +case AML_FIELD_ATTRIB_QUICK:
>> +
>> +length = 0;
>> +break;
>> +
>> +case AML_FIELD_ATTRIB_SEND_RCV:
>> +case AML_FIELD_ATTRIB_BYTE:
>> +
>> +length = 1;
>> +break;
>> +
>> +case AML_FIELD_ATTRIB_WORD:
>> +case AML_FIELD_ATTRIB_WORD_CALL:
>> +
>> +length = 2;
>> +break;
>> +
>> +case AML_FIELD_ATTRIB_MULTIBYTE:
>> +case AML_FIELD_ATTRIB_RAW_BYTES:
>> +case AML_FIELD_ATTRIB_RAW_PROCESS:
>> +
>> +length = access_length;
>> +break;
>> +
>> +case AML_FIELD_ATTRIB_BLOCK:
>> +case AML_FIELD_ATTRIB_BLOCK_CALL:
>> +default:
>> +
>> +length = ACPI_GSBUS_BUFFER_SIZE;
>> +break;
>> +}
>> +
>> +return (length);
>> +}
>> +
>>
>> /***
>> *
>> * FUNCTION:acpi_ex_read_data_from_field
>> @@ -63,8 +124,9 @@ ACPI_MODULE_NAME("exfield")
>> * Buffer, depending on the size of the field.
>> *
>>
>> **/
>> +
>> acpi_status
>> -acpi_ex_read_data_from_field(struct acpi_walk_state *walk_state,
>> +acpi_ex_read_data_from_field(struct acpi_walk_state * walk_state,
>> union acpi_operand_object *obj_desc,
>> union acpi_operand_object **ret_buffer_desc)
>> {
>> @@ -73,6 +135,7 @@ acpi_ex_read_data_from_field(struct acpi_walk_state
>> *walk_state,
>> acpi_size length;
>> void *buffer;
>> u32 function;
>> +u16 accessor_type;
>>
>> ACPI_FUNCTION_TRACE_PTR(ex_read_data_from_field, obj_desc);
>>
>> @@ -116,9 +179,22 @@ acpi_ex_read_data_from_field(struct acpi_walk_state
>> *walk_state,
>> ACPI_READ | (obj_desc->field.attribute << 16);
>> } else if (obj_desc->field.region_obj->region.space_id ==
>> ACPI_ADR_SPACE_GSBUS) {
>> -length = ACPI_GSBUS_BUFFER_SIZE;
>> -function =
>> -ACPI_READ | (obj_desc->field.attribute << 16);
>> +accessor_type = obj_desc->field.attribute;
>> +length = acpi_ex_get_serial_access_length(accessor_type,
>> + obj_desc->
>> + field.
>> +
>> access_length);
>> +
>> +/*
>> + * Add additional 2 bytes for modeled
>> generic_serial_bus data buffer:
>> + * typedef struct {
>> + * BYTEStatus; // Byte 0 of the data buffer
>> + * BYTELength; // Byte 1 of the data buffer
>> + *
Re: linux-next: manual merge of the vfs tree with Linus' and te ext4 trees
On Tue, Apr 22, 2014 at 11:04:59AM +1000, Stephen Rothwell wrote: > > Today's linux-next merge of the vfs tree got a conflict in > fs/ext4/extents.c between rebased versions of commits from Linus' and the > ext4 trees and the same commits from the vfs tree. > > I fixed it up (I just used the version from Linus' and the ext4 trees) > and can carry the fix as necessary (no action is required). > > Al, this is why I asked you about checking with Ted about his tree being > rebased after you merged it into yours ... Sorry, Al, I hadn't been aware you wanted to carrying some of these changes. I had mentioned that I was planning on carrying them in the ext4 tree and including them for 3.15 because some of them were fixing bugs that had been introduced in the merge window. Since no one objected, I thought everyone was on the same page about that plan. - Ted -- 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/
linux-next: manual merge of the vfs tree with Linus' tree
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in mm/filemap.c
between commit b59b8cbca629 ("mm: fix new kernel-doc warning in
filemap.c") from Linus' tree and commit cbabd10029a4 ("write_iter
variants of {__,}generic_file_aio_write()") from the vfs tree.
I fixed it up (I used the vfs tree version) and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpaX9KSATukR.pgp
Description: PGP signature
Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*
I wanted to avoid the "another cpu made this allocation, now I have to free" crap, but I also didn't want to grab the lock if there was no work needed. On April 21, 2014 6:06:19 PM PDT, Andrew Lutomirski wrote: >On Mon, Apr 21, 2014 at 5:53 PM, H. Peter Anvin wrote: >> Well, if 2^17 CPUs are allocated we might 2K pages allocated. We >could easily do a bitmap here, of course. NR_CPUS/64 is a small >number, and would reduce the code complexity. >> > >Even simpler: just get rid of the check entirely. That is, break out >of the higher level loops once one of them is set (this should be a >big speedup regardless) and don't allocate the page if the first PTE >is already pointing at something. > >After all, espfix_already_there is mostly a duplicate of >init_espfix_cpu. > >--Andy -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- 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.13 00/32] 3.13.11-stable review
On Mon, Apr 21, 2014 at 06:06:06PM -0700, Guenter Roeck wrote: > On 04/20/2014 07:13 PM, Greg Kroah-Hartman wrote: > > > > > > Note, this is the LAST 3.13.y kernel I will be releasing. It will be > > end-of-life after this release, please move to 3.14.y at this time. > > > > > > > > This is the start of the stable review cycle for the 3.13.11 release. > > There are 32 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Build results: > total: 126 pass: 122 skipped: 4 fail: 0 > > Qemu tests all passed. Looks good ... > > Details are available at http://server.roeck-us.net:8010/builders. Thanks for testing. 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/
linux-next: manual merge of the vfs tree with the ext4 tree
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in fs/ext4/file.c
between rebased commits from the ext4 tree and commit 29a8196bc41c
("convert ext4 to ->write_iter()") from the vfs tree.
I fixed it up (in this case I used the conflicting hunks from the vfs
tree - I hope its right) and can carry the fix as necessary (no action is
required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpuBObCPyb86.pgp
Description: PGP signature
Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*
On Mon, Apr 21, 2014 at 5:53 PM, H. Peter Anvin wrote: > Well, if 2^17 CPUs are allocated we might 2K pages allocated. We could > easily do a bitmap here, of course. NR_CPUS/64 is a small number, and would > reduce the code complexity. > Even simpler: just get rid of the check entirely. That is, break out of the higher level loops once one of them is set (this should be a big speedup regardless) and don't allocate the page if the first PTE is already pointing at something. After all, espfix_already_there is mostly a duplicate of init_espfix_cpu. --Andy -- 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: [blk] WARNING: CPU: 0 PID: 300 at kernel/softirq.c:156 _local_bh_enable_ip()
On 2014-04-20 14:30, Jet Chen wrote: Hi Zhiguo, I got the below dmesg and the first bad commit is git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 2c575026fae6e63771bd2a4c1d407214a8096a89 Author: Hong Zhiguo AuthorDate: Wed Nov 20 10:35:05 2013 -0700 Commit: Jens Axboe CommitDate: Wed Nov 20 15:33:04 2013 -0700 Update of blkg_stat and blkg_rwstat may happen in bh context. While u64_stats_fetch_retry is only preempt_disable on 32bit UP system. This is not enough to avoid preemption by bh and may read strange 64 bit value. Signed-off-by: Hong Zhiguo Acked-by: Tejun Heo Cc: sta...@kernel.org Signed-off-by: Jens Axboe +---+++ | | 82023bb7f7 | 2c575026fa | +---+++ | boot_successes| 47 | 0 | | boot_failures | 13 | 20 | | BUG:kernel_boot_hang | 13 | 5 | | inconsistent_IN-SOFTIRQ-W-SOFTIRQ-ON-W_usage | 0 | 15 | | backtrace:smpboot_thread_fn | 0 | 15 | | backtrace:vfs_read| 0 | 9 | | backtrace:SyS_read| 0 | 9 | | WARNING:CPU:PID:at_kernel/softirq.c:_local_bh_enable_ip() | 0 | 7 | | BUG:spinlock_lockup_suspected_on_CPU | 0 | 1 | | backtrace:do_mount| 0 | 6 | | backtrace:SyS_mount | 0 | 6 | | backtrace:async_run_entry_fn | 0 | 0 | +---+++ [ 12.318816] WARNING: CPU: 0 PID: 300 at kernel/softirq.c:156 _local_bh_enable_ip+0x34/0x97() Does this still happen with 3.15-rc2? -- Jens Axboe -- 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.13 00/32] 3.13.11-stable review
On 04/20/2014 07:13 PM, Greg Kroah-Hartman wrote: Note, this is the LAST 3.13.y kernel I will be releasing. It will be end-of-life after this release, please move to 3.14.y at this time. This is the start of the stable review cycle for the 3.13.11 release. There are 32 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Build results: total: 126 pass: 122 skipped: 4 fail: 0 Qemu tests all passed. Looks good ... Details are available at http://server.roeck-us.net:8010/builders. Guenter -- 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/
linux-next: manual merge of the vfs tree with Linus' and te ext4 trees
Hi Al, Today's linux-next merge of the vfs tree got a conflict in fs/ext4/extents.c between rebased versions of commits from Linus' and the ext4 trees and the same commits from the vfs tree. I fixed it up (I just used the version from Linus' and the ext4 trees) and can carry the fix as necessary (no action is required). Al, this is why I asked you about checking with Ted about his tree being rebased after you merged it into yours ... -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpoE0G5tQHtC.pgp Description: PGP signature
Re: [PATCH v1 next 0/4] blk-mq: misc changes
On 2014-04-19 04:00, Ming Lei wrote: Hi, Three of them are fixes, another one is cleanup. V1: - line break(2/4) - use explicit cast(3/4) I believe this is v2, but I guess your first posting was v0 :-) Applied for testing for 3.16, thanks. -- Jens Axboe -- 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/
