On Fri, 01 Nov 2013 11:25:37 +
Masami Hiramatsu wrote:
> Prohibit probing on func_ptr_is_kernel_text().
> Since the func_ptr_is_kernel_text() is called from
> notifier_call_chain() which is called from int3 handler,
> probing it may cause double int3 fault and kernel will
> reboot.
>
> This
On Mon, 4 Nov 2013 16:51:31 +0100, Oleg Nesterov wrote:
> On 11/04, Namhyung Kim wrote:
>> On Mon, 04 Nov 2013 17:46:41 +0900, Namhyung Kim wrote:
>> > On Sat, 2 Nov 2013 16:54:58 +0100, Oleg Nesterov wrote:
>> >> - this only allows to read the data from the same binary.
>> >
>> > Right. This is
On Mon, 4 Nov 2013 16:01:12 +0100, Oleg Nesterov wrote:
> On 11/04, Namhyung Kim wrote:
>>
>> On Sat, 2 Nov 2013 16:54:58 +0100, Oleg Nesterov wrote:
>> >
>> > This does not look right to me.
>> >
>> > - get_user_vaddr() is costly, it does vma_interval_tree_foreach() under
>> > ->i_mmap_mutex.
(2013/11/01 22:55), Steven Rostedt wrote:
> On Fri, 01 Nov 2013 11:25:32 +
> Masami Hiramatsu wrote:
>
>> Instead of __kprobes annotation, introduce 'nokprobe' new annotation
>> to annotate that the function is not probed by kprobes.
>>
>> Previously the '__kprobes' is used just for avoiding
On Mon, 2013-11-04 at 11:59 +0800, Yuanhan Liu wrote:
> On Fri, Nov 01, 2013 at 08:15:13PM -0700, Davidlohr Bueso wrote:
> > On Fri, 2013-11-01 at 18:16 +0800, Yuanhan Liu wrote:
> > > On Fri, Nov 01, 2013 at 09:21:46AM +0100, Ingo Molnar wrote:
> > > >
> > > > * Yuanhan Liu wrote:
> > > >
> >
Avoid making the rb_node the first entry to catch some bugs around NULL
checking the rb_node.
Signed-off-by: Cody P Schafer
---
lib/rbtree_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/rbtree_test.c b/lib/rbtree_test.c
index 31dd4cc..df6c125 100644
---
Provide a new helper called rb_next_postorder_entry() to perform NULL
checks and container_of() coversions and use it in
rbtree_for_each_entry_safe() to fix oopses that occur when rb_node is
not the first element in the entry.
Additionally, remove the missplaced NULL check from
On 11/04/2013 04:45 PM, Jan Kara wrote:
On Mon 04-11-13 15:26:38, Jan Kara wrote:
On Fri 01-11-13 15:38:50, Cody P Schafer wrote:
Use rbtree_postorder_for_each_entry_safe() to destroy the rbtree instead
of opencoding an alternate postorder iteration that modifies the tree
Thanks. I've
Paul,
As I added the rcu_is_watching() to the ftrace code to prevent perf
from tracing functions where RCU is not watching, I noticed that the
rcu_is_watching() functions can themselves be traced. I would say this
is a helper function and not something that we need to trace, as it can
cause a
On Mon, 4 Nov 2013 15:38:13 +0100, Oleg Nesterov wrote:
> On 11/04, Namhyung Kim wrote:
>>
>> On Sun, 3 Nov 2013 21:20:37 +0100, Oleg Nesterov wrote:
>> >
>> > But. Perhaps it makes sense to at least add a couple of trivial
>> > helpers in 10/13? Something like arg_buf_get/put/init, just to
>> >
We had a couple of reports of people that are mounting NFS filesystems,
and then bind mounting certain local files onto dentries in that nfs
mount (sort of like a poor-man's unionmount).
This all works well until the dentry serving as the mountpoint fails
d_revalidate. The dentry will end up
Hi Oleg,
On Mon, 4 Nov 2013 15:35:17 +0100, Oleg Nesterov wrote:
> Hi Namhyung,
>
> On 11/04, Namhyung Kim wrote:
>>
>> >>
>> >> + if (atomic_dec_and_test(_buffer_ref)) {
>> >> + free_percpu(uprobe_cpu_buffer);
>> >> + uprobe_cpu_buffer = NULL;
>> >> + }
>> >> +
>> >>
Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node
present' made the call to phy_scan optional, if the DT has a link to
the phy node.
However phy_scan has the side effect of calling phy_addr_set, which
writes the phy MDIO address to the ethernet controller. If phy_addr_set
is not
From: Jason Wang
Date: Fri, 1 Nov 2013 14:07:48 +0800
> Commit 2613af0ed18a11d5c566a81f9a6510b73180660a (virtio_net: migrate mergeable
> rx buffers to page frag allocators) try to increase the payload/truesize for
> MTU-sized traffic. But this will introduce the extra overhead for GSO packets
>
From: Jason Wang
Date: Fri, 1 Nov 2013 14:07:47 +0800
> Sometimes we need to coalesce the rx frags to avoid frag list. One example is
> virtio-net driver which tries to use small frags for both MTU sized packet and
> GSO packet. So this patch introduce skb_coalesce_rx_frag() to do this.
>
>
On Mon, Nov 04 2013 at 12:49pm -0500,
Mikulas Patocka wrote:
>
>
> On Mon, 4 Nov 2013, Mike Snitzer wrote:
>
> > On Mon, Nov 04 2013 at 10:25am -0500,
> > Mikulas Patocka wrote:
> >
> > >
> > >
> > > On Mon, 4 Nov 2013, Mike Snitzer wrote:
> > >
> > > > On Mon, Nov 04 2013 at 10:06am
On Mon, Nov 04, 2013 at 03:56:52PM -0800, Mike Christie wrote:
> On 11/04/2013 03:36 PM, Kent Overstreet wrote:
> > @@ -1822,6 +1820,14 @@ void generic_make_request(struct bio *bio)
> > */
> > blk_queue_bounce(q, );
> >
> > + if (!blk_queue_largebios(q))
> > +
When a disk is in SLEEP mode it can not respond to commands,
including the CHECK POWER command. Instead of waking up the
sleeping disk, fake the reply to the CHECK POWER command to
indicate the disk is in standby mode. This prevents udisks
from waking up sleeping disks when it polls to see if
On 2013年11月04日 17:52, Paul E. McKenney wrote:
> On Mon, Nov 04, 2013 at 11:13:12AM +0800, Lan Tianyu wrote:
>> On 2013年10月29日 18:29, Lan Tianyu wrote:
>>> On 10/29/2013 05:51 PM, Paul E. McKenney wrote:
On Tue, Oct 29, 2013 at 04:48:56PM +0800, Lan Tianyu wrote:
> In some cases, nohz
The ATA SLEEP mode saves some more power than SUSPEND, and
has basically the same recovery time, so use it instead.
Signed-off-by: Phillip Susi
---
drivers/ata/libata-scsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/libata-scsi.c
This only affects the tsc -> time of day correlation when doing
`trace-cmd record --date`.
get_date_to_ts() writes a dummy event to trace_marker and then reads it back.
Reading it back is done by looping over all per-cpu raw trace pipes and trying
to read. This read should be non-blocking,
On Oct 25, 2013, at 2:18 AM, Linus Torvalds
wrote:
> On Fri, Oct 25, 2013 at 8:25 AM, Artem S. Tashkinov wrote:
>>
>> On my x86-64 PC (Intel Core i5 2500, 16GB RAM), I have the same 3.11
>> kernel built for the i686 (with PAE) and x86-64 architectures. What’s
>> really troubling me is that
On Mon 04-11-13 15:26:38, Jan Kara wrote:
> On Fri 01-11-13 15:38:50, Cody P Schafer wrote:
> > Use rbtree_postorder_for_each_entry_safe() to destroy the rbtree instead
> > of opencoding an alternate postorder iteration that modifies the tree
> Thanks. I've merged the patch into my tree.
Hum,
--
Hi There,
Recruitment of a Mystery-Shopper Get Paid, $200 per-assignment. If
Interested Reply us Immediately.
--
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
Hi Andrew -
On Thu, 2013-10-17 at 17:50 -0700, Davidlohr Bueso wrote:
> Linus recently pointed out[1] some of the amount of unnecessary work
> being done with the mmap_sem held. This patchset is a very initial
> approach on reducing some of the contention on this lock, and moving
> work
Hello,
On Mon 04-11-13 14:31:34, Andiry Xu wrote:
> When I'm trying XIP on ext2, I find that xip does not work on ext2
> with latest kernel.
>
> Reproduce steps:
> Compile kernel with following configs:
> CONFIG_BLK_DEV_XIP=y
> CONFIG_EXT2_FS_XIP=y
>
> And run following commands:
> # mke2fs
Jason,
On Mon, Nov 04, 2013 at 05:27:19PM -0700, Jason Gunthorpe wrote:
> Commit cc9d4598 'net: mv643xx_eth: use of_phy_connect if phy_node
fyi: set core.abbrev = 12 in your git config, according to Linus, 7/8
was a bad decision...
> present' made the call to phy_scan optional, if the DT has a
The mm-of-the-moment snapshot 2013-11-04-16-11 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
On Sun, 27 Oct 2013 10:30:15 -0700 Greg Thelen wrote:
> Tests various percpu operations.
Could you please take a look at the 32-bit build (this is i386):
lib/percpu_test.c: In function 'percpu_test_init':
lib/percpu_test.c:61: warning: integer constant is too large for 'long' type
If MODPUBKEY is specified and other than default ./signing_key.x509, use
that key instead of generating one on-the-fly.
Signed-off-by: Eric Miao
Cc: David Howells
Cc: Dan Willemsen
---
kernel/Makefile | 8
1 file changed, 8 insertions(+)
diff --git a/kernel/Makefile
Even if MODULE_SIG_FORCE is turned on, it is still useful if module
can export sig_enforce, so user space will know if module signature
is turned on and forced.
Signed-off-by: Eric Miao
Cc: David Howells
Cc: Dan Willemsen
---
kernel/module.c | 8
1 file changed, 8 insertions(+)
diff
On 11/04/2013 03:36 PM, Kent Overstreet wrote:
> @@ -1822,6 +1820,14 @@ void generic_make_request(struct bio *bio)
>*/
> blk_queue_bounce(q, );
>
> + if (!blk_queue_largebios(q))
> + split = blk_bio_segment_split(q, bio,
On 11/04/2013 04:26 PM, Heiko Stübner wrote:
> I remember we had a discussion about how things like bias-disable explicitly
> shouldn't have a value, when they are represented in the list-format:
>
> pcfg_pull_none: pcfg_pull_none {
> bias-disable;
>
I had a machine crash this weekend running a 3.10.16 kernel that
additionally has a few backported networking patches for performance
improvements. At this point I can't rule out that the bug isn't from
those patches, and I haven't yet tried to see if I can reproduce the
crash. I did happen to
Em Thu, Oct 31, 2013 at 03:56:05PM +0900, Namhyung Kim escreveu:
> -static void hist_entry__add_cpumode_period(struct hist_entry *he,
> +static void hist_entry__add_cpumode_period(struct he_stat *he_stat,
> unsigned int cpumode, u64 period)
So it is not
The way the block layer is currently written, it goes to great lengths
to avoid having to split bios; upper layer code (such as bio_add_page())
checks what the underlying device can handle and tries to always create
bios that don't need to be split.
But this approach becomes unwieldy and
Since generic_make_request() can now handle arbitrary size bios, all we
have to do is make sure the bvec array doesn't overflow.
Signed-off-by: Kent Overstreet
---
drivers/scsi/osd/osd_initiator.c | 5 +-
drivers/target/target_core_pscsi.c | 5 +-
fs/bio.c | 158
Next patch is going to make generic_make_request() handle arbitrary
sized bios by splitting them if necessary. It makes more sense to call
blk_queue_bounce() first, partly so it's working on larger bios - but also the
code that splits bios, and __blk_recalc_rq_segments(), won't have to take into
We get a measurable performance increase by handling this in the driver when
we're already looping over the biovec, instead of handling it separately in
generic_make_request() (or bio_add_page() originally)
Signed-off-by: Kent Overstreet
---
drivers/block/mtip32xx/mtip32xx.c | 46
With immutable biovecs we don't want code accessing bi_io_vec directly -
the uses this patch changes weren't incorrect since they all own the
bio, but it makes the code harder to audit for no good reason - also,
this will help with multipage bvecs later.
Signed-off-by: Kent Overstreet
Cc: Jens
So we get to delete our hacky workaround.
Signed-off-by: Kent Overstreet
---
drivers/md/bcache/bcache.h| 18
drivers/md/bcache/io.c| 100 +-
drivers/md/bcache/journal.c | 4 +-
drivers/md/bcache/request.c | 16 +++
generic_make_request() will now do for us what the code in blk-lib.c was
doing manually, with the bio_batch stuff - we still need some looping in
case we're trying to discard/zeroout more than around a gigabyte, but
when we can submit that much at a time doing the submissions in parallel
really
We will need the MCS lock code for doing optimistic spinning for rwsem.
Extracting the MCS code from mutex.c and put into its own file allow us
to reuse this code easily for rwsem.
Reviewed-by: Ingo Molnar
Reviewed-by: Peter Zijlstra
Signed-off-by: Tim Chen
Signed-off-by: Davidlohr Bueso
---
The following changes are made to enable mcs_spinlock.h file to be
widely included in other files without causing problem:
1) Include a number of prerequisite header files and define
arch_mutex_cpu_relax(), if not previously defined.
2) Separate out mcs_spin_lock() into a mcs_spinlock.c file.
This patch corrects the way memory barriers are used in the MCS lock
and removes ones that are not needed. Also add comments on all barriers.
Reviewed-by: Paul E. McKenney
Reviewed-by: Tim Chen
Signed-off-by: Jason Low
---
include/linux/mcs_spinlock.h | 13 +++--
1 files changed,
Remove unnecessary operation and make the cmpxchg(lock, node, NULL) == node
check in mcs_spin_unlock() likely() as it is likely that a race did not occur
most of the time.
Also add in more comments describing how the local node is used in MCS locks.
Reviewed-by: Paul E. McKenney
Reviewed-by:
In this patch series, we separated out the MCS lock code which was previously
embedded in the
mutex.c. This allows for easier reuse of MCS lock in other places like rwsem
and qrwlock.
We also did some micro optimizations and barrier cleanup.
This patches were previously part of the rwsem
This replaces some of the code that was in __bio_map_user_iov(), and
soon we're going to use this helper in the dio code.
Note that this relies on the recent change to make
generic_make_request() take arbitrary sized bios - we're not using
bio_add_page() here.
Signed-off-by: Kent Overstreet
Cc:
It was being open coded in a few places.
Signed-off-by: Kent Overstreet
Cc: Jens Axboe
Cc: Joern Engel
Cc: Prasad Joshi
---
block/blk-flush.c | 19 +--
fs/logfs/dev_bdev.c | 8 +---
2 files changed, 2 insertions(+), 25 deletions(-)
diff --git a/block/blk-flush.c
Now that immutable biovecs is in, these are the remaining patches required for
my DIO rewrite, along with some related cleanup/refactoring.
The key enabler is patch 4 - making generic_make_request() handle arbitary sized
bios. This takes what was once bio_add_page()'s responsibility and pushes it
Am Montag, 4. November 2013, 13:24:10 schrieb Linus Walleij:
> > In my driver, I have the "one entry per pin" support for all my
> > properties instead of just the function property, like the "drive_str"
> > property below:
> >
> > + grp_1 {
> > + brcm,pins
On Mon, 2013-11-04 at 11:29 -0700, Jim Davis wrote:
> Building with the attached random configuration file,
>
> security/integrity/digsig.c:70:5: error: redefinition of
> ‘integrity_init_keyring
> ’
> int integrity_init_keyring(const unsigned int id)
> ^
> In file included from
Am 04.11.2013 20:49, schrieb Geert Uytterhoeven:
On Mon, Nov 4, 2013 at 6:00 PM, Alexander Holler wrote:
3.14
3.141
3.1415
3.14159
3.141592
3.1415926
(...)
4.0
Since when does \pi converge to 4.0?
Since 3.12 > 3.9. ;)
--
To unsubscribe from this list: send the line "unsubscribe
Hi,
Le 04/11/2013 23:20, Darren Hart a écrit :
> I'm hardly an expert here, but the appears sane to me. Perhaps a
> comment above the PYTHON_VERS describing what valid values are would
> be helpful. Otherwise, looks good to me.
Expected values are "python" and "python3" for PYTHON_VERS.
> The reason I mention it is because I've been mulling over something
> Dirk Hohndel said during LinuxCon EU and the kernel summit. He asked
> at the Q session whether we could do a release with just stability
> and bug-fixes, and I pooh-poohed it because I didn't see most of us
> having the
On 11/04/2013 07:10 AM, Fengguang Wu wrote:
> Hi Jens,
>
> I'm not very sure about this bisect, but anyway it'd be good to inform
> you of a possible problem on commit
>
> commit 3a02db083a78c9f3c9b69305ab513f9422d91b08
> Author: Jens Axboe
> Date: Fri May 24 20:22:33 2013 +0200
>
>
On 11/04/2013 12:11 PM, Ingo Molnar wrote:
>
> * H. Peter Anvin wrote:
>
>> 8192 maybe?
>
> Yeah, that makes more sense I guess.
>
However, I still have serious issues with crap like this because
randconfig is basically broken. If nothing else we need to get that
feedback to the kconfig
Ingo,
Sorry for the late response. My old 4 socket Westmere
test machine went down and I have to find a new one,
which is a 4 socket Ivybridge machine with 15 cores per socket.
I've updated the workload as a perf benchmark (see patch)
attached. The workload will mmap, then access memory
in
Hi,
When I'm trying XIP on ext2, I find that xip does not work on ext2
with latest kernel.
Reproduce steps:
Compile kernel with following configs:
CONFIG_BLK_DEV_XIP=y
CONFIG_EXT2_FS_XIP=y
And run following commands:
# mke2fs -b 4096 /dev/ram0
# mount -t ext2 -o xip /dev/ram0 /mnt/ramdisk/
# dd
On 11/04/2013 06:00 AM, Geert Uytterhoeven wrote:
> do_div() (called by sector_div() if CONFIG_LBDAF=y) is meant for divisions
> of 64-bit number by 32-bit numbers. Passing 64-bit divisor types caused
> issues in the past on 32-bit platforms, cfr. commit
> ea077b1b96e073eac5c3c5590529e964767fc5f7
On Sun, Nov 03, 2013 at 03:39:14PM -0800, Linus Torvalds wrote:
> On Sun, Nov 3, 2013 at 11:54 AM, Al Viro wrote:
> >
> > IIRC, at some point such an attempt has seriously hurt iget() on 32bit
> > boxen, so we ended up deciding not to go there. Had been years ago,
> > though...
>
> Yeah, I
On Mon, 2013-11-04 at 14:21 -0800, Andrew Morton wrote:
> On Thu, 31 Oct 2013 16:12:44 -0700 Joe Perches wrote:
>
> > This now uses the "$balanced_parens" test and also makes
> > the test depend on perl v5.10 and higher.
>
> What happens if one uses an older perl version? A mysterious-looking
On Thu, 31 Oct 2013 16:12:44 -0700 Joe Perches wrote:
> This now uses the "$balanced_parens" test and also makes
> the test depend on perl v5.10 and higher.
What happens if one uses an older perl version? A mysterious-looking
splat, I assume?
It would be nicer to have some explicit perl
I'm hardly an expert here, but the appears sane to me. Perhaps a
comment above the PYTHON_VERS describing what valid values are would
be helpful. Otherwise, looks good to me.
On Mon, Nov 4, 2013 at 12:32 AM, Johannes Berg
wrote:
> On Fri, 2013-11-01 at 17:19 -0400, Steven Rostedt wrote:
>>
On Mon, Nov 04, 2013 at 05:41:27PM +0100, Frank Haverkamp wrote:
> Hi Greg,
>
> Am Mittwoch, den 30.10.2013, 10:44 -0700 schrieb Greg KH:
> > On Wed, Oct 30, 2013 at 10:32:58AM +0100, Frank Haverkamp wrote:
> > > +/*
> > > + * Create device_attribute structures / params: name, mode, show, store
>
DWC3 requires epout to have buffer size aligned to MaxPacketSize value.
This patch sets necessary quirk for it.
Signed-off-by: David Cohen
---
Changes from v4 to v4.1:
- just updated patch's subject. No actual code changed.
drivers/usb/dwc3/gadget.c | 6 ++
1 file changed, 6
On Mon, Nov 04, 2013 at 06:08:01PM +0100, Frank Haverkamp wrote:
> +if GENWQE
> +
> +config GENWQE_DEVNAME
> +string "Name for sysfs and device nodes"
> + default "genwqe"
> +help
> + Select alternate name for sysfs and device nodes.
> +
> +endif
Why is this still
Hi,
These patches are a proposal to add gadget quirks in an immediate objective to
adapt f_fs when using DWC3 controller. But the quirk solution is generic and
can be used by other controllers to adapt gadget functions to their
non-standard restrictions.
This change is necessary to make
Check gadget.quirk_ep_out_aligned_size to decide if buffer size requires
to be aligned to maxpacketsize of an out endpoint. ffs_epfile_io() needs
to pad epout buffer to match above condition if quirk is found.
Signed-off-by: David Cohen
---
drivers/usb/gadget/f_fs.c | 22 ++
DWC3 requires epout to have buffer size aligned to MaxPacketSize value.
This patch adds necessary quirk for it.
Signed-off-by: David Cohen
---
drivers/usb/dwc3/gadget.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index
This patch moves all bitflags to the end of usb_gadget struct in order
to improve readability.
Signed-off-by: David Cohen
---
include/linux/usb/gadget.h | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/include/linux/usb/gadget.h
Due to USB controllers may have different restrictions, usb gadget layer
needs to provide a generic way to inform gadget functions to complain
with non-standard requirements.
This patch adds 'quirk_ep_out_aligned_size' field to struct usb_gadget
to inform when controller's epout requires buffer
Hello,
On Mon, Nov 04, 2013 at 09:51:35PM +, Serge E. Hallyn wrote:
> Do you have a list of such issues which you see with delegation? That is,
> cases where, if ownership of a subtree is granted to a non-root user,
> that user can affect tasks owned by other users who are in other
>
On Fri, 01 Nov 2013 18:31:40 +0400 Maxim Patlasov
wrote:
> "strictlimit" feature was introduced to enforce per-bdi dirty limits for
> FUSE which sets bdi max_ratio to 1% by default:
>
> http://www.http.com//article.gmane.org/gmane.linux.kernel.mm/105809
>
> However the feature can be useful
On 05/11/13 04:08, Frank Haverkamp wrote:
> Selecting interface names via configuration option is obsolete.
Don't do this. You are adding completely new code, so there is no reason
to post a patch full of code that is known to be incorrect, followed by
a set of patches fixing things. Just post
Add this to "try this"...
Chen Gang's defect is because his git repository branch
had a commit he authored but where did not add his signature.
Also, there's a defect in function vcs_find_signers.
It should only return the commit count and array references.
If there are no signers in the commit
Quoting Tejun Heo (t...@kernel.org):
> Hello, Serge.
>
> On Tue, Jul 23, 2013 at 3:28 PM, Serge Hallyn wrote:
> > On Tue, Jul 23, 2013 at 02:04:26PM -0500, Serge Hallyn wrote:
> > > If task A is uid 1000 on the host, and creates task B as uid X in a new
> > > user namespace, then task A, still
On Monday 2013-11-04 01:10, Linus Torvalds wrote:
>
>Onto a totally different topic: we're getting to release numbers where
>I have to take off my socks to count that high again. I'm ok with
>3. [...] [4.0 "ok, after 3.19 (or whatever),"]
What would you do when the major number becomes such an
Add support for battery charge thresholds in new Sandy Bridge and Ivy Bridge
ThinkPads. Based on the unofficial documentation in tpacpi-bat.
The threshold files support the values '0' for the controller's default,
and 1-99 as percentages. Values outside of that range are rejected. The
behaviour
On 11/04/13 14:49, Oleg Nesterov wrote:
On 10/29, Oleg Nesterov wrote:
David. Perhaps we can avoid the new hook altogether? What if we do
the simple change below (it ignores powerpc) ?
Then arm can add "unsigned long ixol[2]" into its arch_uprobe, and
arch_uprobe_analyze_insn() can initialize
On Mon, Nov 04, 2013 at 08:18:11PM +0100, Peter Zijlstra wrote:
> On Mon, Nov 04, 2013 at 08:11:27PM +0100, Peter Zijlstra wrote:
> > +#define smp_load_acquire(p, v)
> > \
>
> I R idiot!! :-)
OK, I did miss this one as well... :-/
On Mon, Nov 04, 2013 at 09:24:58AM -0800, James Ralston wrote:
> This patch adds the AHCI-mode SATA Device IDs for the Intel Wildcat Point-LP
> PCH.
>
> Signed-off-by: James Ralston
Applied to for-3.13 w/ stable cc'd.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line
On Mon, 4 Nov 2013 12:41:52 +0200 (EET) "Kirill A. Shutemov"
wrote:
> Kirill A. Shutemov wrote:
> > Matthew noticed that hugetlb doesn't participate in ASLR on x86-64.
> > The reason is genereic hugetlb_get_unmapped_area() which is used on
> > x86-64. It doesn't support randomization and use
On Mon, Nov 04, 2013 at 10:36:17PM +0200, Michael S. Tsirkin wrote:
> srcu read lock/unlock include a full memory barrier
> but that's an implementation detail.
> Add an API for make memory fencing explicit for
> users that need this barrier, to make sure we
> can change it as needed without
On Mon, Nov 04, 2013 at 06:21:05PM +0800, Gu Zheng wrote:
> Introduce flag KM_ZERO which is used to alloc zeroed entry, and convert
> kmem_{zone_}zalloc to call kmem_{zone_}alloc() with KM_ZERO directly,
> in order to avoid the setting to zero step.
> And following Dave's suggestion, make
On Mon, Nov 04, 2013 at 08:11:27PM +0100, Peter Zijlstra wrote:
> On Mon, Nov 04, 2013 at 08:27:32AM -0800, Paul E. McKenney wrote:
> > All this is leading me to suggest the following shortenings of names:
> >
> > smp_load_with_acquire_semantics() -> smp_load_acquire()
> >
> >
From: hayeswang
Date: Thu, 31 Oct 2013 13:52:38 +0800
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Thursday, October 31, 2013 5:05 AM
>>
>> From: Hayes Wang
>> Date: Wed, 30 Oct 2013 15:13:39 +0800
> [...]
>> Basically, your driver will now queue up to 1,000 packets onto
>> this
> Sure; this is your baby :) Why don't you handle it via your tree,
> since it's more related to xen than any PCI core stuff.
>
> Acked-by: Bjorn Helgaas
Definitly fixed in v3.12. Just tested it and it works.
George, Ian, how do I "close" a bug in http://bugs.xenproject.org/xen/bug/12 ?
--
On Wed, 30 Oct 2013, Daniel Kiper wrote:
> Hi,
>
> Here is a short summary of our discussion. It looks
> that we have two choices right now:
> - chainloader,
> - multiboot2 protocol.
>
> chainloader solution could be implemented quite easily. Some code should be
> added for command line
srcu read lock/unlock include a full memory barrier
but that's an implementation detail.
Add an API for make memory fencing explicit for
users that need this barrier, to make sure we
can change it as needed without breaking all users.
Acked-by: "Paul E. McKenney"
Signed-off-by: Michael S.
I noticed that srcu_read_lock/unlock both have a memory barrier,
so just by moving srcu_read_unlock earlier we can get rid of
one call to smp_mb() using smp_mb__after_srcu_read_unlock instead.
Unsurprisingly, the gain is small but measureable using the unit test
microbenchmark:
before
Dave,
Please accept the following pull request intended for the 3.13 tree...
I had intended to pass most of these to you as much as two weeks ago.
Unfortunately, I failed to account for the effects of bad Internet
connections and my own fatique/laziness while traveling. On the bright
side, at
Commit-ID: b9c5143a012a543c4ee872498d6dbae5c10beb2e
Gitweb: http://git.kernel.org/tip/b9c5143a012a543c4ee872498d6dbae5c10beb2e
Author: Frederic Weisbecker
AuthorDate: Wed, 11 Sep 2013 14:46:56 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 Nov 2013 11:50:28 -0300
perf
> This solution pretty-much equivalent to per-CPU data structures. And
No it's not, it doesn't require one queue per CPU.
A CPU these days isn't really a CPU anymore, but often a CPU thread,
which is much more light weight. So having a queue per CPU is often
total overkill, and amplifies any per
Commit-ID: 162f0befda3becc2cc9f44075fccc030e55baec1
Gitweb: http://git.kernel.org/tip/162f0befda3becc2cc9f44075fccc030e55baec1
Author: Frederic Weisbecker
AuthorDate: Wed, 11 Sep 2013 16:18:24 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 Nov 2013 11:57:06 -0300
perf
On 11/04/2013 01:10 AM, Linus Torvalds wrote:
>
...
Anyway..
Onto a totally different topic: we're getting to release numbers where
I have to take off my socks to count that high again. I'm ok with
3., but I don't want us to get to the kinds of crazy
numbers we had in the 2.x series, so at
Commit-ID: 1902efe7f626fdebe1520f5ff11f1309ec506708
Gitweb: http://git.kernel.org/tip/1902efe7f626fdebe1520f5ff11f1309ec506708
Author: Frederic Weisbecker
AuthorDate: Wed, 11 Sep 2013 16:56:44 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 Nov 2013 12:13:53 -0300
perf
Commit-ID: 4bceffbc26fab2444742db59c6f8124c29e41369
Gitweb: http://git.kernel.org/tip/4bceffbc26fab2444742db59c6f8124c29e41369
Author: Namhyung Kim
AuthorDate: Fri, 1 Nov 2013 16:33:12 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 Nov 2013 12:54:32 -0300
perf report:
Commit-ID: ac6976255076d4bf761abfbecb19d46af5b88046
Gitweb: http://git.kernel.org/tip/ac6976255076d4bf761abfbecb19d46af5b88046
Author: Namhyung Kim
AuthorDate: Fri, 1 Nov 2013 16:33:11 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 Nov 2013 12:51:45 -0300
perf tools:
Commit-ID: 0883d9d730fc294c3d90ebd190b94e5782ead316
Gitweb: http://git.kernel.org/tip/0883d9d730fc294c3d90ebd190b94e5782ead316
Author: Steven Rostedt (Red Hat)
AuthorDate: Fri, 1 Nov 2013 17:53:57 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 Nov 2013 14:35:35 -0300
101 - 200 of 1126 matches
Mail list logo
