[PATCH] mm: protect against concurrent vma expansion
expand_stack() runs with a shared mmap_sem lock. Because of this, there
could be multiple concurrent stack expansions in the same mm, which may
cause problems in the vma gap update code.
I propose to solve this by taking the mm->page_table_lock around such vma
expansions, in order to avoid the concurrency issue. We only have to worry
about concurrent expand_stack() calls here, since we hold a shared mmap_sem
lock and all vma modificaitons other than expand_stack() are done under
an exclusive mmap_sem lock.
I previously tried to achieve the same effect by making sure all
growable vmas in a given mm would share the same anon_vma, which we
already lock here. However this turned out to be difficult - all of the
schemes I tried for refcounting the growable anon_vma and clearing
turned out ugly. So, I'm now proposing only the minimal fix.
Signed-off-by: Michel Lespinasse
---
mm/mmap.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 9ed3a06242a0..e44fe876a7e3 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2069,6 +2069,11 @@ int expand_upwards(struct vm_area_struct *vma, unsigned
long address)
if (vma->vm_pgoff + (size >> PAGE_SHIFT) >= vma->vm_pgoff) {
error = acct_stack_growth(vma, size, grow);
if (!error) {
+ /*
+* page_table_lock to protect against
+* concurrent vma expansions
+*/
+ spin_lock(&vma->vm_mm->page_table_lock);
anon_vma_interval_tree_pre_update_vma(vma);
vma->vm_end = address;
anon_vma_interval_tree_post_update_vma(vma);
@@ -2076,6 +2081,8 @@ int expand_upwards(struct vm_area_struct *vma, unsigned
long address)
vma_gap_update(vma->vm_next);
else
vma->vm_mm->highest_vm_end = address;
+ spin_unlock(&vma->vm_mm->page_table_lock);
+
perf_event_mmap(vma);
}
}
@@ -2126,11 +2133,18 @@ int expand_downwards(struct vm_area_struct *vma,
if (grow <= vma->vm_pgoff) {
error = acct_stack_growth(vma, size, grow);
if (!error) {
+ /*
+* page_table_lock to protect against
+* concurrent vma expansions
+*/
+ spin_lock(&vma->vm_mm->page_table_lock);
anon_vma_interval_tree_pre_update_vma(vma);
vma->vm_start = address;
vma->vm_pgoff -= grow;
anon_vma_interval_tree_post_update_vma(vma);
vma_gap_update(vma);
+ spin_unlock(&vma->vm_mm->page_table_lock);
+
perf_event_mmap(vma);
}
}
--
1.7.7.3
--
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 V7 1/7] kbuild: centralize .dts->.dtb rule
On Fri, Nov 30, 2012 at 8:01 PM, Rob Herring wrote: [...] >> This is based on next-20121126. > > I'll apply the series but I need a stable base. Looks like xtensa has > the dependency. Or I can just drop xtensa. Please drop it, I will follow up with a conversion. -- Thanks. -- Max -- 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: Wireless regression in workqueue: use mod_delayed_work() instead of __cancel + queue
On Fri, 30 Nov 2012, Tejun Heo wrote:
> Hey, again.
>
> Can you please test whether the following patch makes any difference?
>
> Thanks!
>
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index 042d221..26368ef 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -1477,7 +1477,10 @@ bool mod_delayed_work_on(int cpu, struct
> workqueue_struct *wq,
> } while (unlikely(ret == -EAGAIN));
>
> if (likely(ret >= 0)) {
> - __queue_delayed_work(cpu, wq, dwork, delay);
> + if (!delay)
> + __queue_work(cpu, wq, &dwork->work);
> + else
> + __queue_delayed_work(cpu, wq, dwork, delay);
> local_irq_restore(flags);
> }
>
Yes. I tested that both directly on top of the bad commit, and on
v3.7-rc7, and it fixes the bug in both cases.
Thanks,
Anders
--
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 0/1] Input: xpad - Implement wireless controller LED setting and fix connect time LED setting
On Fri, 30 Nov 2012 14:30:23 -0800
Dmitry Torokhov wrote:
> Hi Chris,
>
> On Friday, November 30, 2012 01:54:06 PM Chris Moeller wrote:
> > I've submitted versions of this with prior patch sets, and this part
> > was never accepted, possibly because it depended on other patches to
> > work, or possibly because it wasn't so cleanly organized. This time,
> > I've split the LED setting command off into its own static function,
> > then call that on controller connect and optionally on LED setting
> > commands. The static function does not include any locking, because
> > locking inside the function which receives the incoming packets
> > deadlocks the driver, and does not appear to be necessary anyway.
> >
> > It also removes all traces of the original bulk out function which
> > was designed for the purpose of setting the LED status on connect,
> > as I found that it actually does not work at all. It appears to try
> > to send the data, but nothing actually happens to the controller
> > LEDs.
>
> Attached is a reply I sent to on 7/4/11 to which you unfortunately
> never responded. The issue is that of force feedback (rumble) and LED
> share the same URB then access to that URB should be arbitrated. The
> attached message contains a patch that attempts to implement that
> arbitration, could you please try it out and see what changes are
> needed to make it work?
>
> Thanks.
>
So sorry I missed your reply. That's what I get for filtering the
mailing list messages past my inbox, then never following up on my
filter/folder set for replies to my own messages. I recall you
mentioned that potential race condition when I first submitted, but I
forgot to do anything about it. I'm glad at least one of us has our
stuff together. It seems to work just fine, but there may be a force
feedback issue with the following test program, where it leaves the
effect playing indefinitely after the program terminates, and then the
controller itself ceases to respond until the module is removed and
reloaded.
---
#include
#include
#include
#include
int running;
void interrupt(int sig)
{
(void)sig;
running = 0;
}
int main(void)
{
int fd = open("/dev/input/event13", O_RDWR);
struct ff_effect effect;
struct input_event play;
effect.type = FF_RUMBLE;
effect.id = -1;
effect.u.rumble.strong_magnitude = 0x2F00;
effect.u.rumble.weak_magnitude = 0x1500;
effect.replay.length = 2000;
effect.replay.delay = 0;
ioctl(fd, EVIOCSFF, &effect);
play.type = EV_FF;
play.code = effect.id;
running = 1;
signal(SIGINT, interrupt);
while (running)
{
play.value = 1;
write(fd, (const void *) &play, sizeof(play));
usleep(3);
play.value = 0;
write(fd, (const void *) &play, sizeof(play));
usleep(5000);
}
ioctl(fd, EVIOCRMFF, effect.id);
close(fd);
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] uio.c: Fix warning: 'ret' might be used uninitialized
On Sat, Dec 01, 2012 at 02:22:44AM +0100, Cong Ding wrote: > On Fri, Nov 30, 2012 at 10:33 PM, Hans J. Koch wrote: > > On Fri, Nov 30, 2012 at 12:12:46PM +0100, Tux9 wrote: > >> I like Vitalii's solution more. Hans's solution assign the value > >> -ENOMEM to ret in every round of the loop, which is a kind of wasting > >> CPU cycles. > > > > The difference between > > 1 files changed, 12 insertions(+), 4 deletions(-) and > > 1 files changed, 2 insertions(+), 0 deletions(-) > > > > is more important. Note that this code is not in a fast path but only > > called once at device creation. > Why do you think the size of the patch is so important? I think the > most important thing is the coding style and efficiency. I agree > efficiency is not important in this case, but what about coding style? Most important. Short is beautiful. > Your code is _not_ very easy to understand. You think so? > It's a very natural thing > to set the return value and then goto the error-handling codes, which > is exactly same as what Vitalii did, rather than setting an initial > value in the beginning of each round of the loop as you did. Setting a default value at the beginning of a block is the most natural thing. I don't want to repeat the same code in three places. > There are > also a bunch of codes in kernel in the same style with Vitalii, but I > cannot find anything same as your codes. If you follow LKML closely, you'll notice that simplifying code by replacing unnecessary repetitions with shorter versions is always welcome. If we didn't go for that, the kernel source would be a few million lines bigger by now. Thanks, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] New driver: Xillybus generic interface for FPGA (programmable logic)
On 11/30/2012 09:36 AM, Greg KH wrote: On Fri, Nov 30, 2012 at 05:28:47PM +, Arnd Bergmann wrote: On Wednesday 28 November 2012, Eli Billauer wrote: Xillybus is a general-purpose framework for communication between programmable logic (FPGA) and a host. It provides a simple connection between hardware FIFOs in the FPGA and their respective device files on the host. The user space programming model is like piping data from or to the FPGA. The underlying transport between the host and FPGA is either PCIe or AXI (AMBA bus by ARM). The Xillybus logic (IP core) is configurable in the number of pipes it presents and their nature. The driver autodetects these pipes, making it essentially forward-compatible to future configurations. The benefit of having this driver enabled in the kernel is that hardware vendors may release a new card, knowing that it will work out of the box on any future Linux machine, with the specific configuration defined for the FPGA part. This driver has been available for download for over a year, and has been actively used on a wide variety of kernels versions and configurations. I have a much higher-level comment on this driver: There seem to be a number of parties that are interested in having reprogrammable logic available in Linux and that will want to merge their drivers. I'm aware of these other people that must have some interest (and one person I can't mention here because of NDA): Philip Balister (OpenSDR) Dinh Nguyen (ARM SOCFPGA maintainer) Pavel Machek (SOCFPGA contributor) John Linn (Zynq maintainer) Michal Simek (Zynq maintainer) Ira W. Snyder (Carma driver author) Yes, I know of at least one more device other than the ones listed above that wants this type of functionality as well, so defining it in a standard user/kernel api manner would be very good to do. I'm concerned that a standard driver for FPGA's will be a very difficult problem. The Xillybus driver looks interesting on several levels, however my first concern is depends on a FPGA IP block that is not open source. This is not a bad thing, just a potential obstacle for some people. I've been engaged in design discussions today with my customer. Our target is the Xilinx Zynq hardware. The first pass at a driver focuses on creating the minimal amount of code in the kernel doing most of the logic in user space. So the driver code allocates a large chunk of RAM for the FPGA to read/write to, provides a mmap function so user space can see this RAM, also mmaps in the address space of an AXI slave so the user space can control the logic. This approach has no dependencies on what is loaded into the fpga. This is a very different approach then the Xillybus driver, but should also be useful to a large class of people. Hopefully, we can converge on a set of useful drivers, and not end up with a million drivers all based on custom fpga configuration :) Philip thanks, 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/
Jak poprawić obsługę Klienta w firmie?
Witaj, Żadna firma nie może być istnieć bez zadowolonych Klientów. Nasza firma zajmuje się badaniami, planowaniem strategii, wdrożeniami wewnętrznych działów obsługi Klienta i contact center, szkoleniami z zakresu obsługi Klienta, wdrożeń contact center oraz sprzedaży konsultacyjnej. Zamów teraz nasz dwutygodniowy newsletter, klikając w poniższy link i dowiedz się: 1. Jak poprawić jakość obsługi Klienta w firmie? 2. Jak wykorzystywać narzędzia IT w obsłudze Klienta? 3. Czy warto wdrożyć wewnętrzne contact center? 4. Czy możesz wykorzystać media społecznościowe w swojej firmie? 5. Co to jest ,,lead nurturing"? 6. Czym możesz wyróżnić się od konkurencji? http://sare.enewsletter.pl/k2/1395/8/2w/af7e6a9538d1b Zgodnie z ustawą o świadczeniu usług drogą elektroniczną proszę o informację, czy są Państwo zainteresowani otrzymywaniem informacji na temat metod i narzędzi podnoszenia jakości obsługi Klienta w firmach. Niniejsza oferta została wysłana przez ClientService.pl - serwis poświęcony poprawie efektywności działania firm dzięki doskonaleniu obsługi Klienta. Pozdrawiamy i zapraszamy do korzystania z newslettera Dział Obsługi Klienta www.clientservice.pl Właścicielem ClientService.pl jest Direct Point Sp. z o.o., z siedzibą w 01-319, Warszawie, przy ulicy ul. Szeligowskiej 2/11 , NIP 522-293-16-93, REGON 142033245, KRS 338462 -- 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: Regression with initramfs and nfsroot (appears to be in the dcache)
On Fri, Nov 30, 2012 at 02:00:48AM +, Al Viro wrote:
> OK, that settles it. WARN_ON() and printks in the area can be dropped;
> the right fix is below. However, there's a similar place in cifs that
> also needs to be dealt with and I really, really wonder why the hell do
> we do d_drop() in nfs_revalidate_lookup(). It's not relevant in this
> bug, but I would like to understand what's wrong with simply returning
> 0 from ->d_revalidate() and letting the caller (in fs/namei.c) take care
> of unhashing, etc. itself. Would make have_submounts() in there pointless
> as well - we could just return 0 and let d_invalidate() take care of the
> checks... Trond?
>
> diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
> --- a/fs/nfs/dir.c
> +++ b/fs/nfs/dir.c
> @@ -450,7 +450,8 @@ void nfs_prime_dcache(struct dentry *parent, struct
> nfs_entry *entry)
> nfs_refresh_inode(dentry->d_inode, entry->fattr);
> goto out;
> } else {
> - d_drop(dentry);
> + if (d_invalidate(dentry) != 0)
> + goto out;
> dput(dentry);
> }
> }
Hello,
With your previous patch (with the WARN_ON), I hit the WARN_ON() in the
test case described here: https://patchwork.kernel.org/patch/1446851/ .
The __d_move()ing mountpoint case no longer hits, and there is no longer
an EBUSY, so this seems to work for me (in 3.6, where it broke).
Simon-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] f2fs: move error condition for mkdir at proper place
From: Namjae Jeon In function f2fs_mkdir, err is being initialized without even checking if there was any error in new inode creation. So, instead check the inode error and make use of error/return condition. Signed-off-by: Namjae Jeon Signed-off-by: Amit Sahrawat --- fs/f2fs/namei.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c index 63efd77..2d720ca 100644 --- a/fs/f2fs/namei.c +++ b/fs/f2fs/namei.c @@ -287,9 +287,8 @@ static int f2fs_mkdir(struct inode *dir, struct dentry *dentry, umode_t mode) int err; inode = f2fs_new_inode(dir, S_IFDIR | mode); - err = PTR_ERR(inode); if (IS_ERR(inode)) - return err; + return PTR_ERR(inode); inode->i_op = &f2fs_dir_inode_operations; inode->i_fop = &f2fs_dir_operations; -- 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 5/6] f2fs: remove unneeded initialization
From: Namjae Jeon
No need to initialize "struct f2fs_gc_kthread *gc_th = NULL",
as gc_th = NULL, will be taken care by the return values of kmalloc().
And fix codes in other places.
Signed-off-by: Namjae Jeon
Signed-off-by: Amit Sahrawat
---
fs/f2fs/gc.c |2 +-
fs/f2fs/segment.c |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 3271be4..644aa38 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -89,7 +89,7 @@ static int gc_thread_func(void *data)
int start_gc_thread(struct f2fs_sb_info *sbi)
{
- struct f2fs_gc_kthread *gc_th = NULL;
+ struct f2fs_gc_kthread *gc_th;
gc_th = kmalloc(sizeof(struct f2fs_gc_kthread), GFP_KERNEL);
if (!gc_th)
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index a177eb3..969df1a 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -1489,7 +1489,7 @@ static int build_free_segmap(struct f2fs_sb_info *sbi)
static int build_curseg(struct f2fs_sb_info *sbi)
{
- struct curseg_info *array = NULL;
+ struct curseg_info *array;
int i;
array = kzalloc(sizeof(*array) * NR_CURSEG_TYPE, GFP_KERNEL);
@@ -1656,7 +1656,7 @@ int build_segment_manager(struct f2fs_sb_info *sbi)
{
struct f2fs_super_block *raw_super = F2FS_RAW_SUPER(sbi);
struct f2fs_checkpoint *ckpt = F2FS_CKPT(sbi);
- struct f2fs_sm_info *sm_info = NULL;
+ struct f2fs_sm_info *sm_info;
int err;
sm_info = kzalloc(sizeof(struct f2fs_sm_info), GFP_KERNEL);
--
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 4/6] f2fs: check read only condition before beginning write out
From: Namjae Jeon If the filesystem is mounted as read-only then return from that point itself instead of first doing a writeout/wait and then checking for read-only condition. Signed-off-by: Namjae Jeon Signed-off-by: Amit Sahrawat --- fs/f2fs/file.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index c1a108f..89241c5 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -132,14 +132,15 @@ int f2fs_sync_file(struct file *file, loff_t start, loff_t end, int datasync) .for_reclaim = 0, }; + if (inode->i_sb->s_flags & MS_RDONLY) + return 0; + ret = filemap_write_and_wait_range(inode->i_mapping, start, end); if (ret) return ret; mutex_lock(&inode->i_mutex); - if (inode->i_sb->s_flags & MS_RDONLY) - goto out; if (datasync && !(inode->i_state & I_DIRTY_DATASYNC)) goto out; -- 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 3/6] f2fs: remove unneeded memset from init_once
From: Namjae Jeon
Since, __GFP_ZERO is used while f2fs inode allocation, so we do not
need memset for f2fs_inode_info, as this is already zeroed out.
Signed-off-by: Namjae Jeon
Signed-off-by: Amit Sahrawat
---
fs/f2fs/super.c |1 -
1 file changed, 1 deletion(-)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index c72e517..41ed943 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -57,7 +57,6 @@ static void init_once(void *foo)
{
struct f2fs_inode_info *fi = (struct f2fs_inode_info *) foo;
- memset(fi, 0, sizeof(*fi));
inode_init_once(&fi->vfs_inode);
}
--
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 2/6] f2fs: show error in case of invalid mount arguments
From: Namjae Jeon
print the invalid argument/value from parse_options in case of
mount failure.
Signed-off-by: Namjae Jeon
Signed-off-by: Amit Sahrawat
---
fs/f2fs/super.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 4360600..c72e517 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -311,6 +311,8 @@ static int parse_options(struct f2fs_sb_info *sbi, char
*options)
set_opt(sbi, DISABLE_EXT_IDENTIFY);
break;
default:
+ pr_err("Unrecognized mount option \"%s\" or missing
value\n",
+ p);
return -EINVAL;
}
}
--
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 1/6] f2fs: fix the compiler warning for uninitialized use of variable
From: Namjae Jeon When CONFIG_CC_OPTIMIZE_FOR_SIZE is enabled in the kernel, -Os optimisation flag is passed to gcc for compilation, and somehow while trying to optimize the code, compiler is might not able to see the initialisation of variable ne struct variable inside the get_node_info() function and results into following warning: fs/f2fs/node.c: In function 'get_node_info': fs/f2fs/node.c:175:3: warning: 'ne.block_addr' may be used uninitialized in this function [-Wuninitialized] fs/f2fs/node.c:265:24: note: 'ne.block_addr' was declared here fs/f2fs/node.c:176:3: warning: 'ne.ino' may be used uninitialized in this function [-Wuninitialized] fs/f2fs/node.c:265:24: note: 'ne.ino' was declared here fs/f2fs/node.c:177:3: warning: 'ne.version' may be used uninitialized in this function [-Wuninitialized] fs/f2fs/node.c:265:24: note: 'ne.version' was declared here Hence, lets initialise the ne struct variable to zero, which will remove this warning and also doing this does not seems to making any impact on the code behavior. Signed-off-by: Namjae Jeon Signed-off-by: Pankaj Kumar --- fs/f2fs/node.c |1 + 1 file changed, 1 insertion(+) diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c index 25d3036..1987036 100644 --- a/fs/f2fs/node.c +++ b/fs/f2fs/node.c @@ -266,6 +266,7 @@ void get_node_info(struct f2fs_sb_info *sbi, nid_t nid, struct node_info *ni) struct nat_entry *e; int i; + memset(&ne, 0, sizeof(struct f2fs_nat_entry)); ni->nid = nid; /* Check nat cache */ -- 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]realtek:r8169: Bugfix or workaround for missing extended GigaMAC registers settings
On Fri, Nov 30, 2012 at 06:00:02PM +0800, Wang YanQing wrote: > I found the mainline's r8169 works the same as realtek's driver, > the first time don't work, but it works after reboot, the reason > is the pci driver's shutdown don't call rtl_rar_set in 3.0 stable > tree but the mainline does. Sorry, I make a mistake here, the boths pci driver's shutdown call rtl_rar_set, but 3.0 stable tree don't include commit c28aa38567101bad4e020f4392df41d0bf6c165c(r8169 : MAC address change fix for the 8168e-vl) 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] uio.c: Fix warning: 'ret' might be used uninitialized
On Fri, Nov 30, 2012 at 10:33 PM, Hans J. Koch wrote:
> On Fri, Nov 30, 2012 at 12:12:46PM +0100, Tux9 wrote:
>> I like Vitalii's solution more. Hans's solution assign the value
>> -ENOMEM to ret in every round of the loop, which is a kind of wasting
>> CPU cycles.
>
> The difference between
> 1 files changed, 12 insertions(+), 4 deletions(-) and
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> is more important. Note that this code is not in a fast path but only
> called once at device creation.
Why do you think the size of the patch is so important? I think the
most important thing is the coding style and efficiency. I agree
efficiency is not important in this case, but what about coding style?
Your code is _not_ very easy to understand. It's a very natural thing
to set the return value and then goto the error-handling codes, which
is exactly same as what Vitalii did, rather than setting an initial
value in the beginning of each round of the loop as you did. There are
also a bunch of codes in kernel in the same style with Vitalii, but I
cannot find anything same as your codes.
Cong
>
>>
>> On Fri, Nov 30, 2012 at 12:58 AM, Hans J. Koch wrote:
>> > On Thu, Nov 29, 2012 at 06:36:59PM +0200, Vitalii Demianets wrote:
>> >> > On Thursday 29 November 2012 18:05:27 Tux9 wrote:
>> >> > > Hans, I think there are something wrong in your patch, while Vitalii's
>> >> > > is right. The variable "ret" is reused in line 292 and line 295, so
>> >> > > the value of "ret" would be overridden (if it goto err_map in line 284
>> >> > > when mi>=1).
>> >> >
>> >> > Actually, both patches do exactly the same thing. Hans's patch
>> >> > establishes
>> >> > default value for the ret for all those "other" cases when ret is not
>> >> > explicitly overridden. My patch explicitly enumerates all those "other"
>> >> > cases in more wordily manner.
>> >> >
>> >>
>> >> Oops, disregard this. After looking at it more thoroughly I got your
>> >> point.
>> >> You are right, ret is overridden at first iteration (mi == 0), so Hans's
>> >> approach does not work.
>> >> I must do more thinking before replying in a hurry.
>> >
>> > You're right. Initialization of "ret" has to take place at the beginning of
>> > the loop.
>> >
>> > I think this version is right:
>> >
>> >
>> > From 00c3c734c0dde67873a628bcb18cee403c95c301 Mon Sep 17 00:00:00 2001
>> > From: "Hans J. Koch"
>> > Date: Fri, 30 Nov 2012 00:51:50 +0100
>> > Subject: [PATCH] uio: Fix warning: 'ret' might be used uninitialized
>> >
>> > In two cases, the return value variable "ret" can be undefined.
>> >
>> > Signed-off-by: Hans J. Koch
>> > ---
>> > drivers/uio/uio.c |2 ++
>> > 1 files changed, 2 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
>> > index 5110f36..0c80df2 100644
>> > --- a/drivers/uio/uio.c
>> > +++ b/drivers/uio/uio.c
>> > @@ -273,6 +273,7 @@ static int uio_dev_add_attributes(struct uio_device
>> > *idev)
>> > struct uio_portio *portio;
>> >
>> > for (mi = 0; mi < MAX_UIO_MAPS; mi++) {
>> > + ret = -ENOMEM;
>> > mem = &idev->info->mem[mi];
>> > if (mem->size == 0)
>> > break;
>> > @@ -298,6 +299,7 @@ static int uio_dev_add_attributes(struct uio_device
>> > *idev)
>> > }
>> >
>> > for (pi = 0; pi < MAX_UIO_PORT_REGIONS; pi++) {
>> > + ret = -ENOMEM;
>> > port = &idev->info->port[pi];
>> > if (port->size == 0)
>> > break;
>> > --
>> > 1.7.9
>> >
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> > the body of a message to majord...@vger.kernel.org
>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>> > Please read the FAQ at http://www.tux.org/lkml/
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
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] Avoid dead lock of console related locks in panic case
> What I actually meant was: can "this" CPU avoid stopping other CPUs so early? > If we stop the other CPUs when this CPU is ready to > stop itself then there will never be such deadlocks. Let me explain my opinion. When we focus on the deadlock only, the code will be simple by moving smp_send_stop() at the end of panic(). But, panic situation is not normal. I don't think that keeping running multiple cpus is safe, because they may touch corrupted data/variables and unnecessary panic/BUG() may happen. IMO, cpus should be stopped "as early as" possible when panic happens. And then panic() has to take minimal steps with a single cpu. - output messages - kicking troubleshooting features like kdump/kmsg_dump Seiji -- 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] Documentation: Enumerate the guidelines for stable patches.
Greg KH writes: > Is this really needed? For the large majority of the stable > patches, specifically enumerating this isn't a big deal, it's a tiny > patch, and if you think I'll remember to tell you which specific > clause you didn't follow, then you think I have more spare time than > I really do. Yeah, it was largely tongue-in-cheek. :) Although a hint of "not upstream" would have been helpful. You obviously have the checklist in your head, and you (presumably) have a your formletter automated; it just seems that, as busy as the maintainers are, trading an extra 2s of your time for an hour of a contributor's time would sometimes be the right thing. Regardless, you're the one doing the work, not me. (And you're an outright angel, compared to some other high-level maintainers, so I should simply count myself lucky.) > Sorry, but no, I don't think this patch is ok, especially that S15 > clause, nice try :) Can't fault a guy for trying. (Or, hopefully, can't fault him much...) Have a good weekend, t. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] v3.0.x: mtd: check partition count not partition array pointer
Greg -- Thanks for the very quick response. Greg KH writes: > This is an obvious one, it needs to be upstream first. > > Or if not, a whole lot of explaination saying that you know it > isn't, and why it isn't, and why it isn't applicable there, I thought that I did provide exactly this information, when I indicated that this function no longer even existed in upstream. The replacement in upstream was to fold this functionality into another function -- but I found that function much more complex and difficult to follow. So I went with the simple fix. > including agreement from the subsystem maintainers saying that they > agree with you. I also don't have that. I might post it to the mtd list, to see if they have any interest in either approving it as-is for 3.0 series, or doing the backport of the current code. Thanks again for your time. Tony -- 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: [tip:x86/microcode] x86/microcode_intel_early.c: Early update ucode on Intel's CPU
On Fri, Nov 30, 2012 at 4:25 PM, tip-bot for Fenghua Yu
wrote:
> Commit-ID: 474355fe313391de2429ae225e0fb02f67ec6c31
> Gitweb: http://git.kernel.org/tip/474355fe313391de2429ae225e0fb02f67ec6c31
> Author: Fenghua Yu
> AuthorDate: Thu, 29 Nov 2012 17:47:43 -0800
> Committer: H. Peter Anvin
> CommitDate: Fri, 30 Nov 2012 15:18:16 -0800
>
> x86/microcode_intel_early.c: Early update ucode on Intel's CPU
>
> Implementation of early update ucode on Intel's CPU.
>
> load_ucode_intel_bsp() scans ucode in initrd image file which is a cpio format
> ucode followed by ordinary initrd image file. The binary ucode file is stored
> in kernel/x86/microcode/GenuineIntel/microcode.bin in the cpio data. All ucode
> patches with the same model as BSP are saved in memory. A matching ucode patch
> is updated on BSP.
>
> load_ucode_intel_ap() reads saved ucoded patches and updates ucode on AP.
>
> Signed-off-by: Fenghua Yu
> Link:
> http://lkml.kernel.org/r/1354240068-9821-6-git-send-email-fenghua...@intel.com
> Signed-off-by: H. Peter Anvin
> ---
> arch/x86/kernel/microcode_intel_early.c | 438
>
> 1 file changed, 438 insertions(+)
>
> diff --git a/arch/x86/kernel/microcode_intel_early.c
> b/arch/x86/kernel/microcode_intel_early.c
> new file mode 100644
> index 000..36b1df1
> --- /dev/null
> +++ b/arch/x86/kernel/microcode_intel_early.c
> @@ -0,0 +1,438 @@
> +/*
> + * Intel CPU Microcode Update Driver for Linux
> + *
> + * Copyright (C) 2012 Fenghua Yu
> + *H Peter Anvin"
> + *
> + * This driver allows to early upgrade microcode on Intel processors
> + * belonging to IA-32 family - PentiumPro, Pentium II,
> + * Pentium III, Xeon, Pentium 4, etc.
> + *
> + * Reference: Section 9.11 of Volume 3, IA-32 Intel Architecture
> + * Software Developer's Manual.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct microcode_intel __initdata *mc_saved_in_initrd[MAX_UCODE_COUNT];
> +struct mc_saved_data mc_saved_data;
> +
> +enum ucode_state
> +generic_load_microcode_early(int cpu, struct microcode_intel **mc_saved_p,
> +unsigned int mc_saved_count,
> +struct ucode_cpu_info *uci)
> +{
> + struct microcode_intel *ucode_ptr, *new_mc = NULL;
> + int new_rev = uci->cpu_sig.rev;
> + enum ucode_state state = UCODE_OK;
> + unsigned int mc_size;
> + struct microcode_header_intel *mc_header;
> + unsigned int csig = uci->cpu_sig.sig;
> + unsigned int cpf = uci->cpu_sig.pf;
> + int i;
> +
> + for (i = 0; i < mc_saved_count; i++) {
> + ucode_ptr = mc_saved_p[i];
> + mc_header = (struct microcode_header_intel *)ucode_ptr;
> + mc_size = get_totalsize(mc_header);
> + if (get_matching_microcode(csig, cpf, ucode_ptr, new_rev)) {
> + new_rev = mc_header->rev;
> + new_mc = ucode_ptr;
> + }
> + }
> +
> + if (!new_mc) {
> + state = UCODE_NFOUND;
> + goto out;
> + }
> +
> + uci->mc = (struct microcode_intel *)new_mc;
> +out:
> + return state;
> +}
> +EXPORT_SYMBOL_GPL(generic_load_microcode_early);
> +
> +static enum ucode_state __init
> +load_microcode(struct mc_saved_data *mc_saved_data, int cpu)
> +{
> + struct ucode_cpu_info *uci = mc_saved_data->ucode_cpu_info + cpu;
> +
> + return generic_load_microcode_early(cpu, mc_saved_data->mc_saved,
> + mc_saved_data->mc_saved_count,
> uci);
> +}
> +
> +static u8 get_x86_family(unsigned long sig)
> +{
> + u8 x86;
> +
> + x86 = (sig >> 8) & 0xf;
> +
> + if (x86 == 0xf)
> + x86 += (sig >> 20) & 0xff;
> +
> + return x86;
> +}
> +
> +static u8 get_x86_model(unsigned long sig)
> +{
> + u8 x86, x86_model;
> +
> + x86 = get_x86_family(sig);
> + x86_model = (sig >> 4) & 0xf;
> +
> + if (x86 == 0x6 || x86 == 0xf)
> + x86_model += ((sig >> 16) & 0xf) << 4;
> +
> + return x86_model;
> +}
> +
> +static enum ucode_state
> +matching_model_microcode(struct microcode_header_intel *mc_header,
> + unsigned long sig)
> +{
> + u8 x86, x86_model;
> + u8 x86_ucode, x86_model_ucode;
> +
> + x86 = get_x86_family(sig);
> + x86_model = get_x86_model(sig);
> +
> + x86_ucode = get_x86_family(mc_header->sig);
> + x86_model_ucode = get_x86_model(mc_header->sig);
> +
> + if (x86 != x86_ucode || x86_model != x86_model_ucode)
>
Re: [PATCH] Documentation: Enumerate the guidelines for stable patches.
On Fri, Nov 30, 2012 at 05:44:13PM -0700, Anthony Foiani wrote: > > From: Anthony Foiani > > Having recently received a formletter rejection on a stable patch, I > found it difficult to determine exactly which guideline I had missed. > > Numbering the guidelines will allow the stable maintainer to quickly > and easily indicate which guidelines have not been followed. > > The actual changes are only the addition of clause numbering, and the > wishful thinking added to S15. Is this really needed? For the large majority of the stable patches, specifically enumerating this isn't a big deal, it's a tiny patch, and if you think I'll remember to tell you which specific clause you didn't follow, then you think I have more spare time than I really do. Sorry, but no, I don't think this patch is ok, especially that S15 clause, nice try :) greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] of: When constructing the bus id consider assigned-addresses as well
On Fri, Nov 30, 2012 at 09:48:05AM +, Grant Likely wrote:
> > If you attempt to stick a 'reg' in a block nested below a
> > 'device_type="pci"' the kernel throws lots of error messsages and
> > generates bad address mappings.
>
> Have you added the appropriate #address-cells and #size-cells to the pci
> device node to go back to a non-pci addressing mode?
> assigned-addresses
Switching away from the 5 dword address format is not ideal
because then there is no way to specify the resource region (prefetch,
io, mmio) and mmio would have to be assumed.
> only makes sense in the pci-device node itself. reg should work for all
> nodes below that, and if it doesn't then it is a bug that we need to
> fix.
Okay.. but how should the DTS be constructed?
pcie_bus { // The PCI-E bus
device_type = "pci";
ranges = <5dw ranges>;
#address-cells = <3>;
#size-cells = <2>;
soc_bridge { // The PCI-E device
device_type = "pci";
ranges = <5dw ranges>;
soc_device { // Internal device
assigned-address = <5dw regs>
};
};
};
This is what I have now, the soc_bridge PCI-E device is DTS modeled as
a PCI bridge - it has a ranges with its memory location, and the
children nodes are relative to those ranges. This would not be typical
for a non-bridge PCI-E device.
The reason for the 'assigned-address' requirement with the current
kernel code is the device_type=pci on soc_bridge. This makes
of_match_bus(parent) for soc_device return the PCI structure, which
has '.addresses = "assigned-addresses",'
So.. how would you like this to look?
Jason
--
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: kswapd craziness in 3.7
Hi Thorsten, On Fri, Nov 30, 2012 at 01:39:03PM +0100, Thorsten Leemhuis wrote: > /me wonders how to elegantly get out of his man-in-the-middle position You control the mighty koji :-) But seriously, this is very helpful, thank you! John now also Cc'd directly. > John was able to reproduce the problem quickly with a kernel that > contained the patch from your mail. For details see > > https://bugzilla.redhat.com/show_bug.cgi?id=866988#c42 and later > > He provided the informations there. Parts of it: > /proc/vmstat while kswad0 at 100%cpu > /proc/zoneinfo with kswapd0 at 100% cpu > perf profile Thanks. I'm quoting the interesting bits in order of the cars on my possibly derailing train of thought: > pageoutrun 117729182 > allocstall 5 Okay, so kswapd is stupidly looping but it's still managing to do it's actual job; nobody is dropping into direct reclaim. > pgsteal_kswapd_dma 1 > pgsteal_kswapd_normal 202106 > pgsteal_kswapd_high 36515 > pgsteal_kswapd_movable 0 > pgscan_kswapd_dma 1 > pgscan_kswapd_normal 203044 > pgscan_kswapd_high 40407 > pgscan_kswapd_movable 0 Does not seem excessive, so apparently it also does not overreclaim. > Node 0, zone DMA > pages free 1655 > min 196 > low 245 > high 294 > Node 0, zone Normal > pages free 186234 > min 10953 > low 13691 > high 16429 > Node 0, zone HighMem > pages free 8983 > min 34 > low 475 > high 917 These are all well above their watermarks, yet kswapd is definitely finding something wrong with one of these as it actually does drop into the reclaim loop, so zone_balanced() must be returning false: > 16.52% kswapd0 [kernel.kallsyms] [k] idr_get_next > > | > --- idr_get_next >| >|--99.76%-- css_get_next >| mem_cgroup_iter >| | >| |--50.49%-- shrink_zone >| | kswapd >| | kthread >| | ret_from_kernel_thread >| | >| --49.51%-- kswapd >| kthread >| ret_from_kernel_thread > --0.24%-- [...] > > 11.23% kswapd0 [kernel.kallsyms] [k] prune_super > > | > --- prune_super >| >|--86.74%-- shrink_slab >| kswapd >| kthread >| ret_from_kernel_thread >| > --13.26%-- kswapd > kthread > ret_from_kernel_thread Spending so much time in shrink_zone and shrink_slab without overreclaiming a zone, I would say that a) this always stays on the DEF_PRIORITY and b) only loops on the DMA zone. At DEF_PRIORITY, the scan goal for filepages in the other zones would be > 0 e.g. As the DMA zone watermarks are fine, it must be the fragmentation index that indicates a lack of memory. Filling in the 1655 free pages into the fragmentation index formula indicates lack of free memory when these 1655 pages are lumped together in less than 9 page blocks. Not unrealistic, I think: on my desktop machine, the DMA zone's free 3975 pages are lumped together in only 12 blocks. But on my system, the DMA zone is either never used and there is always at least one page block available that could satisfy a huge page allocation (fragmentation index == -1000). Unless the system gets really close to OOM, at which point the DMA zone is highly fragmented. And keep in mind that if the priority level goes below DEF_PRIORITY, as it does close to OOM, the unreclaimable DMA zone is ignored anyway. But the DMA zone here is just barely used: > Node 0, zone DMA [...] > nr_slab_reclaimable 3 > nr_slab_unreclaimable 1 [...] > nr_dirtied 315 > nr_written 315 which could explain a fragmentation index that asks for more free memory while the watermarks are fine. Why this all loops: there is one more inconsistency where the conditions for reclaim and the conditions for compaction contradict each other: reclaim also does not consider the DMA zone balanced, but it needs only 25% of the whole node to be balanced, while compaction requires every single zone to be balanced individually. So these strict per-zone checks for compaction at the end of balance_pgdat() are likely to be the culprits that keep kswapd looping forever on this machine, trying to balance DMA for compaction while reclaim decides it has enough balanced memory in the nod
[PATCH] Documentation: Enumerate the guidelines for stable patches.
From: Anthony Foiani Having recently received a formletter rejection on a stable patch, I found it difficult to determine exactly which guideline I had missed. Numbering the guidelines will allow the stable maintainer to quickly and easily indicate which guidelines have not been followed. The actual changes are only the addition of clause numbering, and the wishful thinking added to S15. Signed-Off-By: Anthony Foiani --- Documentation/stable_kernel_rules.txt | 185 -- 1 file changed, 108 insertions(+), 77 deletions(-) diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt index b0714d8..9a6dc59 100644 --- a/Documentation/stable_kernel_rules.txt +++ b/Documentation/stable_kernel_rules.txt @@ -1,95 +1,126 @@ Everything you ever wanted to know about Linux -stable releases. -Rules on what kind of patches are accepted, and which ones are not, into the -"-stable" tree: - - - It must be obviously correct and tested. - - It cannot be bigger than 100 lines, with context. - - It must fix only one thing. - - It must fix a real bug that bothers people (not a, "This could be a - problem..." type thing). - - It must fix a problem that causes a build error (but not for things - marked CONFIG_BROKEN), an oops, a hang, data corruption, a real - security issue, or some "oh, that's not good" issue. In short, something - critical. - - Serious issues as reported by a user of a distribution kernel may also - be considered if they fix a notable performance or interactivity issue. - As these fixes are not as obvious and have a higher risk of a subtle - regression they should only be submitted by a distribution kernel - maintainer and include an addendum linking to a bugzilla entry if it - exists and additional information on the user-visible impact. - - New device IDs and quirks are also accepted. - - No "theoretical race condition" issues, unless an explanation of how the - race can be exploited is also provided. - - It cannot contain any "trivial" fixes in it (spelling changes, - whitespace cleanups, etc). - - It must follow the Documentation/SubmittingPatches rules. - - It or an equivalent fix must already exist in Linus' tree (upstream). +Rules on what kind of patches are accepted, and which ones are not, +into the "-stable" tree. +S1. It must be obviously correct and tested. + +S2. It cannot be bigger than 100 lines, with context. + +S3. It must fix only one thing. + +S4. It must fix a real bug that bothers people (not a, "This could be + a problem..." type thing). + +S5. It must fix a problem that causes a build error (but not for + things marked CONFIG_BROKEN), an oops, a hang, data corruption, a + real security issue, or some "oh, that's not good" issue. In + short, something critical. + +S6. Serious issues as reported by a user of a distribution kernel may + also be considered if they fix a notable performance or + interactivity issue. As these fixes are not as obvious and have + a higher risk of a subtle regression they should only be + submitted by a distribution kernel maintainer and include an + addendum linking to a bugzilla entry if it exists and additional + information on the user-visible impact. + +S7. New device IDs and quirks are also accepted. + +S8. No "theoretical race condition" issues, unless an explanation of + how the race can be exploited is also provided. + +S9. It cannot contain any "trivial" fixes in it (spelling changes, + whitespace cleanups, etc). + +S10. It must follow the Documentation/SubmittingPatches rules. + +S11. It or an equivalent fix must already exist in Linus' tree + (upstream). Procedure for submitting patches to the -stable tree: - - Send the patch, after verifying that it follows the above rules, to - sta...@vger.kernel.org. You must note the upstream commit ID in the - changelog of your submission, as well as the kernel version you wish - it to be applied to. - - To have the patch automatically included in the stable tree, add the tag - Cc: sta...@vger.kernel.org - in the sign-off area. Once the patch is merged it will be applied to - the stable tree without anything else needing to be done by the author - or subsystem maintainer. - - If the patch requires other patches as prerequisites which can be - cherry-picked than this can be specified in the following format in - the sign-off area: - - Cc: # 3.3.x: a1f84a3: sched: Check for idle - Cc: # 3.3.x: 1b9508f: sched: Rate-limit newidle - Cc: # 3.3.x: fd21073: sched: Fix affinity logic - Cc: # 3.3.x -Signed-off-by: Ingo Molnar - - The tag sequence has the meaning of: - git cherry-pick a1f84a3 - git cherry-pick 1b9508f - git cherry-pick fd21073 - git cherry-pick - - - The sender will receive an ACK when the patch has been accepted into the - queue, or a NAK if the patch is rejected. This response
[tip:x86/nuke386] x86, 386 removal: Document Nx586 as a 386 and thus unsupported
Commit-ID: 11af32b69ef7ee64c7d8848cad71a6f3749d9e37 Gitweb: http://git.kernel.org/tip/11af32b69ef7ee64c7d8848cad71a6f3749d9e37 Author: H. Peter Anvin AuthorDate: Thu, 29 Nov 2012 13:28:39 -0800 Committer: H. Peter Anvin CommitDate: Thu, 29 Nov 2012 13:28:39 -0800 x86, 386 removal: Document Nx586 as a 386 and thus unsupported Per Alan Cox, Nx586 did not support WP in supervisor mode, making it a 386 by Linux kernel standards. As such, it is too unsupported now. Reported-by: Alan Cox Link: http://lkml.kernel.org/r/20121128205203.05868...@pyramind.ukuu.org.uk Signed-off-by: H. Peter Anvin --- arch/x86/Kconfig.cpu | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu index 423db71..c026cca 100644 --- a/arch/x86/Kconfig.cpu +++ b/arch/x86/Kconfig.cpu @@ -15,7 +15,7 @@ config M486 Note that the 386 is no longer supported, this includes AMD/Cyrix/Intel 386DX/DXL/SL/SLC/SX, Cyrix/TI 486DLC/DLC2, - and UMC 486SX-S. + UMC 486SX-S and the NexGen Nx586. The kernel will not necessarily run on earlier architectures than the one you have chosen, e.g. a Pentium optimized kernel will run on -- 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/
[tip:x86/nuke386] x86, cleanups: Simplify sync_core() in the case of no CPUID
Commit-ID: 45c39fb0cc20d24da08d5bb159f57d191098104d
Gitweb: http://git.kernel.org/tip/45c39fb0cc20d24da08d5bb159f57d191098104d
Author: H. Peter Anvin
AuthorDate: Wed, 28 Nov 2012 11:50:30 -0800
Committer: H. Peter Anvin
CommitDate: Thu, 29 Nov 2012 13:25:39 -0800
x86, cleanups: Simplify sync_core() in the case of no CPUID
Simplify the implementation of sync_core() for the case where we may
not have the CPUID instruction available.
[ v2: stylistic cleanup of the #else clause per suggestion by Borislav
Petkov. ]
Signed-off-by: H. Peter Anvin
Link:
http://lkml.kernel.org/r/1354132230-21854-9-git-send-email-...@linux.intel.com
Cc: Borislav Petkov
---
arch/x86/include/asm/processor.h | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 9a4ee46..b0d3e73 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -673,17 +673,28 @@ static inline void sync_core(void)
int tmp;
#ifdef CONFIG_M486
- if (boot_cpu_data.x86 < 5)
- /* There is no speculative execution.
-* jmp is a barrier to prefetching. */
- asm volatile("jmp 1f\n1:\n" ::: "memory");
- else
+ /*
+* Do a CPUID if available, otherwise do a jump. The jump
+* can conveniently enough be the jump around CPUID.
+*/
+ asm volatile("cmpl %2,%1\n\t"
+"jl 1f\n\t"
+"cpuid\n"
+"1:"
+: "=a" (tmp)
+: "rm" (boot_cpu_data.cpuid_level), "ri" (0), "0" (1)
+: "ebx", "ecx", "edx", "memory");
+#else
+ /*
+* CPUID is a barrier to speculative execution.
+* Prefetched instructions are automatically
+* invalidated when modified.
+*/
+ asm volatile("cpuid"
+: "=a" (tmp)
+: "0" (1)
+: "ebx", "ecx", "edx", "memory");
#endif
- /* cpuid is a barrier to speculative execution.
-* Prefetched instructions are automatically
-* invalidated when modified. */
- asm volatile("cpuid" : "=a" (tmp) : "0" (1)
-: "ebx", "ecx", "edx", "memory");
}
static inline void __monitor(const void *eax, unsigned long ecx,
--
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/
[tip:x86/nuke386] x86, 386 removal: Remove CONFIG_X86_WP_WORKS_OK
Commit-ID: a5c2a893dbd4956a72fb261e8790d19f67b52c99
Gitweb: http://git.kernel.org/tip/a5c2a893dbd4956a72fb261e8790d19f67b52c99
Author: H. Peter Anvin
AuthorDate: Wed, 28 Nov 2012 11:50:28 -0800
Committer: H. Peter Anvin
CommitDate: Thu, 29 Nov 2012 13:23:03 -0800
x86, 386 removal: Remove CONFIG_X86_WP_WORKS_OK
All 486+ CPUs support WP in supervisor mode, so remove the fallback
386 support code.
Signed-off-by: H. Peter Anvin
Link:
http://lkml.kernel.org/r/1354132230-21854-7-git-send-email-...@linux.intel.com
---
arch/x86/Kconfig.cpu | 3 ---
arch/x86/include/asm/uaccess.h | 42 ---
arch/x86/lib/usercopy_32.c | 57 --
arch/x86/mm/init_32.c | 5 +---
4 files changed, 1 insertion(+), 106 deletions(-)
diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index d3bdc18..159ee9c 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -325,9 +325,6 @@ config X86_INVD_BUG
def_bool y
depends on M486
-config X86_WP_WORKS_OK
- def_bool y
-
config X86_POPAD_OK
def_bool y
depends on X86_32
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index 7ccf8d1..1709801 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -237,8 +237,6 @@ extern void __put_user_2(void);
extern void __put_user_4(void);
extern void __put_user_8(void);
-#ifdef CONFIG_X86_WP_WORKS_OK
-
/**
* put_user: - Write a simple value into user space.
* @x: Value to copy to user space.
@@ -326,29 +324,6 @@ do {
\
} \
} while (0)
-#else
-
-#define __put_user_size(x, ptr, size, retval, errret) \
-do { \
- __typeof__(*(ptr))__pus_tmp = x;\
- retval = 0; \
- \
- if (unlikely(__copy_to_user_ll(ptr, &__pus_tmp, size) != 0))\
- retval = errret;\
-} while (0)
-
-#define put_user(x, ptr) \
-({ \
- int __ret_pu; \
- __typeof__(*(ptr))__pus_tmp = x;\
- __ret_pu = 0; \
- if (unlikely(__copy_to_user_ll(ptr, &__pus_tmp, \
- sizeof(*(ptr))) != 0)) \
- __ret_pu = -EFAULT; \
- __ret_pu; \
-})
-#endif
-
#ifdef CONFIG_X86_32
#define __get_user_asm_u64(x, ptr, retval, errret) (x) = __get_user_bad()
#define __get_user_asm_ex_u64(x, ptr) (x) = __get_user_bad()
@@ -543,29 +518,12 @@ struct __large_struct { unsigned long buf[100]; };
(x) = (__force __typeof__(*(ptr)))__gue_val;\
} while (0)
-#ifdef CONFIG_X86_WP_WORKS_OK
-
#define put_user_try uaccess_try
#define put_user_catch(err)uaccess_catch(err)
#define put_user_ex(x, ptr)\
__put_user_size_ex((__typeof__(*(ptr)))(x), (ptr), sizeof(*(ptr)))
-#else /* !CONFIG_X86_WP_WORKS_OK */
-
-#define put_user_try do {\
- int __uaccess_err = 0;
-
-#define put_user_catch(err)\
- (err) |= __uaccess_err; \
-} while (0)
-
-#define put_user_ex(x, ptr)do {\
- __uaccess_err |= __put_user(x, ptr);\
-} while (0)
-
-#endif /* CONFIG_X86_WP_WORKS_OK */
-
extern unsigned long
copy_from_user_nmi(void *to, const void __user *from, unsigned long n);
extern __must_check long
diff --git a/arch/x86/lib/usercopy_32.c b/arch/x86/lib/usercopy_32.c
index 98f6d6b6..f0312d7 100644
--- a/arch/x86/lib/usercopy_32.c
+++ b/arch/x86/lib/usercopy_32.c
@@ -570,63 +570,6 @@ do {
\
unsigned long __copy_to_user_ll(void __user *to, const void *from,
unsigned long n)
{
-#ifndef CONFIG_X86_WP_WORKS_OK
- if (unlikely(boot_cpu_data.wp_works_ok == 0) &&
- ((unsigned long)to) < TASK_SIZE) {
- /*
-* When we are in an atomic section (see
-* mm/filemap.c:file_read_actor), return the full
-* length to take the slow path.
-*/
- if (in_atomic())
- return n;
-
- /*
-* CPU does not honor the WP bit when writing
-* from supervisory mode, and
[tip:x86/nuke386] x86, 386 removal: Remove CONFIG_INVLPG
Commit-ID: 094ab1db7cb7833cd4c820acd868fc26acf3f08e
Gitweb: http://git.kernel.org/tip/094ab1db7cb7833cd4c820acd868fc26acf3f08e
Author: H. Peter Anvin
AuthorDate: Wed, 28 Nov 2012 11:50:27 -0800
Committer: H. Peter Anvin
CommitDate: Thu, 29 Nov 2012 13:23:02 -0800
x86, 386 removal: Remove CONFIG_INVLPG
All 486+ CPUs support INVLPG, so remove the fallback 386 support
code.
Signed-off-by: H. Peter Anvin
Link:
http://lkml.kernel.org/r/1354132230-21854-6-git-send-email-...@linux.intel.com
---
arch/x86/Kconfig.cpu | 4
arch/x86/include/asm/cpufeature.h | 6 --
arch/x86/include/asm/tlbflush.h | 3 ---
arch/x86/kernel/cpu/amd.c | 3 ---
arch/x86/kernel/cpu/intel.c | 4
arch/x86/mm/tlb.c | 8 +++-
6 files changed, 3 insertions(+), 25 deletions(-)
diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index 8e5867c..d3bdc18 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -328,10 +328,6 @@ config X86_INVD_BUG
config X86_WP_WORKS_OK
def_bool y
-config X86_INVLPG
- def_bool y
- depends on X86_32
-
config X86_POPAD_OK
def_bool y
depends on X86_32
diff --git a/arch/x86/include/asm/cpufeature.h
b/arch/x86/include/asm/cpufeature.h
index 8c297aa..ff8dd62 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -312,12 +312,6 @@ extern const char * const x86_power_flags[32];
#define cpu_has_cx16 boot_cpu_has(X86_FEATURE_CX16)
#define cpu_has_eager_fpu boot_cpu_has(X86_FEATURE_EAGER_FPU)
-#if defined(CONFIG_X86_INVLPG) || defined(CONFIG_X86_64)
-# define cpu_has_invlpg1
-#else
-# define cpu_has_invlpg(boot_cpu_data.x86 > 3)
-#endif
-
#ifdef CONFIG_X86_64
#undef cpu_has_vme
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index 74a4433..0fee48e 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -56,10 +56,7 @@ static inline void __flush_tlb_all(void)
static inline void __flush_tlb_one(unsigned long addr)
{
- if (cpu_has_invlpg)
__flush_tlb_single(addr);
- else
- __flush_tlb();
}
#define TLB_FLUSH_ALL -1UL
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 1b7d165..a025d8c 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -753,9 +753,6 @@ static unsigned int __cpuinit amd_size_cache(struct
cpuinfo_x86 *c,
static void __cpuinit cpu_set_tlb_flushall_shift(struct cpuinfo_x86 *c)
{
- if (!cpu_has_invlpg)
- return;
-
tlb_flushall_shift = 5;
if (c->x86 <= 0x11)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 198e019..fcaabd0 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -612,10 +612,6 @@ static void __cpuinit intel_tlb_lookup(const unsigned char
desc)
static void __cpuinit intel_tlb_flushall_shift_set(struct cpuinfo_x86 *c)
{
- if (!cpu_has_invlpg) {
- tlb_flushall_shift = -1;
- return;
- }
switch ((c->x86 << 8) + c->x86_model) {
case 0x60f: /* original 65 nm celeron/pentium/core2/xeon,
"Merom"/"Conroe" */
case 0x616: /* single-core 65 nm celeron/core2solo "Merom-L"/"Conroe-L"
*/
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 60f926c..13a6b29 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -104,7 +104,7 @@ static void flush_tlb_func(void *info)
return;
if (this_cpu_read(cpu_tlbstate.state) == TLBSTATE_OK) {
- if (f->flush_end == TLB_FLUSH_ALL || !cpu_has_invlpg)
+ if (f->flush_end == TLB_FLUSH_ALL)
local_flush_tlb();
else if (!f->flush_end)
__flush_tlb_single(f->flush_start);
@@ -337,10 +337,8 @@ static const struct file_operations fops_tlbflush = {
static int __cpuinit create_tlb_flushall_shift(void)
{
- if (cpu_has_invlpg) {
- debugfs_create_file("tlb_flushall_shift", S_IRUSR | S_IWUSR,
- arch_debugfs_dir, NULL, &fops_tlbflush);
- }
+ debugfs_create_file("tlb_flushall_shift", S_IRUSR | S_IWUSR,
+ arch_debugfs_dir, NULL, &fops_tlbflush);
return 0;
}
late_initcall(create_tlb_flushall_shift);
--
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/
[tip:x86/nuke386] x86, 386 removal: Remove CONFIG_XADD
Commit-ID: 7ac468b1300f35143a9b5b100e3970ca7ae1d9b8
Gitweb: http://git.kernel.org/tip/7ac468b1300f35143a9b5b100e3970ca7ae1d9b8
Author: H. Peter Anvin
AuthorDate: Wed, 28 Nov 2012 11:50:25 -0800
Committer: H. Peter Anvin
CommitDate: Thu, 29 Nov 2012 13:23:02 -0800
x86, 386 removal: Remove CONFIG_XADD
All 486+ CPUs support XADD, so remove the fallback 386 support
code.
Signed-off-by: H. Peter Anvin
Link:
http://lkml.kernel.org/r/1354132230-21854-4-git-send-email-...@linux.intel.com
---
arch/x86/Kconfig | 5 -
arch/x86/Kconfig.cpu | 3 ---
arch/x86/include/asm/atomic.h | 16
arch/x86/include/asm/local.h | 18 +-
arch/x86/um/Kconfig | 2 +-
5 files changed, 2 insertions(+), 42 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index a1a6627..631b298 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -171,13 +171,8 @@ config ARCH_MAY_HAVE_PC_FDC
def_bool y
depends on ISA_DMA_API
-config RWSEM_GENERIC_SPINLOCK
- def_bool y
- depends on !X86_XADD
-
config RWSEM_XCHGADD_ALGORITHM
def_bool y
- depends on X86_XADD
config GENERIC_CALIBRATE_DELAY
def_bool y
diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index 1290a69..52955ee 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -304,9 +304,6 @@ config X86_L1_CACHE_SHIFT
default "4" if MELAN || M486 || MGEODEGX1
default "5" if MWINCHIP3D || MWINCHIPC6 || MCRUSOE || MEFFICEON ||
MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC ||
M586 || MVIAC3_2 || MGEODE_LX
-config X86_XADD
- def_bool y
-
config X86_PPRO_FENCE
bool "PentiumPro memory ordering errata workaround"
depends on M686 || M586MMX || M586TSC || M586 || M486 || MGEODEGX1
diff --git a/arch/x86/include/asm/atomic.h b/arch/x86/include/asm/atomic.h
index b6c3b82..722aa3b 100644
--- a/arch/x86/include/asm/atomic.h
+++ b/arch/x86/include/asm/atomic.h
@@ -172,23 +172,7 @@ static inline int atomic_add_negative(int i, atomic_t *v)
*/
static inline int atomic_add_return(int i, atomic_t *v)
{
-#ifdef CONFIG_M386
- int __i;
- unsigned long flags;
- if (unlikely(boot_cpu_data.x86 <= 3))
- goto no_xadd;
-#endif
- /* Modern 486+ processor */
return i + xadd(&v->counter, i);
-
-#ifdef CONFIG_M386
-no_xadd: /* Legacy 386 processor */
- raw_local_irq_save(flags);
- __i = atomic_read(v);
- atomic_set(v, i + __i);
- raw_local_irq_restore(flags);
- return i + __i;
-#endif
}
/**
diff --git a/arch/x86/include/asm/local.h b/arch/x86/include/asm/local.h
index c8bed0d..2d89e39 100644
--- a/arch/x86/include/asm/local.h
+++ b/arch/x86/include/asm/local.h
@@ -124,27 +124,11 @@ static inline int local_add_negative(long i, local_t *l)
*/
static inline long local_add_return(long i, local_t *l)
{
- long __i;
-#ifdef CONFIG_M386
- unsigned long flags;
- if (unlikely(boot_cpu_data.x86 <= 3))
- goto no_xadd;
-#endif
- /* Modern 486+ processor */
- __i = i;
+ long __i = i;
asm volatile(_ASM_XADD "%0, %1;"
: "+r" (i), "+m" (l->a.counter)
: : "memory");
return i + __i;
-
-#ifdef CONFIG_M386
-no_xadd: /* Legacy 386 processor */
- local_irq_save(flags);
- __i = local_read(l);
- local_set(l, i + __i);
- local_irq_restore(flags);
- return i + __i;
-#endif
}
static inline long local_sub_return(long i, local_t *l)
diff --git a/arch/x86/um/Kconfig b/arch/x86/um/Kconfig
index 0761175..b0c30da 100644
--- a/arch/x86/um/Kconfig
+++ b/arch/x86/um/Kconfig
@@ -31,7 +31,7 @@ config X86_64
select MODULES_USE_ELF_RELA
config RWSEM_XCHGADD_ALGORITHM
- def_bool X86_XADD && 64BIT
+ def_bool 64BIT
config RWSEM_GENERIC_SPINLOCK
def_bool !RWSEM_XCHGADD_ALGORITHM
--
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/
[tip:x86/nuke386] x86, 386 removal: Remove CONFIG_CMPXCHG
Commit-ID: d55c5a93db2d5fa95f233ab153f594365d95b777
Gitweb: http://git.kernel.org/tip/d55c5a93db2d5fa95f233ab153f594365d95b777
Author: H. Peter Anvin
AuthorDate: Wed, 28 Nov 2012 11:50:24 -0800
Committer: H. Peter Anvin
CommitDate: Thu, 29 Nov 2012 13:23:01 -0800
x86, 386 removal: Remove CONFIG_CMPXCHG
All 486+ CPUs support CMPXCHG, so remove the fallback 386 support
code.
Signed-off-by: H. Peter Anvin
Link:
http://lkml.kernel.org/r/1354132230-21854-3-git-send-email-...@linux.intel.com
---
arch/x86/Kconfig.cpu | 3 ---
arch/x86/include/asm/cmpxchg_32.h | 55 ---
arch/x86/include/asm/percpu.h | 3 ---
arch/x86/lib/Makefile | 1 -
arch/x86/lib/cmpxchg.c| 54 --
arch/x86/xen/Kconfig | 2 +-
6 files changed, 1 insertion(+), 117 deletions(-)
diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index 36a07eb..1290a69 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -297,9 +297,6 @@ config X86_INTERNODE_CACHE_SHIFT
default "12" if X86_VSMP
default X86_L1_CACHE_SHIFT
-config X86_CMPXCHG
- def_bool y
-
config X86_L1_CACHE_SHIFT
int
default "7" if MPENTIUM4 || MPSC
diff --git a/arch/x86/include/asm/cmpxchg_32.h
b/arch/x86/include/asm/cmpxchg_32.h
index 53f4b21..f8bf2ee 100644
--- a/arch/x86/include/asm/cmpxchg_32.h
+++ b/arch/x86/include/asm/cmpxchg_32.h
@@ -34,9 +34,7 @@ static inline void set_64bit(volatile u64 *ptr, u64 value)
: "memory");
}
-#ifdef CONFIG_X86_CMPXCHG
#define __HAVE_ARCH_CMPXCHG 1
-#endif
#ifdef CONFIG_X86_CMPXCHG64
#define cmpxchg64(ptr, o, n) \
@@ -73,59 +71,6 @@ static inline u64 __cmpxchg64_local(volatile u64 *ptr, u64
old, u64 new)
return prev;
}
-#ifndef CONFIG_X86_CMPXCHG
-/*
- * Building a kernel capable running on 80386. It may be necessary to
- * simulate the cmpxchg on the 80386 CPU. For that purpose we define
- * a function for each of the sizes we support.
- */
-
-extern unsigned long cmpxchg_386_u8(volatile void *, u8, u8);
-extern unsigned long cmpxchg_386_u16(volatile void *, u16, u16);
-extern unsigned long cmpxchg_386_u32(volatile void *, u32, u32);
-
-static inline unsigned long cmpxchg_386(volatile void *ptr, unsigned long old,
- unsigned long new, int size)
-{
- switch (size) {
- case 1:
- return cmpxchg_386_u8(ptr, old, new);
- case 2:
- return cmpxchg_386_u16(ptr, old, new);
- case 4:
- return cmpxchg_386_u32(ptr, old, new);
- }
- return old;
-}
-
-#define cmpxchg(ptr, o, n) \
-({ \
- __typeof__(*(ptr)) __ret; \
- if (likely(boot_cpu_data.x86 > 3)) \
- __ret = (__typeof__(*(ptr)))__cmpxchg((ptr),\
- (unsigned long)(o), (unsigned long)(n), \
- sizeof(*(ptr)));\
- else\
- __ret = (__typeof__(*(ptr)))cmpxchg_386((ptr), \
- (unsigned long)(o), (unsigned long)(n), \
- sizeof(*(ptr)));\
- __ret; \
-})
-#define cmpxchg_local(ptr, o, n) \
-({ \
- __typeof__(*(ptr)) __ret; \
- if (likely(boot_cpu_data.x86 > 3)) \
- __ret = (__typeof__(*(ptr)))__cmpxchg_local((ptr), \
- (unsigned long)(o), (unsigned long)(n), \
- sizeof(*(ptr)));\
- else\
- __ret = (__typeof__(*(ptr)))cmpxchg_386((ptr), \
- (unsigned long)(o), (unsigned long)(n), \
- sizeof(*(ptr)));\
- __ret; \
-})
-#endif
-
#ifndef CONFIG_X86_CMPXCHG64
/*
* Building a kernel capable running on 80386 and 80486. It may be necessary
diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
index 1104afa..0da5200 100644
--- a/arch/x86/include/asm/percpu.h
+++ b/arch/x86/include/asm/percpu.h
@@ -406,7 +406,6 @@ do {
\
#define this_cpu_xchg_2(pcp, nval) percpu_xchg_op(pcp, nval)
#define this_cpu_xch
[tip:x86/nuke386] x86, 386 removal: Remove CONFIG_M386 from Kconfig
Commit-ID: eb068e781020cf491333c773fb41820b57bfada4 Gitweb: http://git.kernel.org/tip/eb068e781020cf491333c773fb41820b57bfada4 Author: H. Peter Anvin AuthorDate: Wed, 28 Nov 2012 11:50:23 -0800 Committer: H. Peter Anvin CommitDate: Thu, 29 Nov 2012 13:23:01 -0800 x86, 386 removal: Remove CONFIG_M386 from Kconfig Remove the CONFIG_M386 symbol from Kconfig so that it cannot be selected. Signed-off-by: H. Peter Anvin Link: http://lkml.kernel.org/r/1354132230-21854-2-git-send-email-...@linux.intel.com --- arch/x86/Kconfig | 6 ++--- arch/x86/Kconfig.cpu | 58 arch/x86/Makefile_32.cpu | 1 - arch/x86/include/asm/module.h| 2 -- arch/x86/include/asm/processor.h | 2 +- 5 files changed, 27 insertions(+), 42 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 46c3bff..a1a6627 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -69,8 +69,8 @@ config X86 select HAVE_PERF_USER_STACK_DUMP select HAVE_DEBUG_KMEMLEAK select ANON_INODES - select HAVE_ALIGNED_STRUCT_PAGE if SLUB && !M386 - select HAVE_CMPXCHG_LOCAL if !M386 + select HAVE_ALIGNED_STRUCT_PAGE if SLUB + select HAVE_CMPXCHG_LOCAL select HAVE_CMPXCHG_DOUBLE select HAVE_ARCH_KMEMCHECK select HAVE_USER_RETURN_NOTIFIER @@ -1100,7 +1100,7 @@ config HIGHMEM4G config HIGHMEM64G bool "64GB" - depends on !M386 && !M486 + depends on !M486 select X86_PAE ---help--- Select this if you have a 32-bit processor and more than 4 diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu index f3b86d0..36a07eb 100644 --- a/arch/x86/Kconfig.cpu +++ b/arch/x86/Kconfig.cpu @@ -4,23 +4,24 @@ choice default M686 if X86_32 default GENERIC_CPU if X86_64 -config M386 - bool "386" - depends on X86_32 && !UML +config M486 + bool "486" + depends on X86_32 ---help--- - This is the processor type of your CPU. This information is used for - optimizing purposes. In order to compile a kernel that can run on - all x86 CPU types (albeit not optimally fast), you can specify - "386" here. + This is the processor type of your CPU. This information is + used for optimizing purposes. In order to compile a kernel + that can run on all supported x86 CPU types (albeit not + optimally fast), you can specify "486" here. + + Note that the 386 is no longer supported, this includes + AMD/Cyrix/Intel 386DX/DXL/SL/SLC/SX, Cyrix/TI 486DLC/DLC2, + and UMC 486SX-S. The kernel will not necessarily run on earlier architectures than the one you have chosen, e.g. a Pentium optimized kernel will run on a PPro, but not necessarily on a i486. Here are the settings recommended for greatest speed: - - "386" for the AMD/Cyrix/Intel 386DX/DXL/SL/SLC/SX, Cyrix/TI - 486DLC/DLC2, and UMC 486SX-S. Only "386" kernels will run on a 386 - class machine. - "486" for the AMD/Cyrix/IBM/Intel 486DX/DX2/DX4 or SL/SLC/SLC2/SLC3/SX/SX2 and UMC U5D or U5S. - "586" for generic Pentium CPUs lacking the TSC @@ -43,16 +44,7 @@ config M386 - "VIA C3-2" for VIA C3-2 "Nehemiah" (model 9 and above). - "VIA C7" for VIA C7. - If you don't know what to do, choose "386". - -config M486 - bool "486" - depends on X86_32 - ---help--- - Select this for a 486 series processor, either Intel or one of the - compatible processors from AMD, Cyrix, IBM, or Intel. Includes DX, - DX2, and DX4 variants; also SL/SLC/SLC2/SLC3/SX/SX2 and UMC U5D or - U5S. + If you don't know what to do, choose "486". config M586 bool "586/K5/5x86/6x86/6x86MX" @@ -307,22 +299,20 @@ config X86_INTERNODE_CACHE_SHIFT config X86_CMPXCHG def_bool y - depends on X86_64 || (X86_32 && !M386) config X86_L1_CACHE_SHIFT int default "7" if MPENTIUM4 || MPSC default "6" if MK7 || MK8 || MPENTIUMM || MCORE2 || MATOM || MVIAC7 || X86_GENERIC || GENERIC_CPU - default "4" if MELAN || M486 || M386 || MGEODEGX1 + default "4" if MELAN || M486 || MGEODEGX1 default "5" if MWINCHIP3D || MWINCHIPC6 || MCRUSOE || MEFFICEON || MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || M586 || MVIAC3_2 || MGEODE_LX config X86_XADD def_bool y - depends on !M386 config X86_PPRO_FENCE bool "PentiumPro memory ordering errata workaround" - depends on M686 || M586MMX || M586TSC || M586 || M486 || M386 || MGEODEGX1 + depends on M686 || M586MMX || M586TSC || M586 || M486 || MGEODEGX1 ---help--- Old PentiumPro multiprocessor systems had errata that could cause memory operations to violate the x8
Re: [PATCH 1/1] v3.0.x: mtd: check partition count not partition array pointer
On Fri, Nov 30, 2012 at 05:19:28PM -0700, Anthony Foiani wrote: > Greg KH writes: > > This is not the correct way to submit patches for inclusion in the > > stable kernel tree. Please read Documentation/stable_kernel_rules.txt > > for how to do this properly. > > My checklist against stable_kernel_rules.txt is below. > > I could only find two reasons why you are saying this is incorrect: > > 1. There is no matching upstream commit; or This is an obvious one, it needs to be upstream first. Or if not, a whole lot of explaination saying that you know it isn't, and why it isn't, and why it isn't applicable there, including agreement from the subsystem maintainers saying that they agree with you. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] v3.0.x: mtd: check partition count not partition array pointer
Greg KH writes:
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree. Please read Documentation/stable_kernel_rules.txt
> for how to do this properly.
My checklist against stable_kernel_rules.txt is below.
I could only find two reasons why you are saying this is incorrect:
1. There is no matching upstream commit; or
2. I did not CC: stable in the signed-off region.
Please let me know which it is, so I can either drop the subject (for
reasons indicated further below), or respin the patch.
Thanks,
Tony
| - It must be obviously correct and tested.
Check.
| - It cannot be bigger than 100 lines, with context.
Check: 1 changed line, 2 active lines in the patch, ~10 lines total.
| - It must fix only one thing.
Check.
| - It must fix a real bug that bothers people (not a, "This could be
| a problem..." type thing).
It bothered me (made my embedded project not boot correctly).
| - It must fix a problem that causes a build error (but not for
| things marked CONFIG_BROKEN), an oops, a hang, data corruption, a
| real security issue, or some "oh, that's not good" issue. In
| short, something critical.
It repaired a change in behavior; for my project that was a "oh,
that's not good" issue.
It booted, but in such a way that it failed to expose a critical
system resource correctly.
| - Serious issues as reported by a user of a distribution kernel [...]
Not applicable.
| - New device IDs and quirks are also accepted.
Not applicable.
| - No "theoretical race condition" issues [...]
Not applicable.
| - It cannot contain any "trivial" fixes in it [...]
Check.
| - It must follow the Documentation/SubmittingPatches rules.
As far as I can tell, this patch follows those rules.
| - It or an equivalent fix must already exist in Linus' tree (upstream).
As mentioned in the original submission:
>> The current kernel has retired this function; I have not examined
>> its replacement to see if it has the same issue.
You can either use this 1-line patch, or you can have someone else
backport the changes made in the mainline kernel. That someone will
not be me, sadly.
| Procedure for submitting patches to the -stable tree:
|
| - Send the patch, after verifying that it follows the above rules,
| to sta...@vger.kernel.org.
I thought I did this, but I'm guessing that you're complaining about:
| You must note the upstream commit ID in the changelog of your
| submission.
As mentioned above, there is no corresponding upstream commit, because
that function got removed.
I thought that my contribution was more in the spirit of the stable
series ("small, obvious, correct"); more so than would be the
backporting of the upstream fix.
But it's your call; if you disagree, then you disagree. My patch will
be here if other people need it.
| - To have the patch automatically included in the stable tree, add
| the tag
|
| Cc: sta...@vger.kernel.org
|
| in the sign-off area. Once the patch is merged it will be applied
| to the stable tree without anything else needing to be done by the
| author or subsystem maintainer.
I would be happy to resubmit with that modification, if you find the
other aspects of the patch acceptable.
With only the formletter response, I'm unable to determine which bits
you dislike.
| - If the patch requires other patches as prerequisites which can be
| cherry-picked than this can be specified in the following format
| [...]
Not applicable
| - The sender will receive an ACK when the patch has been accepted
| into the queue, or a NAK if the patch is rejected. This response
| might take a few days, according to the developer's schedules.
I received a NAK, and it was timely enough -- thank you. :)
| - If accepted, the patch will be added to the -stable queue, for
| review by other developers and by the relevant subsystem
| maintainer.
Presumably not applicable until you tell me why it was rejected; if it
is repairable, I'll be happy to resubmit.
| - Security patches should not be sent to this alias, but instead to the
| documented secur...@kernel.org address.
Not applicable.
...and I'll not belabor the point.
--
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 01/17] ARM: shmobile: fix memory size for kota2_defconfig
On Fri, Nov 30, 2012 at 02:10:47PM -0800, Olof Johansson wrote: > Hi, > > On Thu, Oct 4, 2012 at 1:58 AM, Simon Horman wrote: > > On Thu, Oct 04, 2012 at 08:34:54AM +, Arnd Bergmann wrote: > >> On Wednesday 03 October 2012, Simon Horman wrote: > >> > I looked through my fines and found a config that I believe > >> > worked with a derivative of 2.6.35.7. > >> > > >> > It has CONFIG_MEMORY_SIZE=0x1e80. > >> > > >> > So what I suspect has happened is that an extra zero has crept into > >> > arch/arm/configs/kota2_defconfig and the intended value is: > >> > > >> > CONFIG_MEMORY_SIZE=0x1e00 > >> > > >> > Unfortunately I do not have access to a board to test this, > >> > nor am I aware of anyone who does. > >> > >> Ok, I'll drop this patch for now then, so we keep the warning around > >> to remind us of the problem. > > > > Thanks. I have subsequently located a Kota2 board, > > however it may be a little while before I get my hands on it. > > Gentle ping. I just came across this warning again so I figured I'd check. Sorry, I still don't have a kota2 board. However, I expect to obtain one within the next week. -- 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/
[tip:x86/microcode] x86/microcode_intel_early.c: Early update ucode on Intel's CPU
Commit-ID: 474355fe313391de2429ae225e0fb02f67ec6c31
Gitweb: http://git.kernel.org/tip/474355fe313391de2429ae225e0fb02f67ec6c31
Author: Fenghua Yu
AuthorDate: Thu, 29 Nov 2012 17:47:43 -0800
Committer: H. Peter Anvin
CommitDate: Fri, 30 Nov 2012 15:18:16 -0800
x86/microcode_intel_early.c: Early update ucode on Intel's CPU
Implementation of early update ucode on Intel's CPU.
load_ucode_intel_bsp() scans ucode in initrd image file which is a cpio format
ucode followed by ordinary initrd image file. The binary ucode file is stored
in kernel/x86/microcode/GenuineIntel/microcode.bin in the cpio data. All ucode
patches with the same model as BSP are saved in memory. A matching ucode patch
is updated on BSP.
load_ucode_intel_ap() reads saved ucoded patches and updates ucode on AP.
Signed-off-by: Fenghua Yu
Link:
http://lkml.kernel.org/r/1354240068-9821-6-git-send-email-fenghua...@intel.com
Signed-off-by: H. Peter Anvin
---
arch/x86/kernel/microcode_intel_early.c | 438
1 file changed, 438 insertions(+)
diff --git a/arch/x86/kernel/microcode_intel_early.c
b/arch/x86/kernel/microcode_intel_early.c
new file mode 100644
index 000..36b1df1
--- /dev/null
+++ b/arch/x86/kernel/microcode_intel_early.c
@@ -0,0 +1,438 @@
+/*
+ * Intel CPU Microcode Update Driver for Linux
+ *
+ * Copyright (C) 2012 Fenghua Yu
+ *H Peter Anvin"
+ *
+ * This driver allows to early upgrade microcode on Intel processors
+ * belonging to IA-32 family - PentiumPro, Pentium II,
+ * Pentium III, Xeon, Pentium 4, etc.
+ *
+ * Reference: Section 9.11 of Volume 3, IA-32 Intel Architecture
+ * Software Developer's Manual.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct microcode_intel __initdata *mc_saved_in_initrd[MAX_UCODE_COUNT];
+struct mc_saved_data mc_saved_data;
+
+enum ucode_state
+generic_load_microcode_early(int cpu, struct microcode_intel **mc_saved_p,
+unsigned int mc_saved_count,
+struct ucode_cpu_info *uci)
+{
+ struct microcode_intel *ucode_ptr, *new_mc = NULL;
+ int new_rev = uci->cpu_sig.rev;
+ enum ucode_state state = UCODE_OK;
+ unsigned int mc_size;
+ struct microcode_header_intel *mc_header;
+ unsigned int csig = uci->cpu_sig.sig;
+ unsigned int cpf = uci->cpu_sig.pf;
+ int i;
+
+ for (i = 0; i < mc_saved_count; i++) {
+ ucode_ptr = mc_saved_p[i];
+ mc_header = (struct microcode_header_intel *)ucode_ptr;
+ mc_size = get_totalsize(mc_header);
+ if (get_matching_microcode(csig, cpf, ucode_ptr, new_rev)) {
+ new_rev = mc_header->rev;
+ new_mc = ucode_ptr;
+ }
+ }
+
+ if (!new_mc) {
+ state = UCODE_NFOUND;
+ goto out;
+ }
+
+ uci->mc = (struct microcode_intel *)new_mc;
+out:
+ return state;
+}
+EXPORT_SYMBOL_GPL(generic_load_microcode_early);
+
+static enum ucode_state __init
+load_microcode(struct mc_saved_data *mc_saved_data, int cpu)
+{
+ struct ucode_cpu_info *uci = mc_saved_data->ucode_cpu_info + cpu;
+
+ return generic_load_microcode_early(cpu, mc_saved_data->mc_saved,
+ mc_saved_data->mc_saved_count, uci);
+}
+
+static u8 get_x86_family(unsigned long sig)
+{
+ u8 x86;
+
+ x86 = (sig >> 8) & 0xf;
+
+ if (x86 == 0xf)
+ x86 += (sig >> 20) & 0xff;
+
+ return x86;
+}
+
+static u8 get_x86_model(unsigned long sig)
+{
+ u8 x86, x86_model;
+
+ x86 = get_x86_family(sig);
+ x86_model = (sig >> 4) & 0xf;
+
+ if (x86 == 0x6 || x86 == 0xf)
+ x86_model += ((sig >> 16) & 0xf) << 4;
+
+ return x86_model;
+}
+
+static enum ucode_state
+matching_model_microcode(struct microcode_header_intel *mc_header,
+ unsigned long sig)
+{
+ u8 x86, x86_model;
+ u8 x86_ucode, x86_model_ucode;
+
+ x86 = get_x86_family(sig);
+ x86_model = get_x86_model(sig);
+
+ x86_ucode = get_x86_family(mc_header->sig);
+ x86_model_ucode = get_x86_model(mc_header->sig);
+
+ if (x86 != x86_ucode || x86_model != x86_model_ucode)
+ return UCODE_ERROR;
+
+ return UCODE_OK;
+}
+
+static void
+save_microcode(struct mc_saved_data *mc_saved_data,
+ struct microcode_intel **mc_saved_src,
+ unsigned int mc_saved_count)
+{
+ int i;
+ struct microcode_intel **mc_saved_p;
+
+ if (!mc_saved_count)
+ return;
+
+
[tip:x86/microcode] x86/microcode_intel_lib.c: Early update ucode on Intel's CPU
Commit-ID: da7d824a00ec0f4d19e2b51653410bde0de40226
Gitweb: http://git.kernel.org/tip/da7d824a00ec0f4d19e2b51653410bde0de40226
Author: Fenghua Yu
AuthorDate: Thu, 29 Nov 2012 17:47:42 -0800
Committer: H. Peter Anvin
CommitDate: Fri, 30 Nov 2012 15:18:15 -0800
x86/microcode_intel_lib.c: Early update ucode on Intel's CPU
Define interfaces microcode_sanity_check() and get_matching_microcode(). They
are called both in early boot time and in microcode Intel driver.
Signed-off-by: Fenghua Yu
Link:
http://lkml.kernel.org/r/1354240068-9821-5-git-send-email-fenghua...@intel.com
Signed-off-by: H. Peter Anvin
---
arch/x86/kernel/microcode_intel_lib.c | 174 ++
1 file changed, 174 insertions(+)
diff --git a/arch/x86/kernel/microcode_intel_lib.c
b/arch/x86/kernel/microcode_intel_lib.c
new file mode 100644
index 000..ce69320
--- /dev/null
+++ b/arch/x86/kernel/microcode_intel_lib.c
@@ -0,0 +1,174 @@
+/*
+ * Intel CPU Microcode Update Driver for Linux
+ *
+ * Copyright (C) 2012 Fenghua Yu
+ *H Peter Anvin"
+ *
+ * This driver allows to upgrade microcode on Intel processors
+ * belonging to IA-32 family - PentiumPro, Pentium II,
+ * Pentium III, Xeon, Pentium 4, etc.
+ *
+ * Reference: Section 8.11 of Volume 3a, IA-32 Intel? Architecture
+ * Software Developer's Manual
+ * Order Number 253668 or free download from:
+ *
+ * http://developer.intel.com/Assets/PDF/manual/253668.pdf
+ *
+ * For more information, go to http://www.urbanmyth.org/microcode
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ */
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+static inline int
+update_match_cpu(unsigned int csig, unsigned int cpf,
+unsigned int sig, unsigned int pf)
+{
+ return (!sigmatch(sig, csig, pf, cpf)) ? 0 : 1;
+}
+
+int
+update_match_revision(struct microcode_header_intel *mc_header, int rev)
+{
+ return (mc_header->rev <= rev) ? 0 : 1;
+}
+
+int microcode_sanity_check(void *mc, int print_err)
+{
+ unsigned long total_size, data_size, ext_table_size;
+ struct microcode_header_intel *mc_header = mc;
+ struct extended_sigtable *ext_header = NULL;
+ int sum, orig_sum, ext_sigcount = 0, i;
+ struct extended_signature *ext_sig;
+
+ total_size = get_totalsize(mc_header);
+ data_size = get_datasize(mc_header);
+
+ if (data_size + MC_HEADER_SIZE > total_size) {
+ if (print_err)
+ pr_err("error! Bad data size in microcode data file\n");
+ return -EINVAL;
+ }
+
+ if (mc_header->ldrver != 1 || mc_header->hdrver != 1) {
+ if (print_err)
+ pr_err("error! Unknown microcode update format\n");
+ return -EINVAL;
+ }
+ ext_table_size = total_size - (MC_HEADER_SIZE + data_size);
+ if (ext_table_size) {
+ if ((ext_table_size < EXT_HEADER_SIZE)
+|| ((ext_table_size - EXT_HEADER_SIZE) % EXT_SIGNATURE_SIZE)) {
+ if (print_err)
+ pr_err("error! Small exttable size in microcode
data file\n");
+ return -EINVAL;
+ }
+ ext_header = mc + MC_HEADER_SIZE + data_size;
+ if (ext_table_size != exttable_size(ext_header)) {
+ if (print_err)
+ pr_err("error! Bad exttable size in microcode
data file\n");
+ return -EFAULT;
+ }
+ ext_sigcount = ext_header->count;
+ }
+
+ /* check extended table checksum */
+ if (ext_table_size) {
+ int ext_table_sum = 0;
+ int *ext_tablep = (int *)ext_header;
+
+ i = ext_table_size / DWSIZE;
+ while (i--)
+ ext_table_sum += ext_tablep[i];
+ if (ext_table_sum) {
+ if (print_err)
+ pr_warn("aborting, bad extended signature table
checksum\n");
+ return -EINVAL;
+ }
+ }
+
+ /* calculate the checksum */
+ orig_sum = 0;
+ i = (MC_HEADER_SIZE + data_size) / DWSIZE;
+ while (i--)
+ orig_sum += ((int *)mc)[i];
+ if (orig_sum) {
+ if (print_err)
+ pr_err("aborting, bad checksum\n");
+ return -EINVAL;
+ }
+ if (!ext_table_size)
+ return 0;
+ /* check extended signature checksum */
+ for (i = 0; i < ext_sigcount; i++) {
+ ext_sig = (void *)ext_header + EXT_HEADER_SIZE +
+
[tip:x86/microcode] x86/microcode_core_early.c: Define interfaces for early loading ucode
Commit-ID: d42bdf2139115faa4d5bdb0dc591d435a644fde4
Gitweb: http://git.kernel.org/tip/d42bdf2139115faa4d5bdb0dc591d435a644fde4
Author: Fenghua Yu
AuthorDate: Thu, 29 Nov 2012 17:47:41 -0800
Committer: H. Peter Anvin
CommitDate: Fri, 30 Nov 2012 15:18:15 -0800
x86/microcode_core_early.c: Define interfaces for early loading ucode
Define interfaces load_ucode_bsp() and load_ucode_ap() to load ucode on BSP and
AP in early boot time. These are generic interfaces. Internally they call
vendor specific implementations.
Signed-off-by: Fenghua Yu
Link:
http://lkml.kernel.org/r/1354240068-9821-4-git-send-email-fenghua...@intel.com
Signed-off-by: H. Peter Anvin
---
arch/x86/include/asm/microcode.h | 23 +++
arch/x86/kernel/microcode_core_early.c | 70 ++
2 files changed, 93 insertions(+)
diff --git a/arch/x86/include/asm/microcode.h b/arch/x86/include/asm/microcode.h
index 43d921b..2e2ff3a 100644
--- a/arch/x86/include/asm/microcode.h
+++ b/arch/x86/include/asm/microcode.h
@@ -57,4 +57,27 @@ static inline struct microcode_ops * __init
init_amd_microcode(void)
static inline void __exit exit_amd_microcode(void) {}
#endif
+struct mc_saved_data {
+ unsigned int mc_saved_count;
+ struct microcode_intel **mc_saved;
+ struct ucode_cpu_info *ucode_cpu_info;
+};
+#ifdef CONFIG_MICROCODE_EARLY
+#define MAX_UCODE_COUNT 128
+extern struct ucode_cpu_info ucode_cpu_info_early[NR_CPUS];
+extern struct microcode_intel __initdata *mc_saved_in_initrd[MAX_UCODE_COUNT];
+extern struct mc_saved_data mc_saved_data;
+extern void __init load_ucode_bsp(char *real_mode_data);
+extern __init void load_ucode_ap(void);
+extern void __init
+save_microcode_in_initrd(struct mc_saved_data *mc_saved_data,
+struct microcode_intel **mc_saved_in_initrd);
+#else
+static inline void __init load_ucode_bsp(char *real_mode_data) {}
+static inline __init void load_ucode_ap(void) {}
+static inline void __init
+save_microcode_in_initrd(struct mc_saved_data *mc_saved_data,
+struct microcode_intel **mc_saved_in_initrd) {}
+#endif
+
#endif /* _ASM_X86_MICROCODE_H */
diff --git a/arch/x86/kernel/microcode_core_early.c
b/arch/x86/kernel/microcode_core_early.c
new file mode 100644
index 000..1c6cc8f
--- /dev/null
+++ b/arch/x86/kernel/microcode_core_early.c
@@ -0,0 +1,70 @@
+/*
+ * X86 CPU microcode early update for Linux
+ *
+ * Copyright (C) 2012 Fenghua Yu
+ *H Peter Anvin"
+ *
+ * This driver allows to early upgrade microcode on Intel processors
+ * belonging to IA-32 family - PentiumPro, Pentium II,
+ * Pentium III, Xeon, Pentium 4, etc.
+ *
+ * Reference: Section 9.11 of Volume 3, IA-32 Intel Architecture
+ * Software Developer's Manual.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include
+#include
+#include
+#include
+
+struct ucode_cpu_info ucode_cpu_info_early[NR_CPUS];
+EXPORT_SYMBOL_GPL(ucode_cpu_info_early);
+
+static inline int __init x86_vendor(void)
+{
+ unsigned int eax = 0x;
+ char x86_vendor_id[16];
+ int i;
+ struct {
+ char x86_vendor_id[16];
+ __u8 x86_vendor;
+ } cpu_vendor_table[] = {
+ { "GenuineIntel", X86_VENDOR_INTEL },
+ { "AuthenticAMD", X86_VENDOR_AMD },
+ };
+
+ memset(x86_vendor_id, 0, ARRAY_SIZE(x86_vendor_id));
+ /* Get vendor name */
+ native_cpuid(&eax,
+ (unsigned int *)&x86_vendor_id[0],
+ (unsigned int *)&x86_vendor_id[8],
+ (unsigned int *)&x86_vendor_id[4]);
+
+ for (i = 0; i < ARRAY_SIZE(cpu_vendor_table); i++) {
+ if (!strcmp(x86_vendor_id, cpu_vendor_table[i].x86_vendor_id))
+ return cpu_vendor_table[i].x86_vendor;
+ }
+
+ return X86_VENDOR_UNKNOWN;
+}
+
+
+void __init load_ucode_bsp(char *real_mode_data)
+{
+ /*
+* boot_cpu_data is not setup yet in this early phase.
+* So we get vendor information directly through cpuid.
+*/
+ if (x86_vendor() == X86_VENDOR_INTEL)
+ load_ucode_intel_bsp(real_mode_data);
+}
+
+void __cpuinit load_ucode_ap(void)
+{
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)
+ load_ucode_intel_ap();
+}
--
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/
[tip:x86/microcode] x86/microcode_intel.h: Define functions and macros for early loading ucode
Commit-ID: 17f1087f1a80d2dfada790c31720eb6a57da2d1f
Gitweb: http://git.kernel.org/tip/17f1087f1a80d2dfada790c31720eb6a57da2d1f
Author: Fenghua Yu
AuthorDate: Thu, 29 Nov 2012 17:47:40 -0800
Committer: H. Peter Anvin
CommitDate: Fri, 30 Nov 2012 15:18:14 -0800
x86/microcode_intel.h: Define functions and macros for early loading ucode
Define some functions and macros that will be used in early loading ucode. Some
of them are moved from microcode_intel.c driver in order to be called in early
boot phase before module can be called.
Signed-off-by: Fenghua Yu
Link:
http://lkml.kernel.org/r/1354240068-9821-3-git-send-email-fenghua...@intel.com
Signed-off-by: H. Peter Anvin
---
arch/x86/include/asm/microcode_intel.h | 106 +++
arch/x86/kernel/Makefile | 3 +
arch/x86/kernel/microcode_core.c | 7 +-
arch/x86/kernel/microcode_intel.c | 185 ++---
4 files changed, 120 insertions(+), 181 deletions(-)
diff --git a/arch/x86/include/asm/microcode_intel.h
b/arch/x86/include/asm/microcode_intel.h
new file mode 100644
index 000..0544bf4
--- /dev/null
+++ b/arch/x86/include/asm/microcode_intel.h
@@ -0,0 +1,106 @@
+#ifndef _ASM_X86_MICROCODE_INTEL_H
+#define _ASM_X86_MICROCODE_INTEL_H
+
+#include
+
+struct microcode_header_intel {
+ unsigned inthdrver;
+ unsigned intrev;
+ unsigned intdate;
+ unsigned intsig;
+ unsigned intcksum;
+ unsigned intldrver;
+ unsigned intpf;
+ unsigned intdatasize;
+ unsigned inttotalsize;
+ unsigned intreserved[3];
+};
+
+struct microcode_intel {
+ struct microcode_header_intel hdr;
+ unsigned intbits[0];
+};
+
+/* microcode format is extended from prescott processors */
+struct extended_signature {
+ unsigned intsig;
+ unsigned intpf;
+ unsigned intcksum;
+};
+
+struct extended_sigtable {
+ unsigned intcount;
+ unsigned intcksum;
+ unsigned intreserved[3];
+ struct extended_signature sigs[0];
+};
+
+#define DEFAULT_UCODE_DATASIZE (2000)
+#define MC_HEADER_SIZE (sizeof(struct microcode_header_intel))
+#define DEFAULT_UCODE_TOTALSIZE (DEFAULT_UCODE_DATASIZE + MC_HEADER_SIZE)
+#define EXT_HEADER_SIZE(sizeof(struct extended_sigtable))
+#define EXT_SIGNATURE_SIZE (sizeof(struct extended_signature))
+#define DWSIZE (sizeof(u32))
+
+#define get_totalsize(mc) \
+ (((struct microcode_intel *)mc)->hdr.totalsize ? \
+((struct microcode_intel *)mc)->hdr.totalsize : \
+DEFAULT_UCODE_TOTALSIZE)
+
+#define get_datasize(mc) \
+ (((struct microcode_intel *)mc)->hdr.datasize ? \
+((struct microcode_intel *)mc)->hdr.datasize : DEFAULT_UCODE_DATASIZE)
+
+#define sigmatch(s1, s2, p1, p2) \
+ (((s1) == (s2)) && (((p1) & (p2)) || (((p1) == 0) && ((p2) == 0
+
+#define exttable_size(et) ((et)->count * EXT_SIGNATURE_SIZE + EXT_HEADER_SIZE)
+
+extern int
+get_matching_microcode(unsigned int csig, int cpf, void *mc, int rev);
+extern int microcode_sanity_check(void *mc, int print_err);
+extern int get_matching_sig(unsigned int csig, int cpf, void *mc, int rev);
+extern int
+update_match_revision(struct microcode_header_intel *mc_header, int rev);
+
+#ifdef CONFIG_MICROCODE_INTEL_EARLY
+extern enum ucode_state
+get_matching_model_microcode(int cpu, void *data, size_t size,
+struct mc_saved_data *mc_saved_data,
+struct microcode_intel **mc_saved_in_initrd,
+enum system_states system_state);
+extern enum ucode_state
+generic_load_microcode_early(int cpu, struct microcode_intel **mc_saved_p,
+unsigned int mc_saved_count,
+struct ucode_cpu_info *uci);
+extern void __init
+load_ucode_intel_bsp(char *real_mode_data);
+extern void __init load_ucode_intel_ap(void);
+#else
+static inline enum ucode_state
+get_matching_model_microcode(int cpu, void *data, size_t size,
+struct mc_saved_data *mc_saved_data,
+struct microcode_intel **mc_saved_in_initrd,
+enum system_states system_state)
+{
+ return UCODE_ERROR;
+}
+static inline enum ucode_state
+generic_load_microcode_early(int cpu, struct microcode_intel **mc_saved_p,
+unsigned int mc_saved_count,
+struct ucode_cpu_info *uci)
+{
+ return UCODE_ERROR;
+}
+static inline __init void
+load_ucode_intel_bsp(char *real_mode_data)
+{
+}
+static inline __init void
+load_ucode_intel_ap(struct ucode_cpu_info *uci,
+ struct mc_saved_data *mc_saved_data)
+{
+}
+#endif
+
+#endif /* _ASM_X86_MICROCO
[tip:x86/microcode] x86, doc: Early microcode loading
Commit-ID: 31ae1d90c127310c67618b8bd79f01c394116187 Gitweb: http://git.kernel.org/tip/31ae1d90c127310c67618b8bd79f01c394116187 Author: Fenghua Yu AuthorDate: Fri, 30 Nov 2012 07:45:51 -0800 Committer: H. Peter Anvin CommitDate: Fri, 30 Nov 2012 15:18:14 -0800 x86, doc: Early microcode loading Documenation for early microcode loading. Signed-off-by: Fenghua Yu Link: http://lkml.kernel.org/r/1354290351-20988-1-git-send-email-fenghua...@intel.com Signed-off-by: H. Peter Anvin --- Documentation/x86/early-microcode.txt | 43 +++ 1 file changed, 43 insertions(+) diff --git a/Documentation/x86/early-microcode.txt b/Documentation/x86/early-microcode.txt new file mode 100644 index 000..4aaf0df --- /dev/null +++ b/Documentation/x86/early-microcode.txt @@ -0,0 +1,43 @@ +Early load microcode + +By Fenghua Yu + +Kernel can update microcode in early phase of boot time. Loading microcode early +can fix CPU issues before they are observed during kernel boot time. + +Microcode is stored in an initrd file. The microcode is read from the initrd +file and loaded to CPUs during boot time. + +The format of the combined initrd image is microcode in cpio format followed by +the initrd image (maybe compressed). Kernel parses the combined initrd image +during boot time. The microcode file in cpio name space is: +kernel/x86/microcode/GenuineIntel.bin + +During BSP boot (before SMP starts), if the kernel finds the microcode file in +the initrd file, it parses the microcode and saves matching microcode in memory. +If matching microcode is found, it will be uploaded in BSP and later on in all +APs. + +The cached microcode patch is applied when CPUs resume from a sleep state. + +There are two legacy user space interfaces to load microcode, either through +/dev/cpu/microcode or through /sys/devices/system/cpu/microcode/reload file +in sysfs. + +In addition to these two legacy methods, the early loading method described +here is the third method with which microcode can be uploaded to a system's +CPUs. + +The following example script shows how to generate a new combined initrd file in +/boot/initrd-3.5.0.ucode.img with original microcode microcode.bin and +original initrd image /boot/initrd-3.5.0.img. + +mkdir initrd +cd initrd +mkdir kernel +mkdir kernel/x86 +mkdir kernel/x86/microcode +cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin +find .|cpio -oc >../ucode.cpio +cd .. +cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img -- 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] vfio powerpc: enabled on powernv platform
On 01/12/12 03:48, Alex Williamson wrote:
On Fri, 2012-11-30 at 17:14 +1100, Alexey Kardashevskiy wrote:
This patch initializes IOMMU groups based on the IOMMU
configuration discovered during the PCI scan on POWERNV
(POWER non virtualized) platform. The IOMMU groups are
to be used later by VFIO driver (PCI pass through).
It also implements an API for mapping/unmapping pages for
guest PCI drivers and providing DMA window properties.
This API is going to be used later by QEMU-VFIO to handle
h_put_tce hypercalls from the KVM guest.
Although this driver has been tested only on the POWERNV
platform, it should work on any platform which supports
TCE tables.
To enable VFIO on POWER, enable SPAPR_TCE_IOMMU config
option and configure VFIO as required.
Cc: David Gibson
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/include/asm/iommu.h |9 ++
arch/powerpc/kernel/iommu.c | 186 ++
arch/powerpc/platforms/powernv/pci.c | 135
drivers/iommu/Kconfig|8 ++
4 files changed, 338 insertions(+)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index cbfe678..5c7087a 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -76,6 +76,9 @@ struct iommu_table {
struct iommu_pool large_pool;
struct iommu_pool pools[IOMMU_NR_POOLS];
unsigned long *it_map; /* A simple allocation bitmap for now */
+#ifdef CONFIG_IOMMU_API
+ struct iommu_group *it_group;
+#endif
};
struct scatterlist;
@@ -147,5 +150,11 @@ static inline void iommu_restore(void)
}
#endif
+extern long iommu_clear_tces(struct iommu_table *tbl, unsigned long entry,
+ unsigned long pages);
+extern long iommu_put_tces(struct iommu_table *tbl, unsigned long entry,
+ uint64_t tce, enum dma_data_direction direction,
+ unsigned long pages);
+
#endif /* __KERNEL__ */
#endif /* _ASM_IOMMU_H */
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index ff5a6ce..0646c50 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -44,6 +44,7 @@
#include
#include
#include
+#include
#define DBG(...)
@@ -856,3 +857,188 @@ void iommu_free_coherent(struct iommu_table *tbl, size_t
size,
free_pages((unsigned long)vaddr, get_order(size));
}
}
+
+#ifdef CONFIG_IOMMU_API
+/*
+ * SPAPR TCE API
+ */
+
+/*
+ * Returns the number of used IOMMU pages (4K) within
+ * the same system page (4K or 64K).
+ * bitmap_weight is not used as it does not support bigendian maps.
+ */
+static int syspage_weight(unsigned long *map, unsigned long entry)
+{
+ int ret = 0, nbits = PAGE_SIZE/IOMMU_PAGE_SIZE;
+
+ /* Aligns TCE entry number to system page boundary */
+ entry &= PAGE_MASK >> IOMMU_PAGE_SHIFT;
+
+ /* Count used 4K pages */
+ while (nbits--)
+ ret += (test_bit(entry++, map) == 0) ? 0 : 1;
Ok, entry is the iova page number. So presumably it's relative to the
start of dma32_window_start since you're unlikely to have a bitmap that
covers all of memory. I hadn't realized that previously.
No, it is zero based. The DMA window is a filter but not offset. But you
are right, the it_map does not cover the whole global table (one per PHB,
roughly), will fix it, thanks for pointing. On my test system IOMMU group
is a whole PHB and DMA window always starts from 0 so tests do not show
everything :)
Doesn't that
mean that it's actually impossible to create an ioctl based interface to
the dma64_window since we're not going to know which window is the
target? I know you're not planning on one, but it seems limiting.
No ,it is not limiting as iova is zero based. Even if it was, there are
flags in map/unmap ioctls which we could use, no?
We
at least need some documentation here, but I'm wondering if iova
shouldn't be zero based so we can determine which window it hits. Also,
now that I look at it, I can't find any range checking on the iova.
True... Have not hit this problem yet :) Good point, will fix, thanks.
--
Alexey
--
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/
Fwd: [GIT] 2 CIFS Fixes for Regressions
-- Forwarded message -- From: Steve French Date: Fri, Nov 30, 2012 at 5:59 PM Subject: [GIT] 2 CIFS Fixes for Regressions To: Linus Torvalds Cc: linux-c...@vger.kernel.org Resending the merge request from earlier in the week. These are two low risk, small fixes, that fix cifs regressions introduced in 3.7. The following changes since commit 5e351cdc998db82935d1248a053a1be37d1160fd: Merge tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux-2.6 (2012-11-23 12:36:06 -1000) are available in the git repository at: git://git.samba.org/sfrench/cifs-2.6.git for-linus Jeff Layton (1): cifs: fix writeback race with file that is growing Pavel Shilovsky (1): CIFS: Fix wrong buffer pointer usage in smb_set_file_info fs/cifs/file.c|6 +++--- fs/cifs/smb1ops.c |3 +-- 2 files changed, 4 insertions(+), 5 deletions(-) -- Thanks, Steve -- Thanks, Steve -- 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 21/21] TTY: move tty buffers to tty_port
On 11/27/2012 02:57 PM, Peter Hurley wrote:
> On Sat, 2012-11-03 at 20:53 -0400, Sasha Levin wrote:
>> On 11/03/2012 07:06 PM, Sasha Levin wrote:
>>> On 11/03/2012 11:55 AM, Jiri Slaby wrote:
>>>> On 11/03/2012 03:03 AM, Sasha Levin wrote:
>>>>> On 11/02/2012 12:18 PM, Jiri Slaby wrote:
>>>>>> On 11/02/2012 05:07 PM, Sasha Levin wrote:
>>>>>>> On Fri, Nov 2, 2012 at 11:51 AM, Jiri Slaby wrote:
>>>>>>>> On 10/31/2012 04:59 PM, Sasha Levin wrote:
>>>>>>>>> So you probably want a lot more than 100k syscalls, why limit it at
>>>>>>>>> all actually?
>>>>>>>>
>>>>>>>> I unset the limit but I still can't reproduce...
>>>>>>>>
>>>>>>>>> I've attached my .config for the guest kernel as reference.
>>>>>>>>
>>>>>>>> Even using this config does not help to reproduce that.
>>>>>>>>
>>>>>>>> Do you use some special trinity params?
>>>>>>>
>>>>>>> Not really:
>>>>>>>
>>>>>>> ./trinity -m --quiet --dangerous -l off
>>>>>>
>>>>>> Oh, you run that as root??
>>>>>>
>>>>>>> Can I add something to my kernel to provide more info when it happens?
>>>>>>
>>>>>> Maybe the attached patch can tell us more...
>>>>>>
>>>>>
>>>>> Nope, I see the warnings mentioned before, without the new 'HUH' warnings.
>>>>
>>>> Actually it does. It is exactly as you wrote some time earlier. The work
>>>> is scheduled after is was cancelled and should not trigger anymore. Or,
>>>> it is scheduled before it is supposed to do. Could you try the attached
>>>> patch and report what happens with that patch?
>>>>
>>>> PS I can't reproduce by whatever I tried.
>>>>
>>>> thanks,
>>>>
>>>
>>> Interesting...
>>>
>>> [ 388.783955] tty is bad=0 ops= (null)Pid: 6480, comm:
>>> kworker/1:2 Tainted: GW
>>> 3.7.0-rc3-next-20121102-sasha-2-gbb570e0-dirty #111
>>
>> So after fuzzing for a while I'm also seeing these:
>>
>> [ 603.533932] tty is bad=-2 ops= (null)Pid: 37, comm: kworker/4:0
>> Tainted: GW3.7.0-rc3-next-20121102-sasha-000
>> 02-gbb570e0-dirty #112
>
> Hi Sasha,
>
> Assuming this access-after-free is still reproducible for you, would you
> be willing to try the patch below? I tried to reproduce this and
> couldn't (with multiple cores and with just single core).
>
> It would distinguish between case A (that the buf work is not being
> cancelled) and case B (that the buf work is being scheduled after the
> port has already been freed). It should BUG in case B, which would also
> expose the call chain. It won't help at all in case A though :\
>
> Regards,
> Peter Hurley
>
> -- >% --
> Subject: [PATCH -next] tty: debug: Narrow possible causes of access-after-free
>
>
> Signed-off-by: Peter Hurley
> ---
> drivers/tty/pty.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
> index be6a373..893fe69 100644
> --- a/drivers/tty/pty.c
> +++ b/drivers/tty/pty.c
> @@ -409,6 +409,7 @@ static void pty_cleanup(struct tty_struct *tty)
> {
> tty->port->itty = NULL;
> tty_port_put(tty->port);
> + tty->port = NULL;
> }
>
> /* Traditional BSD devices */
>
Still reproducible, I'm still seeing this with the patch above applied:
[ 1315.419759] [ cut here ]
[ 1315.420611] WARNING: at drivers/tty/tty_buffer.c:476
flush_to_ldisc+0x60/0x200()
[ 1315.423098] tty is NULL
[ 1315.423885] Pid: 727, comm: kworker/0:1 Tainted: GW
3.7.0-rc7-next-20121130-sasha-00015-g06fcc7a-dirty #2
[ 1315.427278] Call Trace:
[ 1315.428064] [] ? flush_to_ldisc+0x60/0x200
[ 1315.429898] [] warn_slowpath_common+0x86/0xb0
[ 1315.431155] [] warn_slowpath_fmt+0x41/0x50
[ 1315.433087] [] flush_to_ldisc+0x60/0x200
[ 1315.434972] [] process_one_work+0x3b9/0x780
[ 1315.436797] [] ? process_one_work+0x268/0x780
[ 1315.438660] [] ? __tty_buffer_request_room+0x180/0x180
[ 1315.440772] [] worker_thread+0x2ca/0x400
[ 1315.442012] [] ? rescuer_thread+0x2e0/0x2e0
[ 1315.443821] [] kthread+0xe3/0xf0
[ 1315.445362] [] ? put_lock_stats.isra.16+0xe/0x40
[ 1315.447331] [] ? insert_kthread_work+0x90/0x90
[ 1315.449254] [] ret_from_fork+0x7c/0xb0
[ 1315.450246] [] ? insert_kthread_work+0x90/0x90
[ 1315.455389] ---[ end trace 63e808312c27e968 ]---
Thanks,
Sasha
--
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] uio.c: Fix warning: 'ret' might be used uninitialized
On Fri, Nov 30, 2012 at 10:39:06PM +0100, Hans J. Koch wrote: > On Fri, Nov 30, 2012 at 01:16:19PM +0200, Vitalii Demianets wrote: > > On Friday 30 November 2012 01:58:22 Hans J. Koch wrote: > > > On Thu, Nov 29, 2012 at 06:36:59PM +0200, Vitalii Demianets wrote: > > > > > On Thursday 29 November 2012 18:05:27 Tux9 wrote: > > > > > > Hans, I think there are something wrong in your patch, while > > > > > > Vitalii's is right. The variable "ret" is reused in line 292 and > > > > > > line > > > > > > 295, so the value of "ret" would be overridden (if it goto err_map > > > > > > in > > > > > > line 284 when mi>=1). > > > > > > > > > > Actually, both patches do exactly the same thing. Hans's patch > > > > > establishes default value for the ret for all those "other" cases when > > > > > ret is not explicitly overridden. My patch explicitly enumerates all > > > > > those "other" cases in more wordily manner. > > > > > > > > Oops, disregard this. After looking at it more thoroughly I got your > > > > point. You are right, ret is overridden at first iteration (mi == 0), so > > > > Hans's approach does not work. > > > > I must do more thinking before replying in a hurry. > > > > > > You're right. Initialization of "ret" has to take place at the beginning > > > of > > > the loop. > > > > > > I think this version is right: > > > > Yes, this looks right for me. > > OK, I'll send that patch offically, then. This might also be material for > the stable updates. Greg? Yes, that sounds good. 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/
Fwd: bugsplat 3.6.7-rt18 (resend)
Hi
After Frank posted a patch i managed the 3.6.7-rt18 kernel to boot:
There are some local platform modifications for arm mach-pcm043 but nothing
which should
cause this. The kernel got renamed so that the hw debugger works. HR_TIMERS are
disabled in my config.
The kernel continues to work after that but it fails later on more below on
that.
Best regards
Tim
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
=
[ INFO: inconsistent lock state ]
2.6.42pmx-rt18-00015-gdc97b0a-dirty #48 Not tainted <-- this is really
3.6.7-rt18 changed for hw debugger
-
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
kworker/u:0/13 [HC1[1]:SC0[0]:HE0:SE1] takes:
(rcu_kthread_wq.lock.lock.wait_lock){?.+...}, at: []
rt_spin_lock_slowlock+0x44/0x208
{HARDIRQ-ON-W} state was registered at:
[] mark_lock+0x274/0x3c8
[] mark_irqflags+0x11c/0x1a4
[] __lock_acquire+0x5dc/0x814
[] lock_acquire+0x68/0x7c
[] _raw_spin_lock+0x40/0x50
[] rt_spin_lock_slowlock+0x44/0x208
[] rt_spin_lock+0x1c/0x44
[] prepare_to_wait+0x28/0x70
[] rcu_kthread+0x68/0x1b0
[] kthread+0x90/0x9c
[] do_exit+0x0/0x2e0
irq event stamp: 46
hardirqs last enabled at (45): []
_raw_spin_unlock_irqrestore+0x44/0x7c
hardirqs last disabled at (46): [] __irq_svc+0x34/0x98
softirqs last enabled at (0): [] copy_process+0x1f4/0xb78
softirqs last disabled at (0): [< (null)>] (null)
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(rcu_kthread_wq.lock.lock.wait_lock);
lock(rcu_kthread_wq.lock.lock.wait_lock);
*** DEADLOCK ***
2 locks held by kworker/u:0/13:
#0: (&p->alloc_lock){+.+...}, at: [] mm_release+0xd0/0xf8
#1: (&(&(&q->lock)->lock)->wait_lock){+.+...}, at: []
rt_spin_lock_slowunlock+0x14/0x70
stack backtrace:
Backtrace:
[] (dump_backtrace+0x0/0x110) from [] (dump_stack+0x18/0x1c)
r6:c041e414 r5:c78735d0 r4:c7873200 r3:c7873200
[] (dump_stack+0x0/0x1c) from []
(print_usage_bug+0x180/0x1c8)
[] (print_usage_bug+0x0/0x1c8) from []
(mark_lock_irq+0xc0/0x26c)
[] (mark_lock_irq+0x0/0x26c) from [] (mark_lock+0x2a0/0x3c8)
[] (mark_lock+0x0/0x3c8) from [] (mark_irqflags+0x84/0x1a4)
[] (mark_irqflags+0x0/0x1a4) from []
(__lock_acquire+0x5dc/0x814)
r5:c7873200 r4:c036499c
[] (__lock_acquire+0x0/0x814) from []
(lock_acquire+0x68/0x7c)
[] (lock_acquire+0x0/0x7c) from []
(_raw_spin_lock+0x40/0x50)
r6:0003 r5:c0259720 r4:c036498c
[] (_raw_spin_lock+0x0/0x50) from []
(rt_spin_lock_slowlock+0x44/0x208)
r5:c7873200 r4:c036498c
[] (rt_spin_lock_slowlock+0x0/0x208) from []
(rt_spin_lock+0x1c/0x44)
[] (rt_spin_lock+0x0/0x44) from [] (__wake_up+0x24/0x4c)
r5:0001 r4:c036498c
[] (__wake_up+0x0/0x4c) from []
(invoke_rcu_callbacks+0x34/0x40)
r7: r6: r5: r4:c7873200
[] (invoke_rcu_callbacks+0x0/0x40) from []
(rcu_check_callbacks+0x8c/0xc8)
[] (rcu_check_callbacks+0x0/0xc8) from []
(update_process_times+0x48/0x54)
r4:c7873200 r3:c7873200
[] (update_process_times+0x0/0x54) from []
(tick_periodic+0xbc/0xd4)
r6:c0360740 r5:c78090c0 r4:c037cd24 r3:2013
[] (tick_periodic+0x0/0xd4) from []
(tick_handle_periodic+0x20/0x90)
r4:c03607c0 r3:c7874000
[] (tick_handle_periodic+0x0/0x90) from []
(mxc_timer_interrupt+0x28/0x38)
[] (mxc_timer_interrupt+0x0/0x38) from []
(handle_irq_event_percpu+0x60/0x1b0)
[] (handle_irq_event_percpu+0x0/0x1b0) from []
(handle_irq_event+0x44/0x64)
[] (handle_irq_event+0x0/0x64) from []
(handle_level_irq+0xd0/0xe8)
r6:c7875e78 r5:c7809118 r4:c78090c0 r3:0002
[] (handle_level_irq+0x0/0xe8) from []
(generic_handle_irq+0x28/0x38)
r5: r4:002d
[] (generic_handle_irq+0x0/0x38) from []
(handle_IRQ+0x68/0x8c)
r4:002d r3:0050
[] (handle_IRQ+0x0/0x8c) from [] (avic_handle_irq+0x3c/0x48)
r5: r4:c0375c10
[] (avic_handle_irq+0x0/0x48) from [] (__irq_svc+0x44/0x98)
Exception stack(0xc7875e78 to 0xc7875ec0)
5e60: 0001 c78735b8
5e80: 2013 c7840388 2013 000f 0008
5ea0: c7875ed4 c7875e58 c7875ec0 c005129c c025a5f8 2013
r6: r5:2013 r4:c025a5f8 r3:c7873200
[] (_raw_spin_unlock_irqrestore+0x0/0x7c) from []
(try_to_wake_up+0x140/0x164)
r5:c7840388 r4:0001
[] (try_to_wake_up+0x0/0x164) from []
(wake_up_lock_sleeper+0x18/0x1c)
r8:8013 r7:0001 r6:c7847cc8 r5:c7874000 r4:c7847dcc
r3:0001
[] (wake_up_lock_sleeper+0x0/0x1c) from []
(rt_mutex_wake_waiter+0x20/0x30)
[] (rt_mutex_wake_waiter+0x0/0x30) from []
(wakeup_next_waiter+0xa4/0xac)
[] (wakeup_next_waiter+0x0/0xac) from []
(rt_spin_lock_slowunlock+0x5c/0x70)
r8: r7:0013 r6: r5:c7874000 r4:c7847dcc
r3:c7847dec
[] (rt_spin_lock_slowunlock+0x0/0x70) from []
(rt_spin_unlock+0x28/0x2c)
r5:c7847dc8 r4:c7847dcc
[] (rt_spin_unlock+0x0/0x2c) from [] (complete+0x
Re: [PATCH] Avoid dead lock of console related locks in panic case
On Fri, 30 Nov 2012 22:59:13 + Seiji Aguchi wrote: > > > > Let's step back a bit. Please identify with great specificity the code > > sites which are stopping other CPUs before taking locks which > > those other CPUs might have been holding. > > > > Then let's see what we can do to fix up the callers, instead of trying to > > tidy up after they have made this mess. > > OK. > I will update my patch without adding complexity. > The logic will be as follows, if I understand your comment correctly. > > - take console related locks (logbuf_lock, console_sem) > - stop other cpus > - release those locks That would be one way around the problem. It's still a bit messy, because we'll have to take more and more locks in the future, as we identify them. What I actually meant was: can "this" CPU avoid stopping other CPUs so early? If we stop the other CPUs when this CPU is ready to stop itself then there will never be such deadlocks. -- 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 v3]realtek:r8169: Bugfix or workaround for missing extended GigaMAC registers settings
I get a board with 8168e-vl(10ec:8168 with RTL_GIGA_MAC_VER_34),
everything looks well first, I can use ifconfig to set ip, netmask,
etc. And the rx/tx statistics show by ifconfig looks good when I
ping another host or ping it from another host. But it don't work,
I can't get ICMP REPLAY from both sides, although the RX/TX statistics
seem good.
After add some debug code, I found this NIC only accept ethernet
broadcast package, it can't filter out the package send to its
MAC address, but it works good for sending.So ifconfig show the
RX/TX status means it can receive ARP package.(It don't know its
MAC address, so below)
I have try the driver provided by realtek's website, it have the
same problem at the first time. BUT IT WORK AFTER I REBOOT with
CRTL-ALT-DEL, the reason is that realtek's driver call rtl8168_rar_set
in the .shutdown function register with pci_register_driver. Yes,
the really reason to make it work is rtl8689_rar_set, this function
set extended GigaMAC registers, so after reboot without lost the power,
NIC keep the status before reboot.
I haven't see any code to set GigaMAC registers in kernel when boot,
so I guess BIOS or NIC's circuit make it, but of course one miss
the extended GigaMAC registers in this problem. The probe code can
get MAC address right, so MAC{0,4} must had been setted, but some
guys forget the extended GigaMAC registers.
This patch fix it.
[ I don't known whether others' realtek's NIC with extended GigaMAC
reigisters have the same problem, I meet it in 8168e-vl with
RTL_GIGA_MAC_VER_34, so I make this patch just for it.]
Changes:
V1-V2:
I follow Francois Romieu 's below opinion to make this patch oneline:
I'd rather see the GigaMAC registers written through a call to
rtl_rar_set when the mac address is read in rtl_init_one instead of
duplicating most of rtl_rar_set in a quite different place.
V2-V3:
1:Add conditon code to around this fix, because it make no sense for
most NIC
2:Add comment in code
Signed-off-by: Wang YanQing
---
drivers/net/ethernet/realtek/r8169.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index 927aa33..5d98296 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -6903,6 +6903,14 @@ rtl_init_one(struct pci_dev *pdev, const struct
pci_device_id *ent)
dev->dev_addr[i] = RTL_R8(MAC0 + i);
memcpy(dev->perm_addr, dev->dev_addr, dev->addr_len);
+ /*
+*This is a fix for BIOS forget to set
+*extend GigaMAC registers
+*Wang YanQing 12/1/2012
+*/
+ if (tp->mac_version == RTL_GIGA_MAC_VER_34) {
+ rtl_rar_set(tp, dev->dev_addr);
+ }
SET_ETHTOOL_OPS(dev, &rtl8169_ethtool_ops);
dev->watchdog_timeo = RTL8169_TX_TIMEOUT;
--
1.7.11.1.116.g8228a23
--
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, RFT] [PATCH] staging: ft1000: unify struct ft1000_info between USB and PCMCIA drivers
Hi,
On Tue, Nov 13, 2012 at 12:32 PM, Belisko Marek wrote:
> On Tue, Nov 13, 2012 at 11:11 AM, Ondrej Zary
> wrote:
>> On Monday 12 November 2012, Belisko Marek wrote:
>>> Hi Ondrej,
>>>
>>> On Fri, Nov 9, 2012 at 10:42 PM, Ondrej Zary
>> wrote:
>>> > Unify struct ft1000_info between ft1000-usb and ft1000-pcmcia and move it
>>> > to common ft1000.h.
>>> >
>>> > ft1000-pcmcia seems to work. Please test ft1000-usb.
>>> >
>>> > Signed-off-by: Ondrej Zary
>>> > ---
>>> > drivers/staging/ft1000/ft1000-pcmcia/ft1000.h | 33 +-
>>> > drivers/staging/ft1000/ft1000-pcmcia/ft1000_hw.c | 21 ++-
>>> > drivers/staging/ft1000/ft1000-pcmcia/ft1000_proc.c | 10 +-
>>> > drivers/staging/ft1000/ft1000-usb/ft1000_debug.c | 147
>>> > ++-- .../staging/ft1000/ft1000-usb/ft1000_download.c|
>>> > 70 +- drivers/staging/ft1000/ft1000-usb/ft1000_hw.c | 99
>>> > +++--- drivers/staging/ft1000/ft1000-usb/ft1000_proc.c|4
>>> > +-
>>> > drivers/staging/ft1000/ft1000-usb/ft1000_usb.c | 30 ++--
>>> > drivers/staging/ft1000/ft1000-usb/ft1000_usb.h | 54 +--
>>> > drivers/staging/ft1000/ft1000.h| 35 +
>>> > 10 files changed, 236 insertions(+), 267 deletions(-)
>>> >
>>> > diff --git a/drivers/staging/ft1000/ft1000-pcmcia/ft1000.h
>>> > b/drivers/staging/ft1000/ft1000-pcmcia/ft1000.h index adb436e..65f7ab6
>>> > 100644
>>> > --- a/drivers/staging/ft1000/ft1000-pcmcia/ft1000.h
>>> > +++ b/drivers/staging/ft1000/ft1000-pcmcia/ft1000.h
>>> > @@ -31,41 +31,10 @@
>>> > #define SUCCESS0x00
>>> > #define FAILURE0x01
>>> >
>>> > -struct ft1000_info {
>>> > - struct net_device_stats stats;
>>> > - u16 DrvErrNum;
>>> > - u16 AsicID;
>>> > +struct ft1000_pcmcia {
>>>
>>> To be consistent can you please name also usb part not ft100_device
>>> but e.g. ft1000_usb or something?
>>
>> Yes, that's a good idea. I'd like to do that in a separate patch, this one is
>> already big enough.
> OK good idea.
>>
>>> > @@ -1179,8 +1179,6 @@ static int ft1000_open(struct net_device *dev)
>>> > struct ft1000_info *pInfo = netdev_priv(dev);
>>> > struct timeval tv;
>>> >
>>> > - DEBUG("ft1000_open is called for card %d\n", pInfo->CardNumber);
>>>
>>> ^^^ Why removing this debug?
>>
>> I don't remember exactly (this is from an old patch) but probably because I
>> didn't want to add code to reach CardNumber (which should be removed too).
>> The debug messages are a mess, some are completely useless, some should be
>> non-debug instead.
> There is rule one change one patch so please keep it there and remove
> in separate patch.
>>
>> If you have the USB hardware, please test if this patch does not break
>> anything. I have only a PCMCIA card.
> I'll do testing on USB (waiting for HW to come ;))
USB testing done. It's working good. Please update patch according comments
and re-send. Thanks.
>>
>> --
>> Ondrej Zary
>
> Cheers,
>
> marek
>
> --
> as simple and primitive as possible
> -
> Marek Belisko - OPEN-NANDRA
> Freelance Developer
>
> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> Tel: +421 915 052 184
> skype: marekwhite
> twitter: #opennandra
> web: http://open-nandra.com
Marek
--
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
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/
[GIT PULL] x86 fixes for 3.7
Hi Linus,
The following changes since commit 9489e9dcae718d5fde988e4a684a0f55b5f94d17:
Linux 3.7-rc7 (2012-11-25 17:59:19 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/urgent
H. Peter Anvin (2):
x86, kvm: Remove incorrect redundant assembly constraint
x86-32: Unbreak booting on some 486 clones
Vincent Palatin (1):
x86, fpu: Avoid FPU lazy restore after suspend
arch/x86/include/asm/fpu-internal.h | 15 +--
arch/x86/kernel/head_32.S |9 +++--
arch/x86/kernel/smpboot.c |5 +
arch/x86/kvm/emulate.c |3 +--
4 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/arch/x86/include/asm/fpu-internal.h
b/arch/x86/include/asm/fpu-internal.h
index 831dbb9..41ab26e 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -399,14 +399,17 @@ static inline void drop_init_fpu(struct task_struct *tsk)
typedef struct { int preload; } fpu_switch_t;
/*
- * FIXME! We could do a totally lazy restore, but we need to
- * add a per-cpu "this was the task that last touched the FPU
- * on this CPU" variable, and the task needs to have a "I last
- * touched the FPU on this CPU" and check them.
+ * Must be run with preemption disabled: this clears the fpu_owner_task,
+ * on this CPU.
*
- * We don't do that yet, so "fpu_lazy_restore()" always returns
- * false, but some day..
+ * This will disable any lazy FPU state restore of the current FPU state,
+ * but if the current thread owns the FPU, it will still be saved by.
*/
+static inline void __cpu_disable_lazy_restore(unsigned int cpu)
+{
+ per_cpu(fpu_owner_task, cpu) = NULL;
+}
+
static inline int fpu_lazy_restore(struct task_struct *new, unsigned int cpu)
{
return new == this_cpu_read_stable(fpu_owner_task) &&
diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index 957a47a..4dac2f6 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -292,8 +292,8 @@ default_entry:
* be using the global pages.
*
* NOTE! If we are on a 486 we may have no cr4 at all!
- * Specifically, cr4 exists if and only if CPUID exists,
- * which in turn exists if and only if EFLAGS.ID exists.
+ * Specifically, cr4 exists if and only if CPUID exists
+ * and has flags other than the FPU flag set.
*/
movl $X86_EFLAGS_ID,%ecx
pushl %ecx
@@ -308,6 +308,11 @@ default_entry:
testl %ecx,%eax
jz 6f # No ID flag = no CPUID = no CR4
+ movl $1,%eax
+ cpuid
+ andl $~1,%edx # Ignore CPUID.FPU
+ jz 6f # No flags or only CPUID.FPU = no CR4
+
movl pa(mmu_cr4_features),%eax
movl %eax,%cr4
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index c80a33b..f3e2ec8 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -68,6 +68,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -818,6 +820,9 @@ int __cpuinit native_cpu_up(unsigned int cpu, struct
task_struct *tidle)
per_cpu(cpu_state, cpu) = CPU_UP_PREPARE;
+ /* the FPU context is blank, nobody can own it */
+ __cpu_disable_lazy_restore(cpu);
+
err = do_boot_cpu(apicid, cpu, tidle);
if (err) {
pr_debug("do_boot_cpu failed %d\n", err);
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 39171cb..bba39bf 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -426,8 +426,7 @@ static void invalidate_registers(struct x86_emulate_ctxt
*ctxt)
_ASM_EXTABLE(1b, 3b)\
: "=m" ((ctxt)->eflags), "=&r" (_tmp), \
"+a" (*rax), "+d" (*rdx), "+qm"(_ex) \
- : "i" (EFLAGS_MASK), "m" ((ctxt)->src.val), \
- "a" (*rax), "d" (*rdx)); \
+ : "i" (EFLAGS_MASK), "m" ((ctxt)->src.val));\
} while (0)
/* instruction has only one source operand, destination is implicit (e.g. mul,
div, imul, idiv) */
--
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: High context switch rate, ksoftirqd's chewing cpu
On 30.11.2012 23:52, Tejun Heo wrote:
Hello, Zlatko.
Sorry about the delay. Your message was in my spam folder. The
attachment seems to have confused the filter.
On Sat, Nov 17, 2012 at 02:01:29PM +0100, Zlatko Calusic wrote:
This week I spent some hours tracking a regression in 3.7 kernel
that was producing high context switch rate on one of my machines. I
carefully bisected between 3.6 and 3.7-rc1 and eventually found this
commit a culprit:
commit e7c2f967445dd2041f0f8e3179cca22bb8bb7f79
Author: Tejun Heo
Date: Tue Aug 21 13:18:24 2012 -0700
workqueue: use mod_delayed_work() instead of __cancel + queue
...
Then I carefully reverted chunk by chunk to find out what exact
change is responsible for the regression. You can find it attached
as wq.patch (to preserve whitespace). Very simple modification with
wildly different behavior on only one of my machines, weird. I'm
also attaching ctxt/s graph that shows the impact nicely. I'll
gladly provide any additional info that could help you resolve this.
Please Cc: on reply (not subscribed to lkml).
Regards,
--
Zlatko
diff --git a/block/blk-core.c b/block/blk-core.c
index 4b4dbdf..4b8b606 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -319,10 +319,8 @@ EXPORT_SYMBOL(__blk_run_queue);
*/
void blk_run_queue_async(struct request_queue *q)
{
- if (likely(!blk_queue_stopped(q))) {
- __cancel_delayed_work(&q->delay_work);
- queue_delayed_work(kblockd_workqueue, &q->delay_work, 0);
- }
+ if (likely(!blk_queue_stopped(q)))
+ mod_delayed_work(kblockd_workqueue, &q->delay_work, 0);
}
EXPORT_SYMBOL(blk_run_queue_async);
That's intersting. Is there anything else noticeably different than
the ctxsw counts? e.g. CPU usage, IO throughput / latency, etc...
Also, can you please post the kernel boot log from the machine? I
assume that the issue is readily reproducible? Are you up for trying
some debug patches?
Thanks.
Hey Tejun! Thanks for replying.
It's an older C2D machine, I've attached the kernel boot log. Funny
thing is that on the other half a dozen machines I don't observe any
problems, only on this one. And it's reproducible every time. I don't
see any other anomalies beside the two I already mentioned, high context
switch rate and ksoftirqd daemons eating more CPU, probably as a
consequence.
I'll gladly try your patch and send my observations tommorow, as I've
just started md resync on the machine, which will take couple of hours.
Regards,
--
Zlatko
Linux version 3.7.0-rc7 (root@ps) (gcc version 4.7.2 (Debian 4.7.2-4) ) #1 SMP
Fri Nov 30 23:13:52 CET 2012
Command line: root=/dev/md0 rootfstype=ext4 profile=2 ro
BOOT_IMAGE=/boot/vmlinuz-3.7.0-rc7
e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x-0x0009fbff] usable
BIOS-e820: [mem 0x0009fc00-0x0009] reserved
BIOS-e820: [mem 0x000e-0x000f] reserved
BIOS-e820: [mem 0x0010-0xcf239fff] usable
BIOS-e820: [mem 0xcf23a000-0xcf27cfff] ACPI NVS
BIOS-e820: [mem 0xcf27d000-0xcf354fff] reserved
BIOS-e820: [mem 0xcf355000-0xcf364fff] ACPI NVS
BIOS-e820: [mem 0xcf365000-0xcf3e0fff] reserved
BIOS-e820: [mem 0xcf3e1000-0xcf3e6fff] ACPI data
BIOS-e820: [mem 0xcf3e7000-0xcf3e7fff] ACPI NVS
BIOS-e820: [mem 0xcf3e8000-0xcf3e9fff] ACPI data
BIOS-e820: [mem 0xcf3ea000-0xcf3ebfff] ACPI NVS
BIOS-e820: [mem 0xcf3ec000-0xcf3ecfff] reserved
BIOS-e820: [mem 0xcf3ed000-0xcf3f0fff] ACPI NVS
BIOS-e820: [mem 0xcf3f1000-0xcf3f] reserved
BIOS-e820: [mem 0xcf40-0xcf5f] usable
BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
BIOS-e820: [mem 0xffa0-0xffbf] reserved
BIOS-e820: [mem 0xffe0-0x] reserved
BIOS-e820: [mem 0x0001-0x00012fff] usable
NX (Execute Disable) protection: active
DMI 2.4 present.
DMI: /DG31PR, BIOS PRG3110H.86A.0065.2009.0421.1559 04/21/2009
e820: update [mem 0x-0x] usable ==> reserved
e820: remove [mem 0x000a-0x000f] usable
No AGP bridge found
e820: last_pfn = 0x13 max_arch_pfn = 0x4
MTRR default type: uncachable
MTRR fixed ranges enabled:
0-9 write-back
A-E7FFF uncachable
E8000-F write-protect
MTRR variable ranges enabled:
0 base 0 mask F write-back
1 base 1 mask FE000 write-back
2 base 12000 mask FF000 write-back
3 base 0CF60 mask FFFE0 uncachable
4 base 0CF80 mask FFF80 uncachable
5 base 0D000 mask FF000 uncachable
6 base 0E000 mask FE000 uncachable
7 disabled
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
original variable MTRRs
reg 0, base: 0GB, range: 4GB, t
[GIT PULL] C6X: fixes for v3.7
The following changes since commit 9489e9dcae718d5fde988e4a684a0f55b5f94d17: Linux 3.7-rc7 (2012-11-25 17:59:19 -0800) are available in the git repository at: git://linux-c6x.org/git/projects/linux-c6x-upstreaming.git tags/for-linus for you to fetch changes up to 93bbd0c087eb299e0fe11c59d340932180c082b5: c6x: use generic kvm_para.h (2012-11-28 14:33:03 -0500) C6X fixes for v3.7 Mark Salter (4): c6x: run do_notify_resume with interrupts enabled c6x: fix misleading comment c6x: remove internal kernel symbols from exported setup.h c6x: use generic kvm_para.h arch/c6x/include/asm/setup.h | 33 + arch/c6x/include/uapi/asm/Kbuild |2 ++ arch/c6x/include/uapi/asm/kvm_para.h |1 - arch/c6x/include/uapi/asm/setup.h| 33 +++-- arch/c6x/kernel/entry.S |5 +++-- 5 files changed, 41 insertions(+), 33 deletions(-) create mode 100644 arch/c6x/include/asm/setup.h delete mode 100644 arch/c6x/include/uapi/asm/kvm_para.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] Do a proper locking for mmap and block size change
On Sat, Dec 01, 2012 at 09:40:41AM +1100, Dave Chinner wrote: > So it was based on this interface? Based on that. I had dropped the inode operation as it's not really a generic operation but a callback for either the buffered I/O code or direct I/O and should be treated as such. I've also split the single multiplexer function into individual ones, but the underlying data structure and fundamental operations are the same. > (I went looking for this code on google a couple of days ago so I > could point at it and say "we should be using an iomap structure, > not buffer heads", but it looks like I never posted it to fsdevel or > the xfs lists...) Your version defintively was up on your kernel.org XFS tree, that's what I started from. I'll have a long plane right tonight, let's see if I can get the direct I/O version updated. -- 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] Avoid dead lock of console related locks in panic case
Thank you for giving me the comment. > - Makes the logic in this area even more twisty and complex, when > what we need to do is to simplify it > > - Reinitialises in-use locks > > - Gives the boolean variable "yes" three states, but didn't rename > that variable to something appropriate. I understand "yes" is odd. I just wanted to know if an idea reinitializing locks is acceptable. But now I understand I have to take another approach. > > - Passes yes==2 into s390's unsuspecting bust_spinlocks() implementation. > Sorry. I missed the code. > > Let's step back a bit. Please identify with great specificity the code sites > which are stopping other CPUs before taking locks which > those other CPUs might have been holding. > > Then let's see what we can do to fix up the callers, instead of trying to > tidy up after they have made this mess. OK. I will update my patch without adding complexity. The logic will be as follows, if I understand your comment correctly. - take console related locks (logbuf_lock, console_sem) - stop other cpus - release those locks Seiji -- 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-keystone] [PATCH] spi: davinci: add OF support for the spi controller
On 11/15/2012 11:20 AM, Grant Likely wrote:
On Mon, 12 Nov 2012 16:28:22 -0500, Murali Karicheri
wrote:
This adds OF support to DaVinci SPI controller to configure platform
data through device bindings.
Signed-off-by: Murali Karicheri
Hi Murali,
Comments below...
---
.../devicetree/bindings/spi/spi-davinci.txt| 50
drivers/spi/spi-davinci.c | 80 +++-
2 files changed, 126 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/spi-davinci.txt
diff --git a/Documentation/devicetree/bindings/spi/spi-davinci.txt
b/Documentation/devicetree/bindings/spi/spi-davinci.txt
new file mode 100644
index 000..0369369
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-davinci.txt
@@ -0,0 +1,50 @@
+Davinci SPI controller device bindings
+
+Required properties:
+- #address-cells: number of cells required to define a chip select
+ address on the SPI bus.
Will this *ever* be something other than '1'?
+- #size-cells: should be zero.
+- compatible:
+ - "ti,davinci-spi"
Please use the actual model of the chip here. Don't try to be generic
with the compatible string. A driver can bind against more than one
compatible value and new devices can claim compatiblity with old by
including the old compatible string in this list.
+- reg: Offset and length of SPI controller register space
+- ti,davinci-spi-version: SPI version :- "1.0" or "2.0"
Usually this is determined from the compatible value directly (which is
why compatible strings shouldn't be generic). Don't use a separate
property for it.
+- ti,davinci-spi-num-cs: Number of chip selects
+- ti,davinci-spi-intr-line: interrupt line used to connect the SPI
+ IP to the ARM interrupt controller withn the SoC. Possible values
+ are 0 and 1.
? Isn't that what the interrupts property is for? I don't understand why
this is needed from the description.
+- interrupts: interrupt number offset at the irq parent
+- clocks: spi clk phandle
+
+Example of a NOR flash slave device (n25q032) connected to DaVinci
+SPI controller device over the SPI bus.
+
+spi:spi0@20BF {
spi@20BF (use 'spi' not 'spi0')
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "ti,davinci-spi";
+ reg = <0x20BF 0x1000>;
+ ti,davinci-spi-version = "1.0";
+ ti,davinci-spi-num-cs = <4>;
+ ti,davinci-spi-intr-line= <0>;
+ interrupts = <338>;
+ clocks = <&clkspi>;
+
+ flash: n25q032@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "st,m25p32";
+ spi-max-frequency = <2500>;
+ reg = <0>;
+
+ partition@0 {
+ label = "u-boot-spl";
+ reg = <0x0 0x8>;
+ read-only;
+ };
+
+ partition@1 {
+ label = "test";
+ reg = <0x8 0x38>;
+ };
+ };
+};
diff --git a/drivers/spi/spi-davinci.c b/drivers/spi/spi-davinci.c
index 71a6423..0f50319 100644
--- a/drivers/spi/spi-davinci.c
+++ b/drivers/spi/spi-davinci.c
@@ -26,6 +26,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
#include
@@ -788,6 +791,69 @@ rx_dma_failed:
return r;
}
+#if defined(CONFIG_OF)
+static const struct of_device_id davinci_spi_of_match[] = {
+ {
+ .compatible = "ti,davinci-spi",
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, davini_spi_of_match);
+
+/**
+ * spi_davinci_get_pdata - Get platform_data from DTS binding
+ * @pdev: ptr to platform data
+ *
+ * Parses and populate platform_data from device tree bindings.
+ *
+ * NOTE: Not all platform_data params are supported currently.
+ */
+static struct davinci_spi_platform_data
+ *spi_davinci_get_pdata(struct platform_device *pdev)
+{
+ struct device_node *node = pdev->dev.of_node;
+ struct davinci_spi_platform_data *pdata;
+ unsigned int num_cs, intr_line = 0;
+ const char *version;
+
+ if (pdev->dev.platform_data)
+ return pdev->dev.platform_data;
+
+ if (!pdev->dev.of_node)
+ return NULL;
+
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ pdev->dev.platform_data = pdata;
+ if (!pdata)
+ return NULL;
Since pdata must always be present, roll it directly into struct
spi_davinci and get rid of the kzmalloc here. It is less expensive and
is simpler code.
Grant,
Could you elaborate a bit? What you mean by rolling pdata into
spi_davinci? I believe you are referring
to davinci_spi. Are you saying change following:-
struct davinci_spi {
...
struct davinc
Re: Wireless regression in workqueue: use mod_delayed_work() instead of __cancel + queue
Hey, again.
Can you please test whether the following patch makes any difference?
Thanks!
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 042d221..26368ef 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1477,7 +1477,10 @@ bool mod_delayed_work_on(int cpu, struct
workqueue_struct *wq,
} while (unlikely(ret == -EAGAIN));
if (likely(ret >= 0)) {
- __queue_delayed_work(cpu, wq, dwork, delay);
+ if (!delay)
+ __queue_work(cpu, wq, &dwork->work);
+ else
+ __queue_delayed_work(cpu, wq, dwork, delay);
local_irq_restore(flags);
}
--
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: High context switch rate, ksoftirqd's chewing cpu
Hello, again.
Can you please try this patch? Thanks!
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 042d221..26368ef 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1477,7 +1477,10 @@ bool mod_delayed_work_on(int cpu, struct
workqueue_struct *wq,
} while (unlikely(ret == -EAGAIN));
if (likely(ret >= 0)) {
- __queue_delayed_work(cpu, wq, dwork, delay);
+ if (!delay)
+ __queue_work(cpu, wq, &dwork->work);
+ else
+ __queue_delayed_work(cpu, wq, dwork, delay);
local_irq_restore(flags);
}
--
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: High context switch rate, ksoftirqd's chewing cpu
Hello, Zlatko.
Sorry about the delay. Your message was in my spam folder. The
attachment seems to have confused the filter.
On Sat, Nov 17, 2012 at 02:01:29PM +0100, Zlatko Calusic wrote:
> This week I spent some hours tracking a regression in 3.7 kernel
> that was producing high context switch rate on one of my machines. I
> carefully bisected between 3.6 and 3.7-rc1 and eventually found this
> commit a culprit:
>
> commit e7c2f967445dd2041f0f8e3179cca22bb8bb7f79
> Author: Tejun Heo
> Date: Tue Aug 21 13:18:24 2012 -0700
>
> workqueue: use mod_delayed_work() instead of __cancel + queue
...
>
> Then I carefully reverted chunk by chunk to find out what exact
> change is responsible for the regression. You can find it attached
> as wq.patch (to preserve whitespace). Very simple modification with
> wildly different behavior on only one of my machines, weird. I'm
> also attaching ctxt/s graph that shows the impact nicely. I'll
> gladly provide any additional info that could help you resolve this.
>
> Please Cc: on reply (not subscribed to lkml).
>
> Regards,
> --
> Zlatko
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 4b4dbdf..4b8b606 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -319,10 +319,8 @@ EXPORT_SYMBOL(__blk_run_queue);
> */
> void blk_run_queue_async(struct request_queue *q)
> {
> - if (likely(!blk_queue_stopped(q))) {
> - __cancel_delayed_work(&q->delay_work);
> - queue_delayed_work(kblockd_workqueue, &q->delay_work, 0);
> - }
> + if (likely(!blk_queue_stopped(q)))
> + mod_delayed_work(kblockd_workqueue, &q->delay_work, 0);
> }
> EXPORT_SYMBOL(blk_run_queue_async);
That's intersting. Is there anything else noticeably different than
the ctxsw counts? e.g. CPU usage, IO throughput / latency, etc...
Also, can you please post the kernel boot log from the machine? I
assume that the issue is readily reproducible? Are you up for trying
some debug patches?
Thanks.
--
tejun
--
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] Do a proper locking for mmap and block size change
On Fri, Nov 30, 2012 at 11:36:01AM -0500, Christoph Hellwig wrote:
> On Fri, Nov 30, 2012 at 01:49:10PM +1100, Dave Chinner wrote:
> > > Ugh. That's a big violation of how buffer-heads are supposed to work:
> > > the block number is very much defined to be in multiples of b_size
> > > (see for example "submit_bh()" that turns it into a sector number).
> > >
> > > But you're right. The direct-IO code really *is* violating that, and
> > > knows that get_block() ends up being defined in i_blkbits regardless
> > > of b_size.
> >
> > Same with mpage_readpages(), so it's not just direct IO that has
> > this problem
>
> The mpage code may actually fall back to BHs.
>
> I have a version of the direct I/O code that uses the iomap_ops from the
> multi-page write code that you originally started. It uses the new op
> as primary interface for direct I/O and provides a helper for
> filesystems that still use buffer heads internally. I'll try to dust it
> off and send out a version for the current kernel.
So it was based on this interface?
(I went looking for this code on google a couple of days ago so I
could point at it and say "we should be using an iomap structure,
not buffer heads", but it looks like I never posted it to fsdevel or
the xfs lists...)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 090f0ea..e247d62 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -522,6 +522,7 @@ enum positive_aop_returns {
struct page;
struct address_space;
struct writeback_control;
+struct iomap;
struct iov_iter {
const struct iovec *iov;
@@ -614,6 +615,9 @@ struct address_space_operations {
int (*is_partially_uptodate) (struct page *, read_descriptor_t *,
unsigned long);
int (*error_remove_page)(struct address_space *, struct page *);
+
+ int (*iomap)(struct address_space *mapping, loff_t pos,
+ ssize_t length, struct iomap *iomap, int cmd);
};
/*
diff --git a/include/linux/iomap.h b/include/linux/iomap.h
new file mode 100644
index 000..7708614
--- /dev/null
+++ b/include/linux/iomap.h
@@ -0,0 +1,45 @@
+#ifndef _IOMAP_H
+#define _IOMAP_H
+
+/* ->iomap a_op command types */
+#define IOMAP_READ 0x01/* read the current mapping starting at the
+ given position, trimmed to a maximum length.
+ FS's should use this to obtain and lock
+ resources within this range */
+#define IOMAP_RESERVE 0x02/* reserve space for an allocation that spans
+ the given iomap */
+#define IOMAP_ALLOCATE 0x03/* allocate space in a given iomap - must have
+ first been reserved */
+#define IOMAP_UNRESERVE0x04/* return unused reserved space for the
given
+ iomap and used space. This will always be
+ called after a IOMAP_READ so as to allow the
+ FS to release held resources. */
+
+/* types of block ranges for multipage write mappings. */
+#define IOMAP_HOLE 0x01/* no blocks allocated, need allocation */
+#define IOMAP_DELALLOC 0x02/* delayed allocation blocks */
+#define IOMAP_MAPPED 0x03/* blocks allocated @blkno */
+#define IOMAP_UNWRITTEN0x04/* blocks allocated @blkno in unwritten
state */
+
+struct iomap {
+ sector_tblkno; /* first sector of mapping */
+ loff_t offset; /* file offset of mapping, bytes */
+ ssize_t length; /* length of mapping, bytes */
+ int type; /* type of mapping */
+ void*priv; /* fs private data associated with map */
+};
+
+static inline bool
+iomap_needs_allocation(struct iomap *iomap)
+{
+ return iomap->type == IOMAP_HOLE;
+}
+
+/* multipage write interfaces use iomaps */
+typedef int (*mpw_actor_t)(struct address_space *mapping, void *src,
+ loff_t pos, ssize_t len, struct iomap *iomap);
+
+ssize_t multipage_write_segment(struct address_space *mapping, void *src,
+ loff_t pos, ssize_t length, mpw_actor_t actor);
+
+#endif /* _IOMAP_H */
Cheers,
Dave.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
--
Dave Chinner
da...@fromorbit.com
--
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/5] xen-pcifront: handle backend CLOSED without CLOSING
On Fri, Nov 30, 2012 at 02:42:14PM -0700, Bjorn Helgaas wrote: > On Fri, Nov 30, 2012 at 11:41 AM, Bjorn Helgaas wrote: > > On Fri, Oct 19, 2012 at 6:59 AM, Konrad Rzeszutek Wilk > > wrote: > >> On Thu, Oct 18, 2012 at 11:03:36AM +0100, David Vrabel wrote: > >>> From: David Vrabel > >>> > >>> Backend drivers shouldn't transistion to CLOSED unless the frontend is > >>> CLOSED. If a backend does transition to CLOSED too soon then the > >>> frontend may not see the CLOSING state and will not properly shutdown. > >>> > >>> So, treat an unexpected backend CLOSED state the same as CLOSING. > >>> > >>> Signed-off-by: David Vrabel > >>> Acked-by: Konrad Rzeszutek Wilk > >>> --- > >>> Cc: linux-...@vger.kernel.org > >>> Cc: Bjorn Helgaas > >> > >> Bjorn, do you want me to prep a git pull with this patch > >> or can I have your Ack to put it my tree and have it part of my > >> git pull to Linus? > > > > Sorry, I missed this. I can put it in my -next branch for the v3.8 > > merge window. Would that work for you? > > I put this in my -next branch, so we'll at least have a chance of > making a linux-next cycle before v3.7 pops. Great. Thx! > > >>> --- > >>> drivers/pci/xen-pcifront.c |5 - > >>> 1 files changed, 4 insertions(+), 1 deletions(-) > >>> > >>> diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c > >>> index 0aab85a..a0c7312 100644 > >>> --- a/drivers/pci/xen-pcifront.c > >>> +++ b/drivers/pci/xen-pcifront.c > >>> @@ -1068,13 +1068,16 @@ static void __init_refok > >>> pcifront_backend_changed(struct xenbus_device *xdev, > >>> case XenbusStateInitialising: > >>> case XenbusStateInitWait: > >>> case XenbusStateInitialised: > >>> - case XenbusStateClosed: > >>> break; > >>> > >>> case XenbusStateConnected: > >>> pcifront_try_connect(pdev); > >>> break; > >>> > >>> + case XenbusStateClosed: > >>> + if (xdev->state == XenbusStateClosed) > >>> + break; > >>> + /* Missed the backend's CLOSING state -- fallthrough */ > >>> case XenbusStateClosing: > >>> dev_warn(&xdev->dev, "backend going away!\n"); > >>> pcifront_try_disconnect(pdev); > >>> -- > >>> 1.7.2.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 v2 0/5] Add movablecore_map boot option
On Thu, 2012-11-29 at 10:25 +0800, Jiang Liu wrote: > On 2012-11-29 9:42, Jaegeuk Hanse wrote: > > On Wed, Nov 28, 2012 at 04:47:42PM +0800, Jiang Liu wrote: > >> Hi all, > >>Seems it's a great chance to discuss about the memory hotplug feature > >> within this thread. So I will try to give some high level thoughts about > >> memory > >> hotplug feature on x86/IA64. Any comments are welcomed! > >>First of all, I think usability really matters. Ideally, memory hotplug > >> feature should just work out of box, and we shouldn't expect > >> administrators to > >> add several extra platform dependent parameters to enable memory hotplug. > >> But how to enable memory (or CPU/node) hotplug out of box? I think the key > >> point > >> is to cooperate with BIOS/ACPI/firmware/device management teams. > >>I still position memory hotplug as an advanced feature for high end > >> servers and those systems may/should provide some management interfaces to > >> configure CPU/memory/node hotplug features. The configuration UI may be > >> provided > >> by BIOS, BMC or centralized system management suite. Once administrator > >> enables > >> hotplug feature through those management UI, OS should support system > >> device > >> hotplug out of box. For example, HP SuperDome2 management suite provides > >> interface > >> to configure a node as floating node(hot-removable). And OpenSolaris > >> supports > >> CPU/memory hotplug out of box without any extra configurations. So we > >> should > >> shape interfaces between firmware and OS to better support system device > >> hotplug. Well described. I agree with you. I am also OK to have the boot option for the time being, but we should be able to get the info from ACPI for better TCE. > >>On the other hand, I think there are no commercial available x86/IA64 > >> platforms with system device hotplug capabilities in the field yet, at > >> least only > >> limited quantity if any. So backward compatibility is not a big issue for > >> us now. HP SuperDome is IA64-based and supports node hotplug when running with HP-UX. It implements vendor-unique ACPI interface to describe movable memory ranges. > >> So I think it's doable to rely on firmware to provide better support for > >> system > >> device hotplug. > >>Then what should be enhanced to better support system device hotplug? > >> > >> 1) ACPI specification should be enhanced to provide a static table to > >> describe > >> components with hotplug features, so OS could reserve special resources for > >> hotplug at early boot stages. For example, to reserve enough CPU ids for > >> CPU > >> hot-add. Currently we guess maximum number of CPUs supported by the > >> platform > >> by counting CPU entries in APIC table, that's not reliable. Right. HP SuperDome implements vendor-unique ACPI interface for this as well. For Linux, it is nice to have a standard interface defined. > >> 2) BIOS should implement SRAT, MPST and PMTT tables to better support > >> memory > >> hotplug. SRAT associates memory ranges with proximity domains with an extra > >> "hotpluggable" flag. PMTT provides memory device topology information, such > >> as "socket->memory controller->DIMM". MPST is used for memory power > >> management > >> and provides a way to associate memory ranges with memory devices in PMTT. > >> With all information from SRAT, MPST and PMTT, OS could figure out hotplug > >> memory ranges automatically, so no extra kernel parameters needed. I agree that using SRAT is a good compromise. The hotpluggable flag is supposed to indicate the platform's capability, but could use for this purpose until we have a better interface defined. > >> 3) Enhance ACPICA to provide a method to scan static ACPI tables before > >> memory subsystem has been initialized because OS need to access SRAT, > >> MPST and PMTT when initializing memory subsystem. I do not think this is an ACPICA issue. HP-UX also uses ACPICA, and can access ACPI tables and walk ACPI namespace during early boot-time. This is achieved by the acpi_os layer to use special early boot-time memory allocator at early boot-time. Therefore, boot-time and hot-add config code are very consistent in HP-UX. > >> 4) The last and the most important issue is how to minimize performance > >> drop caused by memory hotplug. As proposed by this patchset, once we > >> configure all memory of a NUMA node as movable, it essentially disable > >> NUMA optimization of kernel memory allocation from that node. According > >> to experience, that will cause huge performance drop. We have observed > >> 10-30% performance drop with memory hotplug enabled. And on another > >> OS the average performance drop caused by memory hotplug is about 10%. > >> If we can't resolve the performance drop, memory hotplug is just a feature > >> for demo:( With help from hardware, we do have some chances to reduce > >> performance penalty caused by memory hotplug. > >>As we know, Linux
Record/Replay implementation (as opposed to checkpoint/restart)
Dear hackers, I built scribe, a record/replay engine implemented in the kernel. If you want to explore the code, here it is: git://github.com/nviennot/linux-2.6-scribe.git most of it is in the ./scribe directory. Warning: contains time-space continuum bending material Additionally, here is a blog post that introduce it in further details (includes a screencast): http://velvetpulse.com/2012/11/27/scribe-the-deterministic-transparent-record-replay-engine/ Cheers, Nico -- 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 0/1] Input: xpad - Implement wireless controller LED setting and fix connect time LED setting
Hi Chris,
On Friday, November 30, 2012 01:54:06 PM Chris Moeller wrote:
> I've submitted versions of this with prior patch sets, and this part
> was never accepted, possibly because it depended on other patches to
> work, or possibly because it wasn't so cleanly organized. This time,
> I've split the LED setting command off into its own static function,
> then call that on controller connect and optionally on LED setting
> commands. The static function does not include any locking, because
> locking inside the function which receives the incoming packets
> deadlocks the driver, and does not appear to be necessary anyway.
>
> It also removes all traces of the original bulk out function which was
> designed for the purpose of setting the LED status on connect, as I
> found that it actually does not work at all. It appears to try to send
> the data, but nothing actually happens to the controller LEDs.
Attached is a reply I sent to on 7/4/11 to which you unfortunately never
responded. The issue is that of force feedback (rumble) and LED share the
same URB then access to that URB should be arbitrated. The attached
message contains a patch that attempts to implement that arbitration,
could you please try it out and see what changes are needed to make it
work?
Thanks.
--
Dmitry--- Begin Message ---
On Sun, Jun 12, 2011 at 05:49:49PM -0700, Chris Moeller wrote:
> This patch removes the non-functional bulk output URB method for setting
> XBox360 Wireless Controller player number indicators on controller
> activation, and replaces it with a functional IRQ output URB method. It
> also implements the LED command control for these devices.
>
> Signed-off-by: Chris Moeller
>
> ---
>
> I chose to duplicate the LED command setting function in the
> xpad360w_process_packet function, as the other LED setting function is
> designed to require mutex locking, which I found to deadlock the driver
> when used in that manner. I will consider adding a lock, as testing with
> a rumble flooding application collided with the LED control and
> prevented it from setting the player number on connect. I'm not even
> sure how the mutex could be deadlocking in the input packet handler, or
> even what good it would do in that case, since the rumble setting
> functions don't lock it. In fact, only the LED setting function locks
> it.
If 2 functions share the same URB then we need to arbitrate access to
URB data buffers, etc, etc. I believe the patch below could be used as a
starting point.
Thanks.
--
Dmitry
Input: xpad - wireless LED setting
From: Chris Moeller
This patch removes the non-functional bulk output URB method for setting
XBox360 Wireless Controller player number indicators on controller
activation, and replaces it with a functional IRQ output URB method. It
also implements the LED command control for these devices.
Signed-off-by: Chris Moeller
Signed-off-by: Dmitry Torokhov
---
drivers/input/joystick/xpad.c | 699 ++---
1 files changed, 379 insertions(+), 320 deletions(-)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index d728875..e2dbe54 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -253,23 +253,28 @@ struct usb_xpad {
struct input_dev *dev; /* input device interface */
struct usb_device *udev;/* usb device */
- int pad_present;
+ int interface_number;
struct urb *irq_in; /* urb for interrupt in report */
unsigned char *idata; /* input data */
dma_addr_t idata_dma;
- struct urb *bulk_out;
- unsigned char *bdata;
-
#if defined(CONFIG_JOYSTICK_XPAD_FF) || defined(CONFIG_JOYSTICK_XPAD_LEDS)
struct urb *irq_out;/* urb for interrupt out report */
unsigned char *odata; /* output data */
dma_addr_t odata_dma;
- struct mutex odata_mutex;
+ spinlock_t odata_lock;
+ bool irq_out_pending;
+
+ bool led_pending;
+ int led_command;
+
+ bool ff_pending;
+ u16 rumble_strong;
+ u16 rumble_weak;
#endif
-#if defined(CONFIG_JOYSTICK_XPAD_LEDS)
+#ifdef CONFIG_JOYSTICK_XPAD_LEDS
struct xpad_led *led;
#endif
@@ -279,6 +284,369 @@ struct usb_xpad {
int xtype; /* type of xbox device */
};
+#ifdef CONFIG_JOYSTICK_XPAD_FF
+static bool xpad_format_rumble(struct usb_xpad *xpad, u16 strong, u16 weak)
+{
+ switch (xpad->xtype) {
+
+ case XTYPE_XBOX:
+ xpad->odata[0] = 0x00;
+ xpad->odata[1] = 0x06;
+ xpad->odata[2] = 0x00;
+ xpad->odata[3] = strong / 256; /* left actuator */
+ xpad->odata[4] = 0x00;
+ xpad->odata[5] = weak / 256;/* right actuator */
+ xpad->irq_out->transfer_buffer_length = 6;
+
+ return true;
+
+ case XTYPE_XBOX360:
+ xpad->
Re: [PATCH] Avoid dead lock of console related locks in panic case
On Fri, 30 Nov 2012 17:11:07 + Seiji Aguchi wrote: > If one cpu ,which is taking a logbuf_lock or console_sem, > receive IPI/NMI from a panicked cpu via smp_send_stop(), > the panicked cpu hangs up in subsequent kmsg_dump()/printk() > because logbuf_lock and console_sem are taken in the function calls. > > This causes a console blank and users can't see panic messages. > > [Solution] > > this patch introduces a logic initializing logbuf_lock and console_sem > just after smp_send_stop() to avoid dead locks above. That is one nasty looking patch :( - Makes the logic in this area even more twisty and complex, when what we need to do is to simplify it - Reinitialises in-use locks - Gives the boolean variable "yes" three states, but didn't rename that variable to something appropriate. - Passes yes==2 into s390's unsuspecting bust_spinlocks() implementation. Let's step back a bit. Please identify with great specificity the code sites which are stopping other CPUs before taking locks which those other CPUs might have been holding. Then let's see what we can do to fix up the callers, instead of trying to tidy up after they have made this mess. -- 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] Smack: Add missing depends on INET in Kconfig
On 11/30/2012 2:01 PM, Eric Paris wrote: > Do other LSMs need this too Casey? I remember we mentioned how select > was dangerous :-( I don't see any missing dependencies, but then, I missed INET. Yes, you mentioned that it was dangerous. > > On Fri, Nov 30, 2012 at 12:28 PM, Casey Schaufler > wrote: >> Because NETLABEL depends on INET SECURITY_SMACK >> has to explicitly call out the dependency. >> >> Signed-off-by: Casey Schaufler >> --- >> security/smack/Kconfig |1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/security/smack/Kconfig b/security/smack/Kconfig >> index 9fb14ef..1be1088 100644 >> --- a/security/smack/Kconfig >> +++ b/security/smack/Kconfig >> @@ -1,5 +1,6 @@ >> config SECURITY_SMACK >> bool "Simplified Mandatory Access Control Kernel Support" >> + depends on INET >> depends on NET >> depends on SECURITY >> select NETLABEL >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/17] ARM: shmobile: fix memory size for kota2_defconfig
Hi, On Thu, Oct 4, 2012 at 1:58 AM, Simon Horman wrote: > On Thu, Oct 04, 2012 at 08:34:54AM +, Arnd Bergmann wrote: >> On Wednesday 03 October 2012, Simon Horman wrote: >> > I looked through my fines and found a config that I believe >> > worked with a derivative of 2.6.35.7. >> > >> > It has CONFIG_MEMORY_SIZE=0x1e80. >> > >> > So what I suspect has happened is that an extra zero has crept into >> > arch/arm/configs/kota2_defconfig and the intended value is: >> > >> > CONFIG_MEMORY_SIZE=0x1e00 >> > >> > Unfortunately I do not have access to a board to test this, >> > nor am I aware of anyone who does. >> >> Ok, I'll drop this patch for now then, so we keep the warning around >> to remind us of the problem. > > Thanks. I have subsequently located a Kota2 board, > however it may be a little while before I get my hands on it. Gentle ping. I just came across this warning again so I figured I'd check. -Olof -- 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] bdi: add a user-tunable cpu_list for the bdi flusher threads
> + ret = cpulist_parse(buf, newmask);
> + if (!ret) {
> + spin_lock(&bdi->wb_lock);
> + task = wb->task;
> + get_task_struct(task);
> + spin_unlock(&bdi->wb_lock);
> + if (task)
> + ret = set_cpus_allowed_ptr(task, newmask);
> + put_task_struct(task);
If that test for a non-null task is needed then surely the get and put
need to be similarly protected :).
> + bdi->flusher_cpumask = kmalloc(sizeof(cpumask_t), GFP_KERNEL);
> + if (!bdi->flusher_cpumask)
> + return -ENOMEM;
The bare GFP_KERNEL raises an eyebrow. Some bdi_init() callers like
blk_alloc_queue_node() look like they'll want to pass in a gfp_t for the
allocation.
And shouldn't this be freed in the error path of bdi_init()?
- z
--
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/
[tip:x86/urgent] x86, fpu: Avoid FPU lazy restore after suspend
Commit-ID: 644c154186386bb1fa6446bc5e037b9ed098db46
Gitweb: http://git.kernel.org/tip/644c154186386bb1fa6446bc5e037b9ed098db46
Author: Vincent Palatin
AuthorDate: Fri, 30 Nov 2012 12:15:32 -0800
Committer: H. Peter Anvin
CommitDate: Fri, 30 Nov 2012 13:48:05 -0800
x86, fpu: Avoid FPU lazy restore after suspend
When a cpu enters S3 state, the FPU state is lost.
After resuming for S3, if we try to lazy restore the FPU for a process running
on the same CPU, this will result in a corrupted FPU context.
Ensure that "fpu_owner_task" is properly invalided when (re-)initializing a CPU,
so nobody will try to lazy restore a state which doesn't exist in the hardware.
Tested with a 64-bit kernel on a 4-core Ivybridge CPU with eagerfpu=off,
by doing thousands of suspend/resume cycles with 4 processes doing FPU
operations running. Without the patch, a process is killed after a
few hundreds cycles by a SIGFPE.
Cc: Duncan Laurie
Cc: Olof Johansson
Cc: v3.4+ # for 3.4 need to replace this_cpu_write by
percpu_write
Signed-off-by: Vincent Palatin
Link:
http://lkml.kernel.org/r/1354306532-1014-1-git-send-email-vpala...@chromium.org
Signed-off-by: H. Peter Anvin
---
arch/x86/include/asm/fpu-internal.h | 15 +--
arch/x86/kernel/smpboot.c | 5 +
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/fpu-internal.h
b/arch/x86/include/asm/fpu-internal.h
index 831dbb9..41ab26e 100644
--- a/arch/x86/include/asm/fpu-internal.h
+++ b/arch/x86/include/asm/fpu-internal.h
@@ -399,14 +399,17 @@ static inline void drop_init_fpu(struct task_struct *tsk)
typedef struct { int preload; } fpu_switch_t;
/*
- * FIXME! We could do a totally lazy restore, but we need to
- * add a per-cpu "this was the task that last touched the FPU
- * on this CPU" variable, and the task needs to have a "I last
- * touched the FPU on this CPU" and check them.
+ * Must be run with preemption disabled: this clears the fpu_owner_task,
+ * on this CPU.
*
- * We don't do that yet, so "fpu_lazy_restore()" always returns
- * false, but some day..
+ * This will disable any lazy FPU state restore of the current FPU state,
+ * but if the current thread owns the FPU, it will still be saved by.
*/
+static inline void __cpu_disable_lazy_restore(unsigned int cpu)
+{
+ per_cpu(fpu_owner_task, cpu) = NULL;
+}
+
static inline int fpu_lazy_restore(struct task_struct *new, unsigned int cpu)
{
return new == this_cpu_read_stable(fpu_owner_task) &&
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index c80a33b..f3e2ec8 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -68,6 +68,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -818,6 +820,9 @@ int __cpuinit native_cpu_up(unsigned int cpu, struct
task_struct *tidle)
per_cpu(cpu_state, cpu) = CPU_UP_PREPARE;
+ /* the FPU context is blank, nobody can own it */
+ __cpu_disable_lazy_restore(cpu);
+
err = do_boot_cpu(apicid, cpu, tidle);
if (err) {
pr_debug("do_boot_cpu failed %d\n", err);
--
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/
[GIT PULL] (xen) stable/for-jens-3.8 bug-fixes..
Hey Jens Please git pull the following branch git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git stable/for-jens-3.8 which has one cleanup and one tiny fix. Please pull! Roger Pau Monne (2): xen-blkback: move free persistent grants code xen-blkfront: free allocated page drivers/block/xen-blkback/blkback.c | 68 - drivers/block/xen-blkfront.c| 1 + 2 files changed, 38 insertions(+), 31 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Smack: Add missing depends on INET in Kconfig
Do other LSMs need this too Casey? I remember we mentioned how select was dangerous :-( On Fri, Nov 30, 2012 at 12:28 PM, Casey Schaufler wrote: > Because NETLABEL depends on INET SECURITY_SMACK > has to explicitly call out the dependency. > > Signed-off-by: Casey Schaufler > --- > security/smack/Kconfig |1 + > 1 file changed, 1 insertion(+) > > diff --git a/security/smack/Kconfig b/security/smack/Kconfig > index 9fb14ef..1be1088 100644 > --- a/security/smack/Kconfig > +++ b/security/smack/Kconfig > @@ -1,5 +1,6 @@ > config SECURITY_SMACK > bool "Simplified Mandatory Access Control Kernel Support" > + depends on INET > depends on NET > depends on SECURITY > select NETLABEL > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/2] Add documentation for tca6507 devicetree bindings.
Signed-off-by: Marek Belisko
---
Documentation/devicetree/bindings/leds/tca6507.txt | 33
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/tca6507.txt
diff --git a/Documentation/devicetree/bindings/leds/tca6507.txt
b/Documentation/devicetree/bindings/leds/tca6507.txt
new file mode 100644
index 000..2b6693b
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/tca6507.txt
@@ -0,0 +1,33 @@
+LEDs conected to tca6507
+
+Required properties:
+- compatible : should be : "ti,tca6507".
+
+Each led is represented as a sub-node of the ti,tca6507 device.
+
+LED sub-node properties:
+- label : (optional) see Documentation/devicetree/bindings/leds/common.txt
+- reg : number of LED line (could be from 0 to 6)
+- linux,default-trigger : (optional)
+ see Documentation/devicetree/bindings/leds/common.txt
+
+Examples:
+
+tca6507@45 {
+ compatible = "ti,tca6507";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x45>;
+
+ led0: red-aux@0 {
+ label = "red:aux";
+ reg = <0x0>;
+ };
+
+ led1: green-aux@1 {
+ label = "green:aux";
+ reg = <0x5>;
+ linux,default-trigger = "default-on";
+ };
+};
+
--
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/
[PATCH v4 1/2] leds/tca6507: Add support for devicetree.
Support added only for leds (not for gpio's).
Signed-off-by: Marek Belisko
---
Changes from v3:
- fix code according Bryan suggestions
- use common leds binding description instead copy'n'paste
- use "-" instead "_" in bindings example for leds names
Changes from v2:
- change compatible property to "ti,tca6507"
- add documentation for linux,default-trigger
Changes from v1:
- return proper error value not NULL from tca6507_led_dt_init()
- remove empty lines
- remove kfree()
drivers/leds/leds-tca6507.c | 74 +--
1 file changed, 71 insertions(+), 3 deletions(-)
diff --git a/drivers/leds/leds-tca6507.c b/drivers/leds/leds-tca6507.c
index b26a63b..3ad46fb 100644
--- a/drivers/leds/leds-tca6507.c
+++ b/drivers/leds/leds-tca6507.c
@@ -667,6 +667,70 @@ static void tca6507_remove_gpio(struct tca6507_chip *tca)
}
#endif /* CONFIG_GPIOLIB */
+#ifdef CONFIG_OF
+static struct tca6507_platform_data *
+tca6507_led_dt_init(struct i2c_client *client)
+{
+ struct device_node *np = client->dev.of_node, *child;
+ struct tca6507_platform_data *pdata;
+ struct led_info *tca_leds;
+ int count = 0;
+
+ for_each_child_of_node(np, child)
+ count++;
+ if (!count)
+ return ERR_PTR(-ENODEV);
+
+ if (count > NUM_LEDS)
+ return ERR_PTR(-ENODEV);
+
+ tca_leds = devm_kzalloc(&client->dev,
+ sizeof(struct led_info) * count, GFP_KERNEL);
+ if (!tca_leds)
+ return ERR_PTR(-ENOMEM);
+
+ for_each_child_of_node(np, child) {
+ struct led_info led;
+ u32 reg;
+ int ret;
+
+ led.name =
+ of_get_property(child, "label", NULL) ? : child->name;
+ led.default_trigger =
+ of_get_property(child, "linux,default-trigger", NULL);
+
+ ret = of_property_read_u32(child, "reg", ®);
+ if (ret != 0)
+ continue;
+
+ tca_leds[reg] = led;
+ }
+ pdata = devm_kzalloc(&client->dev,
+ sizeof(struct tca6507_platform_data), GFP_KERNEL);
+ if (!pdata)
+ return ERR_PTR(-ENOMEM);
+
+ pdata->leds.leds = tca_leds;
+ pdata->leds.num_leds = count;
+
+ return pdata;
+}
+
+static const struct of_device_id of_tca6507_leds_match[] = {
+ { .compatible = "ti,tca6507", },
+ {},
+};
+
+#else
+static tca6507_platform_data *
+tca6507_led_dt_init(struct i2c_client *client)
+{
+ return ERR_PRT(-ENODEV);
+}
+
+#define of_tca6507_leds_match NULL
+#endif
+
static int tca6507_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -683,9 +747,12 @@ static int tca6507_probe(struct i2c_client *client,
return -EIO;
if (!pdata || pdata->leds.num_leds != NUM_LEDS) {
- dev_err(&client->dev, "Need %d entries in platform-data list\n",
- NUM_LEDS);
- return -ENODEV;
+ pdata = tca6507_led_dt_init(client);
+ if (IS_ERR(pdata)) {
+ dev_err(&client->dev, "Need %d entries in platform-data
list\n",
+ NUM_LEDS);
+ return PTR_ERR(pdata);
+ }
}
tca = devm_kzalloc(&client->dev, sizeof(*tca), GFP_KERNEL);
if (!tca)
@@ -750,6 +817,7 @@ static struct i2c_driver tca6507_driver = {
.driver = {
.name= "leds-tca6507",
.owner = THIS_MODULE,
+ .of_match_table = of_tca6507_leds_match,
},
.probe= tca6507_probe,
.remove = tca6507_remove,
--
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/
[PATCH v2 1/1] Input: xpad - Implement wireless controller LED setting and fix connect time LED setting
Signed-off-by: Chris Moeller
---
diff -urpN a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
--- a/drivers/input/joystick/xpad.c 2012-11-30 12:33:10.604607590 -0800
+++ b/drivers/input/joystick/xpad.c 2012-11-30 12:41:19.374756212 -0800
@@ -260,13 +260,12 @@ struct usb_xpad {
int pad_present;
+ int interface_number;
+
struct urb *irq_in; /* urb for interrupt in report */
unsigned char *idata; /* input data */
dma_addr_t idata_dma;
- struct urb *bulk_out;
- unsigned char *bdata;
-
#if defined(CONFIG_JOYSTICK_XPAD_FF) || defined(CONFIG_JOYSTICK_XPAD_LEDS)
struct urb *irq_out;/* urb for interrupt out report */
unsigned char *odata; /* output data */
@@ -427,6 +426,33 @@ static void xpad360_process_packet(struc
}
/*
+ * xpad360w_send_led_command
+ *
+ * Sends an LED state change command without any mutex locking. It is designed
+ * for private use, or by public interfaces which have already requested the
+ * appropriate locks.
+ *
+ */
+
+static void xpad360w_send_led_command(struct usb_xpad *xpad, int command)
+{
+ xpad->odata[0] = 0x00;
+ xpad->odata[1] = 0x00;
+ xpad->odata[2] = 0x08;
+ xpad->odata[3] = 0x40 + command;
+ xpad->odata[4] = 0x00;
+ xpad->odata[5] = 0x00;
+ xpad->odata[6] = 0x00;
+ xpad->odata[7] = 0x00;
+ xpad->odata[8] = 0x00;
+ xpad->odata[9] = 0x00;
+ xpad->odata[10] = 0x00;
+ xpad->odata[11] = 0x00;
+ xpad->irq_out->transfer_buffer_length = 12;
+ usb_submit_urb(xpad->irq_out, GFP_KERNEL);
+}
+
+/*
* xpad360w_process_packet
*
* Completes a request by converting the data into events for the
@@ -447,7 +473,7 @@ static void xpad360w_process_packet(stru
if (data[0] & 0x08) {
if (data[1] & 0x80) {
xpad->pad_present = 1;
- usb_submit_urb(xpad->bulk_out, GFP_ATOMIC);
+ xpad360w_send_led_command(xpad, 2 +
(xpad->interface_number & 6) / 2);
} else
xpad->pad_present = 0;
}
@@ -502,28 +528,6 @@ exit:
__func__, retval);
}
-static void xpad_bulk_out(struct urb *urb)
-{
- struct usb_xpad *xpad = urb->context;
- struct device *dev = &xpad->intf->dev;
-
- switch (urb->status) {
- case 0:
- /* success */
- break;
- case -ECONNRESET:
- case -ENOENT:
- case -ESHUTDOWN:
- /* this urb is terminated, clean up */
- dev_dbg(dev, "%s - urb shutting down with status: %d\n",
- __func__, urb->status);
- break;
- default:
- dev_dbg(dev, "%s - nonzero urb status received: %d\n",
- __func__, urb->status);
- }
-}
-
#if defined(CONFIG_JOYSTICK_XPAD_FF) || defined(CONFIG_JOYSTICK_XPAD_LEDS)
static void xpad_irq_out(struct urb *urb)
{
@@ -704,14 +708,24 @@ struct xpad_led {
static void xpad_send_led_command(struct usb_xpad *xpad, int command)
{
- if (command >= 0 && command < 14) {
- mutex_lock(&xpad->odata_mutex);
- xpad->odata[0] = 0x01;
- xpad->odata[1] = 0x03;
- xpad->odata[2] = command;
- xpad->irq_out->transfer_buffer_length = 3;
- usb_submit_urb(xpad->irq_out, GFP_KERNEL);
- mutex_unlock(&xpad->odata_mutex);
+ if (xpad->xtype == XTYPE_XBOX || xpad->xtype == XTYPE_XBOX360) {
+ if (command >= 0 && command < 14) {
+ mutex_lock(&xpad->odata_mutex);
+ xpad->odata[0] = 0x01;
+ xpad->odata[1] = 0x03;
+ xpad->odata[2] = command;
+ xpad->irq_out->transfer_buffer_length = 3;
+ usb_submit_urb(xpad->irq_out, GFP_KERNEL);
+ mutex_unlock(&xpad->odata_mutex);
+ }
+ } else if (xpad->xtype == XTYPE_XBOX360W) {
+ if (command >= 0 && command < 17) {
+ if (command == 16)
+ command = 2 + (xpad->interface_number & 6) / 2;
+ mutex_lock(&xpad->odata_mutex);
+ xpad360w_send_led_command(xpad, command);
+ mutex_unlock(&xpad->odata_mutex);
+ }
}
}
@@ -732,7 +746,7 @@ static int xpad_led_probe(struct usb_xpa
struct led_classdev *led_cdev;
int error;
- if (xpad->xtype != XTYPE_XBOX360)
+ if (xpad->xtype != XTYPE_XBOX360 && xpad->xtype != XTYPE_XBOX360W)
return 0;
xpad->led = led = kzalloc(sizeof(struct xpad_led), GFP_KERNEL);
@@ -758,7 +772,8 @@ static int xpad_led_probe(struct usb_xpa
/*
* Light up the segment corresponding to controller num
[PATCH v2 0/1] Input: xpad - Implement wireless controller LED setting and fix connect time LED setting
I've submitted versions of this with prior patch sets, and this part was never accepted, possibly because it depended on other patches to work, or possibly because it wasn't so cleanly organized. This time, I've split the LED setting command off into its own static function, then call that on controller connect and optionally on LED setting commands. The static function does not include any locking, because locking inside the function which receives the incoming packets deadlocks the driver, and does not appear to be necessary anyway. It also removes all traces of the original bulk out function which was designed for the purpose of setting the LED status on connect, as I found that it actually does not work at all. It appears to try to send the data, but nothing actually happens to the controller LEDs. -- 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, fpu: avoid FPU lazy restore after suspend
On Fri, Nov 30, 2012 at 11:55 AM, H. Peter Anvin wrote: > > On 11/30/2012 11:54 AM, Vincent Palatin wrote: > >> > > I have done a patch v2 according to your suggestions. > > I will run the testing on it now. > > I probably need at least 2 to 3 hours to validate it. > > > > That would be super. Let me know and I'll queue it up and send a pull > request with this and a few more urgent things to Linus. I have done 1000+ cycles so far with patch v3 (on 4-core Ivybridge and no eagerfpu), and did not hit my issue. I let the testing going on, but wrt the issue after suspend, this fixes it with very high probability (ie I have never done that many cycles without hitting the issue). -- Vincent -- 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] wait: add wait_event_lock_irq() interface
On Fri, 30 Nov 2012 11:42:40 +0100
Lukas Czerner wrote:
> New wait_event{_interruptible}_lock_irq{_cmd} macros added. This commit
> moves the private wait_event_lock_irq() macro from MD to regular wait
> includes, introduces new macro wait_event_lock_irq_cmd() instead of using
> the old method with omitting cmd parameter which is ugly and makes a use
> of new macros in the MD. It also introduces the _interruptible_ variant.
>
> The use of new interface is when one have a special lock to protect data
> structures used in the condition, or one also needs to invoke "cmd"
> before putting it to sleep.
>
> All new macros are expected to be called with the lock taken. The lock
> is released before sleep and is reacquired afterwards. We will leave the
> macro with the lock held.
>
> Note to DM: IMO this should also fix theoretical race on waitqueue while
> using simultaneously wait_event_lock_irq() and wait_event() because of
> lack of locking around current state setting and wait queue removal.
>
> Signed-off-by: Lukas Czerner
> Cc: Neil Brown
> Cc: David Howells
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> ---
> v2: add interruptible variant, swap cmd and schedule, use prepare_to_wait
> v3: swap cmd and schedule so we call cmd before schedule
Your v3 patch reverts
http://ozlabs.org/~akpm/mmots/broken-out/wait-add-wait_event_lock_irq-interface-fix.patch.
Here's what I've queued in -mm:
--- a/include/linux/wait.h~wait-add-wait_event_lock_irq-interface-v3
+++ a/include/linux/wait.h
@@ -555,14 +555,13 @@ do {
\
do { \
DEFINE_WAIT(__wait);\
\
- cmd;\
for (;;) { \
prepare_to_wait(&wq, &__wait, TASK_UNINTERRUPTIBLE);\
if (condition) \
break; \
spin_unlock_irq(&lock); \
- schedule(); \
cmd;\
+ schedule(); \
spin_lock_irq(&lock); \
} \
finish_wait(&wq, &__wait); \
@@ -575,8 +574,8 @@ do {
\
* taken.
* @wq: the waitqueue to wait on
* @condition: a C expression for the event to wait for
- * @lock: a locked spinlock_t, which will be released before schedule()
- * and cmd reacquired afterwards.
+ * @lock: a locked spinlock_t, which will be released before cmd
+ * and schedule() and reacquired afterwards.
* @cmd: a command which is invoked outside the critical section before
* sleep
*
@@ -588,7 +587,7 @@ do {
\
* change the result of the wait condition.
*
* This is supposed to be called while holding the lock. The lock is
- * dropped before going to sleep and invoking the cmd and is reacquired
+ * dropped before invoking the cmd and going to sleep and is reacquired
* afterwards.
*/
#define wait_event_lock_irq_cmd(wq, condition, lock, cmd) \
@@ -631,7 +630,6 @@ do {
\
do { \
DEFINE_WAIT(__wait);\
\
- cmd;\
for (;;) { \
prepare_to_wait(&wq, &__wait, TASK_INTERRUPTIBLE); \
if (condition) \
@@ -641,8 +639,8 @@ do {
\
break; \
} \
spin_unlock_irq(&lock); \
- schedule(); \
cmd;\
+ schedule(); \
spin_lock_irq(&lock); \
}
Re: [PATCH 3/5] xen-pcifront: handle backend CLOSED without CLOSING
On Fri, Nov 30, 2012 at 11:41 AM, Bjorn Helgaas wrote: > On Fri, Oct 19, 2012 at 6:59 AM, Konrad Rzeszutek Wilk > wrote: >> On Thu, Oct 18, 2012 at 11:03:36AM +0100, David Vrabel wrote: >>> From: David Vrabel >>> >>> Backend drivers shouldn't transistion to CLOSED unless the frontend is >>> CLOSED. If a backend does transition to CLOSED too soon then the >>> frontend may not see the CLOSING state and will not properly shutdown. >>> >>> So, treat an unexpected backend CLOSED state the same as CLOSING. >>> >>> Signed-off-by: David Vrabel >>> Acked-by: Konrad Rzeszutek Wilk >>> --- >>> Cc: linux-...@vger.kernel.org >>> Cc: Bjorn Helgaas >> >> Bjorn, do you want me to prep a git pull with this patch >> or can I have your Ack to put it my tree and have it part of my >> git pull to Linus? > > Sorry, I missed this. I can put it in my -next branch for the v3.8 > merge window. Would that work for you? I put this in my -next branch, so we'll at least have a chance of making a linux-next cycle before v3.7 pops. >>> --- >>> drivers/pci/xen-pcifront.c |5 - >>> 1 files changed, 4 insertions(+), 1 deletions(-) >>> >>> diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c >>> index 0aab85a..a0c7312 100644 >>> --- a/drivers/pci/xen-pcifront.c >>> +++ b/drivers/pci/xen-pcifront.c >>> @@ -1068,13 +1068,16 @@ static void __init_refok >>> pcifront_backend_changed(struct xenbus_device *xdev, >>> case XenbusStateInitialising: >>> case XenbusStateInitWait: >>> case XenbusStateInitialised: >>> - case XenbusStateClosed: >>> break; >>> >>> case XenbusStateConnected: >>> pcifront_try_connect(pdev); >>> break; >>> >>> + case XenbusStateClosed: >>> + if (xdev->state == XenbusStateClosed) >>> + break; >>> + /* Missed the backend's CLOSING state -- fallthrough */ >>> case XenbusStateClosing: >>> dev_warn(&xdev->dev, "backend going away!\n"); >>> pcifront_try_disconnect(pdev); >>> -- >>> 1.7.2.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] uio.c: Fix warning: 'ret' might be used uninitialized
On Fri, Nov 30, 2012 at 01:16:19PM +0200, Vitalii Demianets wrote:
> On Friday 30 November 2012 01:58:22 Hans J. Koch wrote:
> > On Thu, Nov 29, 2012 at 06:36:59PM +0200, Vitalii Demianets wrote:
> > > > On Thursday 29 November 2012 18:05:27 Tux9 wrote:
> > > > > Hans, I think there are something wrong in your patch, while
> > > > > Vitalii's is right. The variable "ret" is reused in line 292 and line
> > > > > 295, so the value of "ret" would be overridden (if it goto err_map in
> > > > > line 284 when mi>=1).
> > > >
> > > > Actually, both patches do exactly the same thing. Hans's patch
> > > > establishes default value for the ret for all those "other" cases when
> > > > ret is not explicitly overridden. My patch explicitly enumerates all
> > > > those "other" cases in more wordily manner.
> > >
> > > Oops, disregard this. After looking at it more thoroughly I got your
> > > point. You are right, ret is overridden at first iteration (mi == 0), so
> > > Hans's approach does not work.
> > > I must do more thinking before replying in a hurry.
> >
> > You're right. Initialization of "ret" has to take place at the beginning of
> > the loop.
> >
> > I think this version is right:
>
> Yes, this looks right for me.
OK, I'll send that patch offically, then. This might also be material for
the stable updates. Greg?
Thanks a lot for reporting and discussing that problem. I'll add a
Reported-by: Vitalii Demianets
if you have no objections.
Thanks,
Hans
>
> > >From 00c3c734c0dde67873a628bcb18cee403c95c301 Mon Sep 17 00:00:00 2001
> >
> > From: "Hans J. Koch"
> > Date: Fri, 30 Nov 2012 00:51:50 +0100
> > Subject: [PATCH] uio: Fix warning: 'ret' might be used uninitialized
> >
> > In two cases, the return value variable "ret" can be undefined.
> >
> > Signed-off-by: Hans J. Koch
> > ---
> > drivers/uio/uio.c |2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> > index 5110f36..0c80df2 100644
> > --- a/drivers/uio/uio.c
> > +++ b/drivers/uio/uio.c
> > @@ -273,6 +273,7 @@ static int uio_dev_add_attributes(struct uio_device
> > *idev) struct uio_portio *portio;
> >
> > for (mi = 0; mi < MAX_UIO_MAPS; mi++) {
> > + ret = -ENOMEM;
> > mem = &idev->info->mem[mi];
> > if (mem->size == 0)
> > break;
> > @@ -298,6 +299,7 @@ static int uio_dev_add_attributes(struct uio_device
> > *idev) }
> >
> > for (pi = 0; pi < MAX_UIO_PORT_REGIONS; pi++) {
> > + ret = -ENOMEM;
> > port = &idev->info->port[pi];
> > if (port->size == 0)
> > break;
>
--
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 v3 3/3] aerdrv: Cleanup log output for CPER based AER
These changes make cper_print_aer more consistent with aer_print_error
which is called in the AER interrupt case. The string in the variable
'prefix' is printed at the beginning of each print statement in
cper_print_aer(). The prefix is a string containing the driver name
and the device's path. Looking up the call path, the value of prefix
is never assigned and is NULL, so when cper_print_aer prints data the
initial string does not get printed. This string is important because
it identifies the device that the error is on. This patch adds code to
create the prefix and print it in the cper_print_aer function. This
patch also calculates the device's agent id so it can be printed.
v1-v2 fix some compile errors withinn the #ifdef
Signed-off-by: Lance Ortiz
---
drivers/pci/pcie/aer/aerdrv_errprint.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/pcie/aer/aerdrv_errprint.c
b/drivers/pci/pcie/aer/aerdrv_errprint.c
index 34d96e4..5050891 100644
--- a/drivers/pci/pcie/aer/aerdrv_errprint.c
+++ b/drivers/pci/pcie/aer/aerdrv_errprint.c
@@ -228,9 +228,15 @@ void cper_print_aer(struct pci_dev *dev, int cper_severity,
int aer_severity, layer, agent, status_strs_size, tlp_header_valid = 0;
u32 status, mask;
const char **status_strs;
- char *prefix = NULL;
+ int id = ((dev->bus->number << 8) | dev->devfn);
+ char prefix[44];
aer_severity = cper_severity_to_aer(cper_severity);
+ snprintf(prefix, sizeof(prefix), "%s%s %s: ",
+ (aer_severity == AER_CORRECTABLE) ?
+ KERN_WARNING : KERN_ERR,
+ dev_driver_string(&dev->dev), dev_name(&dev->dev));
+
if (aer_severity == AER_CORRECTABLE) {
status = aer->cor_status;
mask = aer->cor_mask;
@@ -248,8 +254,8 @@ void cper_print_aer(struct pci_dev *dev, int cper_severity,
printk("%s""aer_status: 0x%08x, aer_mask: 0x%08x\n",
prefix, status, mask);
cper_print_bits(prefix, status, status_strs, status_strs_size);
- printk("%s""aer_layer=%s, aer_agent=%s\n", prefix,
- aer_error_layer[layer], aer_agent_string[agent]);
+ printk("%s""aer_layer=%s, id=%04x(%s)\n", prefix,
+ aer_error_layer[layer], id, aer_agent_string[agent]);
if (aer_severity != AER_CORRECTABLE)
printk("%s""aer_uncor_severity: 0x%08x\n",
prefix, aer->uncor_severity);
--
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 v3 2/3] aerdrv: Enhanced AER logging
This patch will provide a more reliable and easy way for user-space
applications to have access to AER logs rather than reading them from the
message buffer. It also provides a way to notify user-space when an AER
event occurs.
The aer driver is updated to generate a trace event of function 'aer_event'
when an AER occurs. The trace event was added to both the interrupt
based aer path and the firmware first path
v1-v2 fix compile errors in ifdefs.
v2-v3 Update to new location of trace header. Update print to remove
warning.
Signed-off-by: Lance Ortiz
---
drivers/acpi/apei/cper.c | 17 +++--
drivers/pci/pcie/aer/aerdrv_errprint.c | 10 +-
include/linux/aer.h|2 +-
3 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/apei/cper.c b/drivers/acpi/apei/cper.c
index e6defd8..e9d6062 100644
--- a/drivers/acpi/apei/cper.c
+++ b/drivers/acpi/apei/cper.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
/*
@@ -249,6 +250,10 @@ static const char *cper_pcie_port_type_strs[] = {
static void cper_print_pcie(const char *pfx, const struct cper_sec_pcie *pcie,
const struct acpi_hest_generic_data *gdata)
{
+#ifdef CONFIG_ACPI_APEI_PCIEAER
+ struct pci_dev *dev;
+#endif
+
if (pcie->validation_bits & CPER_PCIE_VALID_PORT_TYPE)
printk("%s""port_type: %d, %s\n", pfx, pcie->port_type,
pcie->port_type < ARRAY_SIZE(cper_pcie_port_type_strs) ?
@@ -281,9 +286,17 @@ static void cper_print_pcie(const char *pfx, const struct
cper_sec_pcie *pcie,
"%s""bridge: secondary_status: 0x%04x, control: 0x%04x\n",
pfx, pcie->bridge.secondary_status, pcie->bridge.control);
#ifdef CONFIG_ACPI_APEI_PCIEAER
- if (pcie->validation_bits & CPER_PCIE_VALID_AER_INFO) {
+ dev = pci_get_domain_bus_and_slot(pcie->device_id.segment,
+ pcie->device_id.bus, pcie->device_id.function);
+ if (!dev)
+ pr_info("PCI AER Cannot get PCI device %04x:%02x:%02x.%d\n",
+ pcie->device_id.segment, pcie->device_id.bus,
+ pcie->device_id.slot, pcie->device_id.function);
+
+ if (pcie->validation_bits & CPER_PCIE_VALID_AER_INFO && dev) {
struct aer_capability_regs *aer_regs = (void *)pcie->aer_info;
- cper_print_aer(pfx, gdata->error_severity, aer_regs);
+ cper_print_aer(dev, gdata->error_severity, aer_regs);
+ pci_dev_put(dev);
}
#endif
}
diff --git a/drivers/pci/pcie/aer/aerdrv_errprint.c
b/drivers/pci/pcie/aer/aerdrv_errprint.c
index 3ea5173..34d96e4 100644
--- a/drivers/pci/pcie/aer/aerdrv_errprint.c
+++ b/drivers/pci/pcie/aer/aerdrv_errprint.c
@@ -23,6 +23,9 @@
#include "aerdrv.h"
+#define CREATE_TRACE_POINTS
+#include
+
#define AER_AGENT_RECEIVER 0
#define AER_AGENT_REQUESTER1
#define AER_AGENT_COMPLETER2
@@ -194,6 +197,8 @@ void aer_print_error(struct pci_dev *dev, struct
aer_err_info *info)
if (info->id && info->error_dev_num > 1 && info->id == id)
printk("%s"" Error of this Agent(%04x) is reported first\n",
prefix, id);
+ trace_aer_event(dev_name(&dev->dev), (info->status & ~info->mask),
+ info->severity);
}
void aer_print_port_info(struct pci_dev *dev, struct aer_err_info *info)
@@ -217,12 +222,13 @@ int cper_severity_to_aer(int cper_severity)
}
EXPORT_SYMBOL_GPL(cper_severity_to_aer);
-void cper_print_aer(const char *prefix, int cper_severity,
+void cper_print_aer(struct pci_dev *dev, int cper_severity,
struct aer_capability_regs *aer)
{
int aer_severity, layer, agent, status_strs_size, tlp_header_valid = 0;
u32 status, mask;
const char **status_strs;
+ char *prefix = NULL;
aer_severity = cper_severity_to_aer(cper_severity);
if (aer_severity == AER_CORRECTABLE) {
@@ -259,5 +265,7 @@ void cper_print_aer(const char *prefix, int cper_severity,
*(tlp + 8), *(tlp + 15), *(tlp + 14),
*(tlp + 13), *(tlp + 12));
}
+ trace_aer_event(dev_name(&dev->dev), (status & ~mask),
+ aer_severity);
}
#endif
diff --git a/include/linux/aer.h b/include/linux/aer.h
index 544abdb..7b86dc6 100644
--- a/include/linux/aer.h
+++ b/include/linux/aer.h
@@ -49,7 +49,7 @@ static inline int
pci_cleanup_aer_uncorrect_error_status(struct pci_dev *dev)
}
#endif
-extern void cper_print_aer(const char *prefix, int cper_severity,
+extern void cper_print_aer(struct pci_dev *dev, int cper_severity,
struct aer_capability_regs *aer);
extern int cper_severity_to_aer(int cper_severity);
extern void aer_recover_queue(int domain, unsigned int bus, unsigned int devfn,
--
To unsubscribe from this list: send the line "u
[PATCH v3 1/3] aerdrv: Trace Event for AER
This header file will define a new trace event that will be triggered when
a AER event occurs. The following data will be provided to the trace
event.
char * name - String containing the device path
u32 status -Either the correctable or uncorrectable register
indicating what error or errors have been see.
u8 severity - error severity 0:NONFATAL 1:FATAL 2:CORRECTED
The trace event will also provide a trace string that may look like:
":05:00.0 PCIe Bus Error:severity=Uncorrected (Non-Fatal), Poisoned
TLP"
v1-v2 Move header from include/ras/aer_event.h to
include/trace/events/ras.h
Signed-off-by: Lance Ortiz
---
include/trace/events/ras.h | 77
1 files changed, 77 insertions(+), 0 deletions(-)
create mode 100644 include/trace/events/ras.h
diff --git a/include/trace/events/ras.h b/include/trace/events/ras.h
new file mode 100644
index 000..f77d009
--- /dev/null
+++ b/include/trace/events/ras.h
@@ -0,0 +1,77 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM aer_event
+#define TRACE_INCLUDE_FILE ras
+
+#if !defined(_TRACE_AER_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_AER_H
+
+#include
+#include
+
+
+/*
+ * Anhance Error Reporting (AER) PCIE Report Error
+ *
+ * These events are generated when hardware detects a corrected or
+ * uncorrected event on a pci express device and reports
+ * errors. The event reports the following data.
+ *
+ * char * dev_name - String containing the device identification
+ * u32 status -Either the correctable or uncorrectable register
+ * indicating what error or errors have been seen
+ * u8 severity - error severity 0:NONFATAL 1:FATAL 2:CORRECTED
+ */
+
+#define correctable_error_string \
+ {BIT(0),"Receiver Error"}, \
+ {BIT(6),"Bad TLP"}, \
+ {BIT(7),"Bad DLLP"},\
+ {BIT(8),"RELAY_NUM Rollover"}, \
+ {BIT(12), "Replay Timer Timeout"},\
+ {BIT(13), "Advisory Non-Fatal"}
+
+#define uncorrectable_error_string \
+ {BIT(4),"Data Link Protocol"}, \
+ {BIT(12), "Poisoned TLP"},\
+ {BIT(13), "Flow Control Protocol"}, \
+ {BIT(14), "Completion Timeout"}, \
+ {BIT(15), "Completer Abort"}, \
+ {BIT(16), "Unexpected Completion"}, \
+ {BIT(17), "Receiver Overflow"}, \
+ {BIT(18), "Malformed TLP"}, \
+ {BIT(19), "ECRC"},\
+ {BIT(20), "Unsupported Request"}
+
+TRACE_EVENT(aer_event,
+ TP_PROTO(const char *dev_name,
+const u32 status,
+const u8 severity),
+
+ TP_ARGS(dev_name, status, severity),
+
+ TP_STRUCT__entry(
+ __string( dev_name, dev_name)
+ __field(u32,status )
+ __field(u8, severity)
+ ),
+
+ TP_fast_assign(
+ __assign_str(dev_name, dev_name);
+ __entry->status = status;
+ __entry->severity = severity;
+ ),
+
+ TP_printk("%s PCIe Bus Error: severity=%s, %s\n",
+ __get_str(dev_name),
+ (__entry->severity == HW_EVENT_ERR_CORRECTED) ? "Corrected" :
+ ((__entry->severity == HW_EVENT_ERR_FATAL) ?
+ "Fatal" : "Uncorrected"),
+ __entry->severity == HW_EVENT_ERR_CORRECTED ?
+ __print_flags(__entry->status, "|", correctable_error_string) :
+ __print_flags(__entry->status, "|", uncorrectable_error_string))
+);
+
+#endif /* _TRACE_AER_H */
+
+/* This part must be outside protection */
+#include
--
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] uio.c: Fix warning: 'ret' might be used uninitialized
On Fri, Nov 30, 2012 at 12:12:46PM +0100, Tux9 wrote:
> I like Vitalii's solution more. Hans's solution assign the value
> -ENOMEM to ret in every round of the loop, which is a kind of wasting
> CPU cycles.
The difference between
1 files changed, 12 insertions(+), 4 deletions(-) and
1 files changed, 2 insertions(+), 0 deletions(-)
is more important. Note that this code is not in a fast path but only
called once at device creation.
Thanks,
Hans
>
> On Fri, Nov 30, 2012 at 12:58 AM, Hans J. Koch wrote:
> > On Thu, Nov 29, 2012 at 06:36:59PM +0200, Vitalii Demianets wrote:
> >> > On Thursday 29 November 2012 18:05:27 Tux9 wrote:
> >> > > Hans, I think there are something wrong in your patch, while Vitalii's
> >> > > is right. The variable "ret" is reused in line 292 and line 295, so
> >> > > the value of "ret" would be overridden (if it goto err_map in line 284
> >> > > when mi>=1).
> >> >
> >> > Actually, both patches do exactly the same thing. Hans's patch
> >> > establishes
> >> > default value for the ret for all those "other" cases when ret is not
> >> > explicitly overridden. My patch explicitly enumerates all those "other"
> >> > cases in more wordily manner.
> >> >
> >>
> >> Oops, disregard this. After looking at it more thoroughly I got your point.
> >> You are right, ret is overridden at first iteration (mi == 0), so Hans's
> >> approach does not work.
> >> I must do more thinking before replying in a hurry.
> >
> > You're right. Initialization of "ret" has to take place at the beginning of
> > the loop.
> >
> > I think this version is right:
> >
> >
> > From 00c3c734c0dde67873a628bcb18cee403c95c301 Mon Sep 17 00:00:00 2001
> > From: "Hans J. Koch"
> > Date: Fri, 30 Nov 2012 00:51:50 +0100
> > Subject: [PATCH] uio: Fix warning: 'ret' might be used uninitialized
> >
> > In two cases, the return value variable "ret" can be undefined.
> >
> > Signed-off-by: Hans J. Koch
> > ---
> > drivers/uio/uio.c |2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> > index 5110f36..0c80df2 100644
> > --- a/drivers/uio/uio.c
> > +++ b/drivers/uio/uio.c
> > @@ -273,6 +273,7 @@ static int uio_dev_add_attributes(struct uio_device
> > *idev)
> > struct uio_portio *portio;
> >
> > for (mi = 0; mi < MAX_UIO_MAPS; mi++) {
> > + ret = -ENOMEM;
> > mem = &idev->info->mem[mi];
> > if (mem->size == 0)
> > break;
> > @@ -298,6 +299,7 @@ static int uio_dev_add_attributes(struct uio_device
> > *idev)
> > }
> >
> > for (pi = 0; pi < MAX_UIO_PORT_REGIONS; pi++) {
> > + ret = -ENOMEM;
> > port = &idev->info->port[pi];
> > if (port->size == 0)
> > break;
> > --
> > 1.7.9
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] drivers: convert struct spinlock to spinlock_t
On 11/30/2012 09:25 PM, Luis R. Rodriguez wrote: > On Fri, Nov 30, 2012 at 11:18 AM, Luis R. Rodriguez > wrote: >> On Fri, Nov 30, 2012 at 12:38 AM, Arend van Spriel >> wrote: >>> So what is the rationale here. During mainlining our drivers we had to >>> remove all uses of 'typedef struct foo foo_t;'. The Linux CodingStyle >>> (chapter 5 Typedefs) is spending a number of lines explaining why. >>> >>> So is spinlock_t an exception to this rule simply because the kernel >>> uses spinlock_t all over the place. >> >> Yes. > > Let me provide a better explanation. In practice drivers should not be > creating their own typedefs given that generally the reasons to create > them do not exist for drivers. The kernel may provide their own though > for reasons explained in CodingStyle and in such cases the drivers > should use these supplied typedefs. Ok. Fine by me. It just looked like a case of saying a and doing b. Thanks for taking time giving the better explanation :-) Gr. AvS -- 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: [Pv-drivers] [PATCH 12/12] VMCI: Some header and config files.
On Fri, Nov 30, 2012 at 12:58:25PM -0800, Dmitry Torokhov wrote: > On Friday, November 30, 2012 12:44:06 PM Greg KH wrote: > > On Fri, Nov 30, 2012 at 12:09:40PM -0800, Dmitry Torokhov wrote: > > > On Friday, November 30, 2012 10:57:55 AM Greg KH wrote: > > > > On Fri, Nov 30, 2012 at 10:45:44AM -0800, Dmitry Torokhov wrote: > > > > > However you snipped the rest of my reply: do we really need to > > > > > renumber > > > > > ioctls? There is no benefit for the driver as its ioctl handler does > > > > > not parse the numbers into components. > > > > > > > > I don't know if you need to renumber, I really don't understand what you > > > > were trying to do with this code, and as it was acting differently from > > > > all other kernel ioctl declarations, I asked for some clarity. > > > > > > > > If you can rewrite it to look sane, and keep the same numbers, that's > > > > fine with me. > > > > > > OK, it looks like we can redo them as: > > > > > > #define IOCTL_VMCI_VERSION_IO(7, 0x9f)/* 1951 */ > > > #define IOCTL_VMCI_INIT_CONTEXT _IO(7, 0xa0)/* 1952 */ > > > > > > Is this acceptable? > > > > Sure, that's better. You also got lucky, '7' happens to be unused right > > now. > > Excellent. You said you want the next drop after -rc1, right? Yes please, I will be ignoring patches until then. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wireless regression in workqueue: use mod_delayed_work() instead of __cancel + queue
Hello, Anders. Sorry about the delay. On Wed, Nov 28, 2012 at 10:17:28AM -0500, Anders Kaseorg wrote: > On Wed, 28 Nov 2012, Anders Kaseorg wrote: > > My Intel 6250 wireless card (iwldvm) can no longer associate with a > > WPA-Enterprise network (PEAP-MSCHAPv2). To my surprise, I bisected this > > regression to commit e7c2f967445dd2041f0f8e3179cca22bb8bb7f79, > > workqueue: use mod_delayed_work() instead of __cancel + queue. I see. > > A bunch of logs collected by Ubuntu apport are in this bug report: > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1083980 > > > > How can I help to debug this? > > > > I see that someone else reported another regression with the same commit > > last week, although this looks unrelated at first glance: > > http://thread.gmane.org/gmane.linux.kernel/1395938 Urgh... that one was in my spam folder probably due to the mimed content. Nothing rings a bell yet. Will keep looking into it. Thanks. -- tejun -- 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: WARNING: at drivers/gpu/drm/i915/intel_display.c:1009 ironlake_crtc_disable+0xaf/0x8e0
On Fri, Nov 30, 2012 at 9:49 PM, Meelis Roos wrote: >> I tried 3.7-rc5 on an ironlale PC and got the warning in subject. The >> computer last ran 3.6.0 without any warnings. Second reboot showed the >> same warning plus a couple of EDID warnings (also below). > > Still there with 3.7.0-rc7-00113-gcc19528 and 100% reproducible: Hm, can you please boot with drm.debug=0xe added to your kernel cmdline and the attach the complete dmesg? -Daniel > > [0.646574] WARNING: at drivers/gpu/drm/i915/intel_display.c:1009 > ironlake_crtc_disable+0xaf/0x8e0() > [0.646575] Hardware name: HP Compaq 8100 Elite SFF PC > [0.646575] pipe_off wait timed out > [0.646576] Modules linked in: > [0.646578] Pid: 1, comm: swapper/0 Not tainted 3.7.0-rc7-00113-gcc19528 > #75 > [0.646578] Call Trace: > [0.646583] [] ? warn_slowpath_common+0x79/0xc0 > [0.646584] [] ? warn_slowpath_fmt+0x45/0x50 > [0.646585] [] ? intel_wait_for_pipe_off+0x5b/0x170 > [0.646586] [] ? ironlake_crtc_disable+0xaf/0x8e0 > [0.646588] [] ? intel_dp_mode_fixup+0x249/0x270 > [0.646590] [] ? intel_set_mode+0x306/0x920 > [0.646592] [] ? intel_crtc_set_config+0x6f1/0x950 > [0.646595] [] ? drm_fb_helper_set_par+0x6f/0xe0 > [0.646598] [] ? fbcon_init+0x55f/0x5f0 > [0.646600] [] ? visual_init+0xac/0x110 > [0.646601] [] ? bind_con_driver+0x16c/0x340 > [0.646602] [] ? take_over_console+0x60/0x70 > [0.646604] [] ? fbcon_takeover+0x5b/0xc0 > [0.646607] [] ? notifier_call_chain+0x45/0x60 > [0.646608] [] ? > __blocking_notifier_call_chain+0x55/0x80 > [0.646609] [] ? register_framebuffer+0x1af/0x2e0 > [0.646611] [] ? > drm_fb_helper_single_fb_probe+0x1f4/0x320 > [0.646612] [] ? > drm_fb_helper_initial_config+0x1a9/0x220 > [0.646615] [] ? __kmalloc+0xed/0x130 > [0.646618] [] ? intel_fbdev_init+0x7d/0xb0 > [0.646619] [] ? i915_driver_load+0xd95/0xf00 > [0.646622] [] ? drm_get_pci_dev+0x185/0x2c0 > [0.646624] [] ? pci_device_probe+0xd1/0x170 > [0.646625] [] ? driver_probe_device+0x68/0x220 > [0.646626] [] ? __driver_attach+0x93/0xa0 > [0.646627] [] ? driver_probe_device+0x220/0x220 > [0.646629] [] ? bus_for_each_dev+0x4d/0x80 > [0.646630] [] ? bus_add_driver+0x178/0x260 > [0.646631] [] ? driver_register+0x84/0x180 > [0.646634] [] ? drm_core_init+0x12f/0x12f > [0.646636] [] ? do_one_initcall+0x122/0x170 > [0.646638] [] ? kernel_init+0x11c/0x2a0 > [0.646641] [] ? do_early_param+0x83/0x83 > [0.646643] [] ? schedule_tail+0x21/0xb0 > [0.646644] [] ? rest_init+0x70/0x70 > [0.646645] [] ? ret_from_fork+0x7c/0xb0 > [0.646646] [] ? rest_init+0x70/0x70 > [0.646650] ---[ end trace ed6fe7a7042b42d8 ]--- > [0.702400] [drm:intel_disable_transcoder] *ERROR* failed to disable > transcoder 0 > > > > -- > Meelis Roos (mr...@ut.ee) http://www.cs.ut.ee/~mroos/ -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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: WARNING: at drivers/gpu/drm/i915/intel_display.c:1009 ironlake_crtc_disable+0xaf/0x8e0
> I tried 3.7-rc5 on an ironlale PC and got the warning in subject. The > computer last ran 3.6.0 without any warnings. Second reboot showed the > same warning plus a couple of EDID warnings (also below). Still there with 3.7.0-rc7-00113-gcc19528 and 100% reproducible: [0.646574] WARNING: at drivers/gpu/drm/i915/intel_display.c:1009 ironlake_crtc_disable+0xaf/0x8e0() [0.646575] Hardware name: HP Compaq 8100 Elite SFF PC [0.646575] pipe_off wait timed out [0.646576] Modules linked in: [0.646578] Pid: 1, comm: swapper/0 Not tainted 3.7.0-rc7-00113-gcc19528 #75 [0.646578] Call Trace: [0.646583] [] ? warn_slowpath_common+0x79/0xc0 [0.646584] [] ? warn_slowpath_fmt+0x45/0x50 [0.646585] [] ? intel_wait_for_pipe_off+0x5b/0x170 [0.646586] [] ? ironlake_crtc_disable+0xaf/0x8e0 [0.646588] [] ? intel_dp_mode_fixup+0x249/0x270 [0.646590] [] ? intel_set_mode+0x306/0x920 [0.646592] [] ? intel_crtc_set_config+0x6f1/0x950 [0.646595] [] ? drm_fb_helper_set_par+0x6f/0xe0 [0.646598] [] ? fbcon_init+0x55f/0x5f0 [0.646600] [] ? visual_init+0xac/0x110 [0.646601] [] ? bind_con_driver+0x16c/0x340 [0.646602] [] ? take_over_console+0x60/0x70 [0.646604] [] ? fbcon_takeover+0x5b/0xc0 [0.646607] [] ? notifier_call_chain+0x45/0x60 [0.646608] [] ? __blocking_notifier_call_chain+0x55/0x80 [0.646609] [] ? register_framebuffer+0x1af/0x2e0 [0.646611] [] ? drm_fb_helper_single_fb_probe+0x1f4/0x320 [0.646612] [] ? drm_fb_helper_initial_config+0x1a9/0x220 [0.646615] [] ? __kmalloc+0xed/0x130 [0.646618] [] ? intel_fbdev_init+0x7d/0xb0 [0.646619] [] ? i915_driver_load+0xd95/0xf00 [0.646622] [] ? drm_get_pci_dev+0x185/0x2c0 [0.646624] [] ? pci_device_probe+0xd1/0x170 [0.646625] [] ? driver_probe_device+0x68/0x220 [0.646626] [] ? __driver_attach+0x93/0xa0 [0.646627] [] ? driver_probe_device+0x220/0x220 [0.646629] [] ? bus_for_each_dev+0x4d/0x80 [0.646630] [] ? bus_add_driver+0x178/0x260 [0.646631] [] ? driver_register+0x84/0x180 [0.646634] [] ? drm_core_init+0x12f/0x12f [0.646636] [] ? do_one_initcall+0x122/0x170 [0.646638] [] ? kernel_init+0x11c/0x2a0 [0.646641] [] ? do_early_param+0x83/0x83 [0.646643] [] ? schedule_tail+0x21/0xb0 [0.646644] [] ? rest_init+0x70/0x70 [0.646645] [] ? ret_from_fork+0x7c/0xb0 [0.646646] [] ? rest_init+0x70/0x70 [0.646650] ---[ end trace ed6fe7a7042b42d8 ]--- [0.702400] [drm:intel_disable_transcoder] *ERROR* failed to disable transcoder 0 -- Meelis Roos (mr...@ut.ee) http://www.cs.ut.ee/~mroos/ -- 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/3] aerdrv: Enhanced AER logging
On Fri, 2012-11-30 at 13:39 -0700, Lance Ortiz wrote:
> This patch will provide a more reliable and easy way for user-space
> applications to have access to AER logs rather than reading them from the
> message buffer. It also provides a way to notify user-space when an AER
> event occurs.
Please run your patches through checkpatch.
[]
> diff --git a/drivers/acpi/apei/cper.c b/drivers/acpi/apei/cper.c
[]
> @@ -249,6 +250,10 @@ static const char *cper_pcie_port_type_strs[] = {
> static void cper_print_pcie(const char *pfx, const struct cper_sec_pcie
> *pcie,
> const struct acpi_hest_generic_data *gdata)
> {
> +#ifdef CONFIG_ACPI_APEI_PCIEAER
> + struct pci_dev *dev;
> +#endif
> +
> if (pcie->validation_bits & CPER_PCIE_VALID_PORT_TYPE)
> printk("%s""port_type: %d, %s\n", pfx, pcie->port_type,
> pcie->port_type < ARRAY_SIZE(cper_pcie_port_type_strs) ?
> @@ -281,9 +286,17 @@ static void cper_print_pcie(const char *pfx, const
> struct cper_sec_pcie *pcie,
> "%s""bridge: secondary_status: 0x%04x, control: 0x%04x\n",
> pfx, pcie->bridge.secondary_status, pcie->bridge.control);
> #ifdef CONFIG_ACPI_APEI_PCIEAER
> - if (pcie->validation_bits & CPER_PCIE_VALID_AER_INFO) {
> + dev = pci_get_domain_bus_and_slot(pcie->device_id.segment,
> + pcie->device_id.bus, pcie->device_id.function);
> + if (!dev)
> + printk("PCI AER Cannot get PCI device %04x:%02x:%02x.%d\n",
> + pcie->device_id.segment, pcie->device_id.bus,
> + pcie->device_id.slot, pcie->device_id.function);
Please prefix this with an appropriate KERN_
--
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: [Pv-drivers] [PATCH 12/12] VMCI: Some header and config files.
On Friday, November 30, 2012 12:44:06 PM Greg KH wrote: > On Fri, Nov 30, 2012 at 12:09:40PM -0800, Dmitry Torokhov wrote: > > On Friday, November 30, 2012 10:57:55 AM Greg KH wrote: > > > On Fri, Nov 30, 2012 at 10:45:44AM -0800, Dmitry Torokhov wrote: > > > > However you snipped the rest of my reply: do we really need to > > > > renumber > > > > ioctls? There is no benefit for the driver as its ioctl handler does > > > > not parse the numbers into components. > > > > > > I don't know if you need to renumber, I really don't understand what you > > > were trying to do with this code, and as it was acting differently from > > > all other kernel ioctl declarations, I asked for some clarity. > > > > > > If you can rewrite it to look sane, and keep the same numbers, that's > > > fine with me. > > > > OK, it looks like we can redo them as: > > > > #define IOCTL_VMCI_VERSION _IO(7, 0x9f)/* 1951 */ > > #define IOCTL_VMCI_INIT_CONTEXT _IO(7, 0xa0)/* 1952 */ > > > > Is this acceptable? > > Sure, that's better. You also got lucky, '7' happens to be unused right > now. Excellent. You said you want the next drop after -rc1, right? -- Dmitry -- 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: 32/64-bit NUMA consolidation behavior regresion
On 11/30/2012 12:42 PM, Tejun Heo wrote: > On Wed, Nov 28, 2012 at 04:03:58PM -0800, Dave Hansen wrote: >> My system is just qemu booted with: >> >> -smp 8 -m 8192 -numa node,nodeid=0,cpus=0-3 -numa node,nodeid=1,cpus=4-7 >> >> Watch the "PERCPU:" line early in boot, and you can see the "Embedded" >> come and go with or without your patch: >> >> [0.00] PERCPU: Embedded 11 pages/cpu @f300 s30592 r0 d14464 >> vs >> [0.00] PERCPU: 11 4K pages/cpu @f83fe000 s30592 r0 d14464 > ... >> I don't have a fix handy because I'm working on the original problem, >> but I just happened to run across this during a bisect. > > Just tested 3.7-rc7 w/ qemu and it works as expected here. > > Can you please boot with the following debug patch and report the boot > message before and after? Hi Tejun, I just tested with 3.7-rc7 and I'm seeing the expected behavior now. Looks like it got fixed along the way somewhere. I was bisecting way back in the 2.6.3x's. Sorry of the noise. -- 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 0/1] ubi: Add ubiblock driver
Hi Artem, Thanks for the taking the time to answer. On Fri, Nov 30, 2012 at 8:08 AM, Artem Bityutskiy wrote: > >> I don't know how many ubi volumes a user typically creates, but I >> expect not to be too many. > > I think I saw something like 8-10 in some peoples' reports. > Mmm, that's more than I've expected. [...] > >> This cache is 1-LEB bytes, vmalloced at open() and freed at release(). > > Is it per-block device? Yes. But notice the vmalloced cache is freed on release(). So, an unused ubiblock won't allocate it. >Then I am not sure it is a good idea to > automatically create them for every volume... > Given that ubiblock is workqueue based I believe there isn't any performance penalty in creating many instances. Regarding memory footprint: we should consider how much does it cost to create an ubiblock device, plus the underlying gendisk, request queue, etc. If people is partitioning its ubi devices in 8-10 volumes, then I'm not too sure if we want to create a block device per-volume automatically. Not because of the cache -again, if an ubiblock is unused it won't allocate any- but because of overall unnecessary bloatness. The main idea behind auto-creation is that, IMHO, ubi ecosystem already has its own rather large set of userspace tools, I'm against adding yet another one. I'm gonna keep playing with this and come up with the long promise numbers. Ezequiel -- 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] init.h: Remove __dev* sections from the kernel
On Fri, Nov 30, 2012 at 12:39:43PM -0800, H. Peter Anvin wrote: > On 11/29/2012 10:43 AM, Greg Kroah-Hartman wrote: > > > >-/* Used for HOTPLUG */ > >-#define __devinit__section(.devinit.text) __cold notrace > >-#define __devinitdata__section(.devinit.data) > >-#define __devinitconst __constsection(.devinit.rodata) > >-#define __devexit__section(.devexit.text) __exitused __cold notrace > >-#define __devexitdata__section(.devexit.data) > >-#define __devexitconst __constsection(.devexit.rodata) > >+/* Used for HOTPLUG, but that is always enabled now, so just make them > >noops */ > >+#define __devinit > >+#define __devinitdata > >+#define __devinitconst > >+#define __devexit > >+#define __devexitdata > >+#define __devexitconst > > > > Second question... what about the __exitused __cold notrace annotations? __exitused shouldn't matter, we shouldn't be optimizing these away at all anymore. I don't know about __cold and notrace, but given that these could be traced, I don't see why that marking got there in the first place. In reading compiler-gcc4.h, and knowing just how infrequent these functions are ever called, I would be amazed if the __cold marking ever even helped anything out here. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] drivers: cma: fix addressing on PAE machines
>> On Fri, Nov 30 2012, Vitaly Andrianov wrote:
>> > This patch fixes a couple of bugs that otherwise impair CMA
>> > functionality on PAE machines:
>> >
>> > - alignment must be a 64-bit type when running on systems with 64-
>> bit
>> > physical addresses. If this is not the case, the limit
>> calculation thunks
>> > allocations down to an address range < 4G.
>> >
>> > - The allocated range check is removed. On 32bit ARM kernel with
>> LPAE
>> > enabled the base may be allocated outside the fist 4GB of
>> physical
>> > memory (keystone SoC for example).
>> >
>> > Signed-off-by: Vitaly Andrianov
>> > Signed-off-by: Cyril Chemparathy
>>
>> To be consistent, you should also change the type in:
>>
>> static long size_cmdline = -1;
>> static const unsigned long size_bytes = CMA_SIZE_MBYTES * SZ_1M; static
>> unsigned long __init __maybe_unused cma_early_percent_memory(void)
>>
>> and in
>>
>> void __init dma_contiguous_reserve(phys_addr_t limit)
On Fri, Nov 30 2012, Andrianov, Vitaly wrote:
> Can you elaborate why we need to change type for size?
Like I've wrote, for consistency. The size should use the same type as
alignment. This most likely won't affect the way you use the code, but
it's the right thing to do. It should be done that way from the start,
so it's really my mistake, but since you are touching the code, it'd
best to have the changes contained in a single commit. Alternatively
I can just send my own patch with all those fixes (including yours).
>> > diff --git a/drivers/base/dma-contiguous.c
>> > b/drivers/base/dma-contiguous.c index 9a14694..7936b2e 100644
>> > --- a/drivers/base/dma-contiguous.c
>> > +++ b/drivers/base/dma-contiguous.c
>> > @@ -234,7 +234,7 @@ int __init dma_declare_contiguous(struct device
>> *dev, unsigned long size,
>> > phys_addr_t base, phys_addr_t limit) {
>> >struct cma_reserved *r = &cma_reserved[cma_reserved_count];
>> > - unsigned long alignment;
>> > + phys_addr_t alignment;
>> >
>> >pr_debug("%s(size %lx, base %08lx, limit %08lx)\n", __func__,
>> > (unsigned long)size, (unsigned long)base, @@ -271,10 +271,6
>> @@ int
>> > __init dma_declare_contiguous(struct device *dev, unsigned long size,
>> >if (!addr) {
>> >base = -ENOMEM;
>> >goto err;
>> > - } else if (addr + size > ~(unsigned long)0) {
>> > - memblock_free(addr, size);
>> > - base = -EINVAL;
>> > - goto err;
>> >} else {
>> >base = addr;
>> >}
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
pgpBLpWvQLnZ0.pgp
Description: PGP signature
Re: [PATCH 1/2] init.h: Remove __dev* sections from the kernel
On Fri, Nov 30, 2012 at 12:39:01PM -0800, H. Peter Anvin wrote: > On 11/29/2012 10:43 AM, Greg Kroah-Hartman wrote: > >From: Greg Kroah-Hartman > > > >With the recent work to remove CONFIG_HOTPLUG, we are starting to get a > >bunch of __devinit section warnings, despite CONFIG_HOTPLUG always being > >enabled. So, stop marking the sections entirely, by defining them away > >the section markings in init.h > > > > Could we run a sed script over the kernel tree and generate patches > to remove the markings completely? Yes, we can, and Bill's been generating patches that way. A number of them are already in linux-next and I'll sweep the tree after 3.8-rc1 is out and catch the rest. thanks, 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/
[PATCH v2 3/3] aerdrv: Cleanup log output for CPER based AER
These changes make cper_print_aer more consistent with aer_print_error
which is called in the AER interrupt case. The string in the variable
'prefix' is printed at the beginning of each print statement in
cper_print_aer(). The prefix is a string containing the driver name
and the device's path. Looking up the call path, the value of prefix
is never assigned and is NULL, so when cper_print_aer prints data the
initial string does not get printed. This string is important because
it identifies the device that the error is on. This patch adds code to
create the prefix and print it in the cper_print_aer function. This
patch also calculates the device's agent id so it can be printed.
Signed-off-by: Lance Ortiz
---
drivers/pci/pcie/aer/aerdrv_errprint.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/pcie/aer/aerdrv_errprint.c
b/drivers/pci/pcie/aer/aerdrv_errprint.c
index 34d96e4..5050891 100644
--- a/drivers/pci/pcie/aer/aerdrv_errprint.c
+++ b/drivers/pci/pcie/aer/aerdrv_errprint.c
@@ -228,9 +228,15 @@ void cper_print_aer(struct pci_dev *dev, int cper_severity,
int aer_severity, layer, agent, status_strs_size, tlp_header_valid = 0;
u32 status, mask;
const char **status_strs;
- char *prefix = NULL;
+ int id = ((dev->bus->number << 8) | dev->devfn);
+ char prefix[44];
aer_severity = cper_severity_to_aer(cper_severity);
+ snprintf(prefix, sizeof(prefix), "%s%s %s: ",
+ (aer_severity == AER_CORRECTABLE) ?
+ KERN_WARNING : KERN_ERR,
+ dev_driver_string(&dev->dev), dev_name(&dev->dev));
+
if (aer_severity == AER_CORRECTABLE) {
status = aer->cor_status;
mask = aer->cor_mask;
@@ -248,8 +254,8 @@ void cper_print_aer(struct pci_dev *dev, int cper_severity,
printk("%s""aer_status: 0x%08x, aer_mask: 0x%08x\n",
prefix, status, mask);
cper_print_bits(prefix, status, status_strs, status_strs_size);
- printk("%s""aer_layer=%s, aer_agent=%s\n", prefix,
- aer_error_layer[layer], aer_agent_string[agent]);
+ printk("%s""aer_layer=%s, id=%04x(%s)\n", prefix,
+ aer_error_layer[layer], id, aer_agent_string[agent]);
if (aer_severity != AER_CORRECTABLE)
printk("%s""aer_uncor_severity: 0x%08x\n",
prefix, aer->uncor_severity);
--
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 v3 2/3] aerdrv: Enhanced AER logging
This patch will provide a more reliable and easy way for user-space
applications to have access to AER logs rather than reading them from the
message buffer. It also provides a way to notify user-space when an AER
event occurs.
The aer driver is updated to generate a trace event of function 'aer_event'
when an AER occurs. The trace event was added to both the interrupt
based aer path and the firmware first path
Signed-off-by: Lance Ortiz
---
drivers/acpi/apei/cper.c | 17 +++--
drivers/pci/pcie/aer/aerdrv_errprint.c | 10 +-
include/linux/aer.h|2 +-
3 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/apei/cper.c b/drivers/acpi/apei/cper.c
index e6defd8..87345d4 100644
--- a/drivers/acpi/apei/cper.c
+++ b/drivers/acpi/apei/cper.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
/*
@@ -249,6 +250,10 @@ static const char *cper_pcie_port_type_strs[] = {
static void cper_print_pcie(const char *pfx, const struct cper_sec_pcie *pcie,
const struct acpi_hest_generic_data *gdata)
{
+#ifdef CONFIG_ACPI_APEI_PCIEAER
+ struct pci_dev *dev;
+#endif
+
if (pcie->validation_bits & CPER_PCIE_VALID_PORT_TYPE)
printk("%s""port_type: %d, %s\n", pfx, pcie->port_type,
pcie->port_type < ARRAY_SIZE(cper_pcie_port_type_strs) ?
@@ -281,9 +286,17 @@ static void cper_print_pcie(const char *pfx, const struct
cper_sec_pcie *pcie,
"%s""bridge: secondary_status: 0x%04x, control: 0x%04x\n",
pfx, pcie->bridge.secondary_status, pcie->bridge.control);
#ifdef CONFIG_ACPI_APEI_PCIEAER
- if (pcie->validation_bits & CPER_PCIE_VALID_AER_INFO) {
+ dev = pci_get_domain_bus_and_slot(pcie->device_id.segment,
+ pcie->device_id.bus, pcie->device_id.function);
+ if (!dev)
+ printk("PCI AER Cannot get PCI device %04x:%02x:%02x.%d\n",
+ pcie->device_id.segment, pcie->device_id.bus,
+ pcie->device_id.slot, pcie->device_id.function);
+
+ if (pcie->validation_bits & CPER_PCIE_VALID_AER_INFO && dev) {
struct aer_capability_regs *aer_regs = (void *)pcie->aer_info;
- cper_print_aer(pfx, gdata->error_severity, aer_regs);
+ cper_print_aer(dev, gdata->error_severity, aer_regs);
+ pci_dev_put(dev);
}
#endif
}
diff --git a/drivers/pci/pcie/aer/aerdrv_errprint.c
b/drivers/pci/pcie/aer/aerdrv_errprint.c
index 3ea5173..34d96e4 100644
--- a/drivers/pci/pcie/aer/aerdrv_errprint.c
+++ b/drivers/pci/pcie/aer/aerdrv_errprint.c
@@ -23,6 +23,9 @@
#include "aerdrv.h"
+#define CREATE_TRACE_POINTS
+#include
+
#define AER_AGENT_RECEIVER 0
#define AER_AGENT_REQUESTER1
#define AER_AGENT_COMPLETER2
@@ -194,6 +197,8 @@ void aer_print_error(struct pci_dev *dev, struct
aer_err_info *info)
if (info->id && info->error_dev_num > 1 && info->id == id)
printk("%s"" Error of this Agent(%04x) is reported first\n",
prefix, id);
+ trace_aer_event(dev_name(&dev->dev), (info->status & ~info->mask),
+ info->severity);
}
void aer_print_port_info(struct pci_dev *dev, struct aer_err_info *info)
@@ -217,12 +222,13 @@ int cper_severity_to_aer(int cper_severity)
}
EXPORT_SYMBOL_GPL(cper_severity_to_aer);
-void cper_print_aer(const char *prefix, int cper_severity,
+void cper_print_aer(struct pci_dev *dev, int cper_severity,
struct aer_capability_regs *aer)
{
int aer_severity, layer, agent, status_strs_size, tlp_header_valid = 0;
u32 status, mask;
const char **status_strs;
+ char *prefix = NULL;
aer_severity = cper_severity_to_aer(cper_severity);
if (aer_severity == AER_CORRECTABLE) {
@@ -259,5 +265,7 @@ void cper_print_aer(const char *prefix, int cper_severity,
*(tlp + 8), *(tlp + 15), *(tlp + 14),
*(tlp + 13), *(tlp + 12));
}
+ trace_aer_event(dev_name(&dev->dev), (status & ~mask),
+ aer_severity);
}
#endif
diff --git a/include/linux/aer.h b/include/linux/aer.h
index 544abdb..7b86dc6 100644
--- a/include/linux/aer.h
+++ b/include/linux/aer.h
@@ -49,7 +49,7 @@ static inline int
pci_cleanup_aer_uncorrect_error_status(struct pci_dev *dev)
}
#endif
-extern void cper_print_aer(const char *prefix, int cper_severity,
+extern void cper_print_aer(struct pci_dev *dev, int cper_severity,
struct aer_capability_regs *aer);
extern int cper_severity_to_aer(int cper_severity);
extern void aer_recover_queue(int domain, unsigned int bus, unsigned int devfn,
--
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.k
[PATCH v2 1/3] aerdrv: Trace Event for AER
This header file will define a new trace event that will be triggered when
a AER event occurs. The following data will be provided to the trace
event.
char * name - String containing the device path
u32 status -Either the correctable or uncorrectable register
indicating what error or errors have been see.
u8 severity - error severity 0:NONFATAL 1:FATAL 2:CORRECTED
The trace event will also provide a trace string that may look like:
":05:00.0 PCIe Bus Error:severity=Uncorrected (Non-Fatal), Poisoned
TLP"
Signed-off-by: Lance Ortiz
---
include/trace/events/ras.h | 77
1 files changed, 77 insertions(+), 0 deletions(-)
create mode 100644 include/trace/events/ras.h
diff --git a/include/trace/events/ras.h b/include/trace/events/ras.h
new file mode 100644
index 000..f77d009
--- /dev/null
+++ b/include/trace/events/ras.h
@@ -0,0 +1,77 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM aer_event
+#define TRACE_INCLUDE_FILE ras
+
+#if !defined(_TRACE_AER_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_AER_H
+
+#include
+#include
+
+
+/*
+ * Anhance Error Reporting (AER) PCIE Report Error
+ *
+ * These events are generated when hardware detects a corrected or
+ * uncorrected event on a pci express device and reports
+ * errors. The event reports the following data.
+ *
+ * char * dev_name - String containing the device identification
+ * u32 status -Either the correctable or uncorrectable register
+ * indicating what error or errors have been seen
+ * u8 severity - error severity 0:NONFATAL 1:FATAL 2:CORRECTED
+ */
+
+#define correctable_error_string \
+ {BIT(0),"Receiver Error"}, \
+ {BIT(6),"Bad TLP"}, \
+ {BIT(7),"Bad DLLP"},\
+ {BIT(8),"RELAY_NUM Rollover"}, \
+ {BIT(12), "Replay Timer Timeout"},\
+ {BIT(13), "Advisory Non-Fatal"}
+
+#define uncorrectable_error_string \
+ {BIT(4),"Data Link Protocol"}, \
+ {BIT(12), "Poisoned TLP"},\
+ {BIT(13), "Flow Control Protocol"}, \
+ {BIT(14), "Completion Timeout"}, \
+ {BIT(15), "Completer Abort"}, \
+ {BIT(16), "Unexpected Completion"}, \
+ {BIT(17), "Receiver Overflow"}, \
+ {BIT(18), "Malformed TLP"}, \
+ {BIT(19), "ECRC"},\
+ {BIT(20), "Unsupported Request"}
+
+TRACE_EVENT(aer_event,
+ TP_PROTO(const char *dev_name,
+const u32 status,
+const u8 severity),
+
+ TP_ARGS(dev_name, status, severity),
+
+ TP_STRUCT__entry(
+ __string( dev_name, dev_name)
+ __field(u32,status )
+ __field(u8, severity)
+ ),
+
+ TP_fast_assign(
+ __assign_str(dev_name, dev_name);
+ __entry->status = status;
+ __entry->severity = severity;
+ ),
+
+ TP_printk("%s PCIe Bus Error: severity=%s, %s\n",
+ __get_str(dev_name),
+ (__entry->severity == HW_EVENT_ERR_CORRECTED) ? "Corrected" :
+ ((__entry->severity == HW_EVENT_ERR_FATAL) ?
+ "Fatal" : "Uncorrected"),
+ __entry->severity == HW_EVENT_ERR_CORRECTED ?
+ __print_flags(__entry->status, "|", correctable_error_string) :
+ __print_flags(__entry->status, "|", uncorrectable_error_string))
+);
+
+#endif /* _TRACE_AER_H */
+
+/* This part must be outside protection */
+#include
--
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: [Pv-drivers] [PATCH 12/12] VMCI: Some header and config files.
On Fri, Nov 30, 2012 at 12:09:40PM -0800, Dmitry Torokhov wrote: > On Friday, November 30, 2012 10:57:55 AM Greg KH wrote: > > On Fri, Nov 30, 2012 at 10:45:44AM -0800, Dmitry Torokhov wrote: > > > However you snipped the rest of my reply: do we really need to renumber > > > ioctls? There is no benefit for the driver as its ioctl handler does > > > not parse the numbers into components. > > > > I don't know if you need to renumber, I really don't understand what you > > were trying to do with this code, and as it was acting differently from > > all other kernel ioctl declarations, I asked for some clarity. > > > > If you can rewrite it to look sane, and keep the same numbers, that's > > fine with me. > > OK, it looks like we can redo them as: > > #define IOCTL_VMCI_VERSION_IO(7, 0x9f)/* 1951 */ > #define IOCTL_VMCI_INIT_CONTEXT _IO(7, 0xa0)/* 1952 */ > > Is this acceptable? Sure, that's better. You also got lucky, '7' happens to be unused right now. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH for 3.2.34] memcg: do not trigger OOM from add_to_page_cache_locked
>The only strange thing I noticed is that some groups have 0 limit. Is >this intentional? >grep memory.limit_in_bytes cgroups | grep -v uid | sed 's@.*/@@' | sort | uniq >-c > 3 memory.limit_in_bytes:0 These are users who are not allowed to run anything. azur -- 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] init.h: Remove __dev* sections from the kernel
H. Peter Anvin writes: > > On 11/29/2012 10:43 AM, Greg Kroah-Hartman wrote: > > From: Greg Kroah-Hartman > > > > With the recent work to remove CONFIG_HOTPLUG, we are starting to get a > > bunch of __devinit section warnings, despite CONFIG_HOTPLUG always being > > enabled. So, stop marking the sections entirely, by defining them away > > the section markings in init.h > > > > Could we run a sed script over the kernel tree and generate patches to > remove the markings completely? > That's how I've been generating the patches to remove the markings -- except it's a perl script. -- Bill -- 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: Re: Re: Re: Re: Re: Re: [RFC PATCH 0/2] kvm/vmx: Output TSC offset
On Fri, Nov 30, 2012 at 10:36:43AM +0900, Yoshihiro YUNOMAE wrote: > Hi Marcelo, > > >>>Can you please write a succint but complete description of the method > >>>so it can be verified? > >> > >>Sure. > >> > >>- Prerequisite > >>1. the host TSC is synchronized and stable. > >>2. kvm_write_tsc_offset events include previous and next TSC offset > >>values. > >>3. Every event's trace_clock is TSC. > >> > >>- Assumption for the sake of ease > >>1. One VCPU > >>2. The guest executes no write_tsc or write_tsc only once. > >> > >>- Configuration > >>1. On the host, kvm_exit/entry events are recorded in the buffer A and > >>kvm_write_tsc_offset events are recorded in the buffer B. > >>2. Boot a guest > >> > >>- Sort method > >>1. > >> Confirm which the kvm_write_tsc_offset events are recorded except for > >>boot. Note that a vcpu thread writes TSC offset when boot as an initial > >>operation. > >> > >>1-1. > >> If not recorded, it means that the guest did not execute write_tsc. > >>So, we convert the guest TSC to the host TSC using TSC offset of boot. > >>=> END > >> > >>1-2. > >> If recorded, it means that the guest executed write_tsc. > >>So, we use new kvm_write_tsc_offset event information. > >> > >>2. > >>We convert the host TSC(Th) of the kvm_write_tsc_offset event to > >>the guest TSC(Tg) using previous_tsc_offset value: > >> Tg = Th + previous_tsc_offset > >> > >>3. > >>To search the point where the guest executed write_tsc, we find "n" > >>which satisfies the condition Tn < Tg < Tn+1 or Tn+1 < Tn < Tg from > >>older events of the guest. > >>The former condition means trace data of > >>the guest were recorded monotonically. On the other hand, the latter > >>condition means trace data of the guest moved backward. > >>4. > >>We convert the guest TSC of trace data to the host TSC using > >>previous_tsc_offset value before "n" and using next_tsc_offset value > >>after "n+1". > >>=> END > >> > >>- Note > >>We assumed one vcpu and no write_tsc or write_tsc only once for the > >>sake of ease. For other conditions, we will use similar method. > >> > >>Thanks, > > > >There is no certainty. Consider the following information available > > > >guest trace host trace > > 100: guest_tsc_write (tsc_offset=-100 => > > guest_tsc = 0) > > 104: guest_tsc_write (tsc_offset=-104 => > > guest_tsc = 0) > > 108: guest_tsc_write (tsc_offset=-108 => > > guest_tsc = 0) > >1: eventA > >2: eventB > >3: eventC > >1: eventD > >2: eventE > >3: eventF > > > >How can you tell which tsc_offset to use for eventD ? It could be either > >-104 or -108. The notion of "next_tsc_offset" is subject to such > >issue. > > > >I suppose its fine to restrict the interface as follows: the tool will > >accept one trace of events with monotonic timestamps and the user is > >responsible for correlating that to a host trace. > > OK, I'll add the restriction, which trace data must have monotonic > timestamps to use this feature. I think guests seldom will execute > write_tsc, so in many cases, timestamps will be monotonically recorded > in trace data. > > >That is, you can't feed distinct instances of guest kernel trace. > > I'm not clear for "distinct instances". Is this about SMP or multiple > guests? Would you explain about this? Distinct boot instances. If the guest reboots TSC can be written to. -- 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: 32/64-bit NUMA consolidation behavior regresion
Hello, Dave.
On Wed, Nov 28, 2012 at 04:03:58PM -0800, Dave Hansen wrote:
> My system is just qemu booted with:
>
> -smp 8 -m 8192 -numa node,nodeid=0,cpus=0-3 -numa node,nodeid=1,cpus=4-7
>
> Watch the "PERCPU:" line early in boot, and you can see the "Embedded"
> come and go with or without your patch:
>
> [0.00] PERCPU: Embedded 11 pages/cpu @f300 s30592 r0 d14464
> vs
> [0.00] PERCPU: 11 4K pages/cpu @f83fe000 s30592 r0 d14464
...
> I don't have a fix handy because I'm working on the original problem,
> but I just happened to run across this during a bisect.
Just tested 3.7-rc7 w/ qemu and it works as expected here.
Can you please boot with the following debug patch and report the boot
message before and after?
Thanks.
diff --git a/arch/x86/kernel/setup_percpu.c b/arch/x86/kernel/setup_percpu.c
index 5cdff03..1133dc8 100644
--- a/arch/x86/kernel/setup_percpu.c
+++ b/arch/x86/kernel/setup_percpu.c
@@ -71,9 +71,13 @@ static bool __init pcpu_need_numa(void)
for_each_possible_cpu(cpu) {
int node = early_cpu_to_node(cpu);
+ printk("XXX pcpu_need_numa: cpu%d@%d online=%d ND=%p\n",
+ cpu, node, node_online(node), NODE_DATA(node));
if (node_online(node) && NODE_DATA(node) &&
- last && last != NODE_DATA(node))
+ last && last != NODE_DATA(node)) {
+ printk("XXX need numa\n");
return true;
+ }
last = NODE_DATA(node);
}
--
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/
