Ugh. Forgot to actually add the ODD people to the list...
Linus
On Tue, Feb 26, 2013 at 8:27 AM, Linus Torvalds
wrote:
> On Tue, Feb 26, 2013 at 8:10 AM, Nishanth Menon wrote:
>> On 16:55-20130226, Rafael J. Wysocki wrote:
>>>
>>> It says that in &quo
On Tue, Feb 26, 2013 at 8:37 AM, Tejun Heo wrote:
>
> One interesting bit, for me (and possibly Aaron too), ODD is much more
> closer to an everyday term. For some reason, at least in Korea, ODD
> is a popular term. For exmple, the likes of newegg would use it along
> with CPU, SSD or VGA to lab
On Thu, Feb 21, 2013 at 9:26 PM, Markus F.X.J. Oberhumer
wrote:
>
> please pull my "lzo-update" branch from
>
> git://github.com/markus-oberhumer/linux.git lzo-update
I *really* want github (and other general hosting) pull requests to be
for signed tags, so that I can see your gpg key and there
On Fri, Feb 22, 2013 at 6:21 PM, Bryan Wu wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds.git
> for-next
Pulled, but I'd *really* like to see some human-readable explanation
of what happened, so that I can make my merge messages be much more
informative. Next time,
On Mon, Feb 25, 2013 at 12:27 PM, Wolfram Sang wrote:
>
> here are the changes for the i2c subsystem for 3.9. Highlights:
>
> In addition, there is the usual bunch of fixes, cleanups, devm_*
> conversions, etc. Please pull.
Pulled, but when doing the conflict resolution, I noted that at l
On Tue, Feb 26, 2013 at 8:08 AM, Linus Torvalds
wrote:
>
> It is totally untested, though. Does it work for you (and we should
> do the same thing for the grows-up case, obviously)?
Ok, thinking about this more, this is not good enough.
There is one case where growing into the prev
On Tue, Feb 26, 2013 at 3:43 PM, Linus Torvalds
wrote:
>
> So I'll need to extend on that logic a bit more.
Ok, here's the fleshed-out patch. Also fixed to use "expand_stack()",
which is what the page fault handling actually uses. And it has the
GROWSUP case as well a
On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie wrote:
>
> Highlights:
>
> i915: all over the map, haswell power well enhancements, valleyview macro
> horrors cleaned up, killing lots of legacy GTT
> code,
Lowlight:
There's something wrong with i915 DP detection or whatever. I get
stuff like this:
On Tue, Feb 26, 2013 at 5:39 PM, Linus Torvalds
wrote:
>
> Lowlight:
>
> [5.710827] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
Oh, forgot to mention - this is my trusty old Westmere chip (aka "Core
i5-670", aka Clarkdale, a
On Tue, Feb 26, 2013 at 7:30 PM, Dave Airlie wrote:
>
> If you want to just bump it so Ironlake isn't affected, (patch attached).
It works fine 95% of the time and isn't a hard failure when it
doesn't, so this isn't critical. I can wait for it to be fixed a
while.
> Is this external DP monitor o
On Wed, Feb 27, 2013 at 3:15 AM, Heiko Carstens
wrote:
>
> Tested with 64 bit kernel with 64 bit and 31 bit mode user space as well as
> with 31 bit kernel and 31 bit user space. Each with legacy and flexible
> mmap layout.
> The bug is fixed and everything else still seems to work. Thanks!
>
> Te
On Tue, Feb 26, 2013 at 11:33 PM, Dave Airlie wrote:
>
> It looks to me like the weak bit isn't working so well
>
> if (platform_sysrq_reset_seq) {
> for (i = 0; i < ARRAY_SIZE(sysrq_reset_seq); i++) {
> key = platform_sysrq_reset_seq[i];
> 6d: 6
On Wed, Feb 27, 2013 at 8:42 AM, Rik van Riel wrote:
>
> To keep the results readable and relevant, I am reporting the
> plateau performance numbers. Comments are given where required.
>
> 3.7.6 vanilla 3.7.6 w/ backoff
>
> all_utime 333000 333000
> alltest
On Wed, Feb 27, 2013 at 9:15 AM, Sedat Dilek wrote:
>
> Where is it?
Oh sorry, I hadn't pushed it out, I was looking through other emails
in the meantime.
Pushed out now (but mirror delays to public sites etc..)
The patch itself is the same one I already attached earlier though
(the last versio
On Wed, Feb 27, 2013 at 9:45 AM, Markus Trippelsdorf
wrote:
>
> git revert
> 06b0c886214a223dde7b21cbfc3008fd20a8ce16..74cd15cd02708c7188581f279f33a98b2ae8d322
> fixes all issues...
Hmm. I'm hoping this will have a quick resolution that doesn't mean
having to revert all that. But it's good to ha
On Wed, Feb 27, 2013 at 9:58 AM, Mathieu Poirier
wrote:
>
> Your fix is compiling, running and yielding the correct results -
> apologies about that.
>
> Acked-by: Mathieu Poirier
Ok, good. Committed and pushed out. Adding rmk and dhowells to the cc
just to let them know, since Dave said they we
The following changes since commit 304e220f0879198b1f5309ad6f0be862b4009491:
ext4: fix free clusters calculation in bigalloc filesystem (2013-02-22
15:27:52 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
tags/ext4_for_linus
for
On Wed, Feb 27, 2013 at 11:53 AM, Rik van Riel wrote:
>
> If we have two classes of spinlocks, I suspect we would be better
> off making those high-demand spinlocks MCS or LCH locks, which have
> the property that having N+1 CPUs contend on the lock will never
> result in slower aggregate throughp
On Wed, Feb 27, 2013 at 12:15 PM, Theodore Ts'o wrote:
> On Wed, Feb 27, 2013 at 03:12:17PM -0500, Linus Torvalds wrote:
>> The following changes since commit 304e220f0879198b1f5309ad6f0be862b4009491:
>
> Obviously, this wasn't from Linus. I screwed up on sending
On Wed, Feb 27, 2013 at 6:58 PM, Rik van Riel wrote:
>
> On the other hand, both MCS and the fast queue locks
> implemented by Michel showed low variability and high
> performance.
On microbenchmarks, and when implemented for only one single subsystem, yes.
> The numbers for Michel's MCS and fas
On Wed, Feb 27, 2013 at 8:06 PM, Davidlohr Bueso wrote:
>
> The attached file shows how the amount of sys time used by the ipc lock
> for a 4 and 8 socket box.
I have to say, even with the improvements, that looks pretty
disgusting. It really makes me wonder if that thing couldn't be done
better
On Thu, Feb 28, 2013 at 7:13 AM, Rik van Riel wrote:
>
> Btw, the IPC lock is already fairly fine grained. One ipc
> lock is allocated for each set of semaphores allocated through
> sys_semget. Looking up those semaphores in the namespace, when
> they are used later, is done under RCU.
Bullshit.
On Thu, Feb 28, 2013 at 10:22 AM, Linus Torvalds
wrote:
>
> I'm sure there are other things we could do to improve ipc lock times
> even if we don't actually split the lock, but the security one might
> be a good first step.
Btw, if somebody has a benchmark for thre
On Thu, Feb 28, 2013 at 1:14 PM, Rik van Riel wrote:
>
> I have modified one of the semop tests to use multiple semaphores.
Ooh yeah. This shows contention quite nicely. And it's all from
ipc_lock, and looking at the top-10 loffenders of the profile:
43.01% semop-multi [kernel.kallsyms] [k]
On Thu, Feb 28, 2013 at 2:38 PM, Rik van Riel wrote:
>
> I could see doing the permission checks under a seq lock.
>
> If the permissions, or any other aspect of the semaphore
> array changed while we were doing our permission check,
> we can simply jump back to the top of the function and
> try a
On Mon, Feb 18, 2013 at 7:53 AM, Frederic Weisbecker wrote:
>
> Here is an updated version. It cleans up things a bit and boots fine with my
> usual
> config. There might be still some small details to work on but here is the
> big picture.
>
> What do you think?
Looks fine to me. Did this get
Do not leak kernel page mapping locations
net, sctp: remove CONFIG_EXPERIMENTAL
Konrad Rzeszutek Wilk (2):
Revert "xen/PVonHVM: fix compile warning in init_hvm_pv_info"
Revert "xen PVonHVM: use E820_Reserved area for shared_info"
Linus Torvalds (2):
mm: fix
On Tue, Feb 19, 2013 at 10:42 AM, Konrad Rzeszutek Wilk
wrote:
>
> To give you a 3.9 branch I am thinking to either:
>
> a). revert the merges I've for this new feature altogether and
> merge it later in v3.10 time-frame. They make about 50% off the
> code in this branch, so its big chu
On Tue, Feb 19, 2013 at 6:16 AM, Ingo Molnar wrote:
>
> Please pull the latest perf-urgent-for-linus git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> perf-urgent-for-linus
>
>HEAD: e97cbe3edf7d88aad4c21dd3de124d9f9d039881 perf/hwbp: Fix cleanup in
> case of k
On Tue, Feb 19, 2013 at 7:41 AM, Ingo Molnar wrote:
>
> Please pull the latest x86-platform-for-linus git tree from:
Hmm.
My main desktop just had a reboot failure - it just got stuck at the
end, not powering down, and not rebooting like it should have.
This is *not* necessarily the pull that c
On Tue, Feb 19, 2013 at 10:39 PM, Linus Torvalds
wrote:
>
> My main desktop just had a reboot failure - it just got stuck at the
> end, not powering down, and not rebooting like it should have.
Ok, it doesn't seem to be repeatable, so I'm going to ignore it unt
On Mon, Feb 18, 2013 at 6:51 PM, Jingoo Han wrote:
>
> are available in the git repository at:
> git://github.com/jingoo/linux.git samsung-fb-next
I _really_ want signed tags when pulling from untrusted hosts like
github. Same goes for your exynos-dp-next branch.
Not pulled.
Linu
On Wed, Feb 20, 2013 at 2:09 PM, David Miller wrote:
>
> 15) Orphan and delete a bunch of pre-historic networking drivers from
> Paul Gortmaker.
Nooo You killed the 3c501 and 3c503 drivers! Snif.
I wonder if they still worked..
Linus
--
To unsubscribe from this list: send t
On Wed, Feb 20, 2013 at 7:05 PM, Linus Torvalds
wrote:
>
> Nooo You killed the 3c501 and 3c503 drivers! Snif.
.. but thank gods, the 3c509 still exists in the tree. I was worried
for a minute.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-ker
On Thu, Feb 21, 2013 at 4:00 AM, David Howells wrote:
> A patch to fix some unreachable code in search_my_process_keyrings() got
> applied twice by two different routes upstream:
Ok, applied. Let's not apply this one twice. So Andrew, please don't
put it in your queue ;)
Linus
--
T
On Thu, Feb 21, 2013 at 6:03 AM, James Morris wrote:
> This is basically a maintenance update for the TPM driver and EVM/IMA.
Hmm. There were conflicts in lib/digsig.c and ima_main.c. The digsig
one was pretty trivial, but I'd like people to take a look at the IMA
one.
And that's not because the
On Thu, Feb 21, 2013 at 7:47 AM, David Howells wrote:
>
> Can you pull this patchset please?
Not without a lot more discussion first.
Quite frankly, this is f*cking moronic. The whole thing seems to be
designed around stupid interfaces, for completely moronic reasons. Why
should we do this?
I a
On Thu, Feb 21, 2013 at 8:42 AM, Matthew Garrett wrote:
>
> There's only one signing authority, and they only sign PE binaries.
Guys, this is not a dick-sucking contest.
If you want to parse PE binaries, go right ahead.
If Red Hat wants to deep-throat Microsoft, that's *your* issue. That
has n
On Wed, Feb 20, 2013 at 1:00 PM, Thomas Gleixner wrote:
> */
> void irq_exit(void)
> {
> +#ifndef __ARCH_IRQ_EXIT_IRQS_DISABLED
> + unsigned long flags;
> +
> + local_irq_save(flags);
> +#else
> + BUG_ON(!irqs_disabled();
> +#endif
Guys, STOP DOING THIS!
Adding BUG_ON()'s j
On Thu, Feb 21, 2013 at 9:49 AM, Matthew Garrett wrote:
>
> Vendors want to ship keys that have been signed by a trusted party.
> Right now the only one that fits the bill is Microsoft, because
> apparently the only thing vendors love more than shitty firmware is
> following Microsoft specs.
Quit
On Thu, Feb 21, 2013 at 10:06 AM, Mimi Zohar wrote:
>
> Almost, and enforcing file integrity is enabled. The merged result
> should look like what's contained in
> linux-integrity/next-upstreamed-patches:
>
> int ima_module_check(struct file *file)
> {
> if (!file) {
> if
On Thu, Feb 21, 2013 at 10:17 AM, David Howells wrote:
>
> There's a problem with your idea.
You continue to miss the big question:
- why should the kernel care?
- why do you bother with the MS keysigning of Linux kernel modules to
begin with?
Your arguments only make sense if you accept tho
On Thu, Feb 21, 2013 at 10:21 AM, Thomas Gleixner wrote:
>
> This was a draft patch. I made it a WARN_ON_ONCE() already.
Ok, good.
I really wish we could just get rid of BUG_ON(). It was a bad idea,
and it makes it easy for people to do the wrong thing. Sadly, we have
tons of them.
On Thu, Feb 21, 2013 at 10:34 AM, Peter Jones wrote:
> On Thu, Feb 21, 2013 at 10:25:47AM -0800, Linus Torvalds wrote:
>> - why do you bother with the MS keysigning of Linux kernel modules to
>> begin with?
>
> This is not actually what the patchset implements. All it'
On Thu, Feb 21, 2013 at 10:40 AM, Greg KH wrote:
>
> USB patches for 3.9-rc1
>
> Here's the big USB merge for 3.9-rc1
>
> Nothing major, lots of gadget fixes, and of course, xhci stuff.
Ok, so there were a couple of conflicts with Thierry Reding's series
to convert devm_request_and_ioremap() user
On Thu, Feb 21, 2013 at 1:12 PM, Arnd Bergmann wrote:
>
> The merge conflicts I mention in the tags are all for conflicts
> between the arm-soc branches. There are a few more conflicts
> with other stuff you already pulled, but it all looks simple
> as well. I have uploaded a 'for-linus' branch to
On Wed, Feb 20, 2013 at 9:17 PM, Jingoo Han wrote:
> samsung-fb updates for the v3.9:
Ok, there's a good gpg signed tag now, with a very recent gpg key. Try
to get that key signed by a few people.
Anyway, I pulled, and noticed that I had gotten these patches through
Andrew, so then I undid my pu
On Wed, Feb 20, 2013 at 9:20 PM, Jingoo Han wrote:
>
> git://github.com/jingoo/linux.git tags/exynos-dp-3.9
Ok, Andrew seems to have taken these patches too, so I got them through him.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Fri, Feb 22, 2013 at 7:06 AM, Thomas Gleixner wrote:
>>
>> I prefer to let you guys have the final word on this patch. Whether you
>> apply it or not, I fear I'll never be entirely happy either way :)
>> That's the sad fate of dealing with circular dependencies...
>
> plus the butt ugly softirq
On Fri, Feb 22, 2013 at 4:19 PM, Rafael J. Wysocki wrote:
>
> It won't revert, there's more stuff on top of it. And it is a fix, so
> reverting it is not really a good idea anyway.
Rafael, please don't *ever* write that crap again.
We revert stuff whether it "fixed" something else or not. The r
On Fri, Feb 22, 2013 at 4:48 PM, Rafael J. Wysocki wrote:
>
> The problem is, though, that even if bisection turns up something, it doesn't
> automatically mean that this particular commit is the one that caused the
> problem to happen in the first place.
No, I agree. I just react *very* strongly
On Mon, Mar 11, 2013 at 8:25 PM, Benjamin Herrenschmidt
wrote:
>
> A couple of weeks ago, David sent an email that went unanswered about a
> regression concerning orderly_poweroff(). I think the original patch
> causing it should be reverted, here's the actual email with the
> explanation:
Hmm..
On Tue, Mar 12, 2013 at 6:06 AM, Al Viro wrote:
>
> While we are at it, I don't see any reason for having separate file_operations
> for r/o, w/o and r/w cases; the only differences are in EBADF-returning
> ->read() and ->write() (and ->f_mode checks in vfs_read() et.al. take care of
> that) and m
On Mon, Mar 11, 2013 at 7:22 AM, Masami Hiramatsu
wrote:
> Beacuse hash_64() is called from the get_kprobe() inside
> int3 handler, kernel causes int3 recursion and crashes if
> kprobes user puts a probe on it.
>
> Usually hash_64() is inlined into caller function, but in
> some cases, it has inst
[ Added Junio and git to the recipients, and leaving a lot of stuff
quoted due to that... ]
On Mon, Mar 11, 2013 at 9:16 PM, Theodore Ts'o wrote:
> On Tue, Mar 12, 2013 at 03:10:53PM +1100, James Morris wrote:
>> On Tue, 12 Mar 2013, Stephen Rothwell wrote:
>> > The top commit in the security tre
On Mon, Mar 11, 2013 at 1:53 PM, Mathieu Desnoyers
wrote:
>
> Not sure. My guess would be that there is missing proof that I actually
> tested the patch
Well, it was actually mostly that the early patches I saw had very
tentative messages which made me go "Mathieu isn't sure" and kind of
waited f
On Tue, Mar 12, 2013 at 11:04 AM, Linus Torvalds
wrote:
>
> That said, the patch definitely looks like the right thing to do. I'll apply
> it.
Hmm. I applied it, and then pretty much immediately realized what was
problematic about it. What about the fs/bio.c one? This all fe
On Sun, Mar 10, 2013 at 4:04 PM, Al Viro wrote:
>
> The interesting part is what to do with it; it's not enough to make that
> BUG_ON() to STFU, unfortunately.
Why? That's what I did last week, it seemed to be the RightThing(tm)
to do. It somebody has opened a symlink, opening that again through
On Tue, Mar 12, 2013 at 11:22 AM, Oleg Nesterov wrote:
>
> And how this can help? The real problem is not GFP_KERNEL.
> call_usermodehelper_exec(UMH_WAIT_EXEC) will block.
Well, it's probably a starting point.
You need to do the argument handling atomically, because you cannot
delay that in a wo
On Tue, Mar 12, 2013 at 12:11 PM, Oleg Nesterov wrote:
>
> Confused... which arguments? The only argument is poweroff_cmd, it can't
> go away and kmalloc(GFP_KERNEL) is fine in work->func() ?
Hmm. I guess in this particular situation, we really don't have any
arguments from callers, no. I was con
On Tue, Mar 12, 2013 at 12:43 PM, Al Viro wrote:
>
> Umm... How about the following, then? I think it makes the whole thing
> simpler and saner... NOTE: this got only a light beating and we'd
> just seen an example of long-standing breakage in that area; I'd really
> like to see it tortured by
On Tue, Mar 12, 2013 at 2:20 PM, Theodore Ts'o wrote:
> What if we added the ability to do something like this:
>
> [remote "origin"]
> url =
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> fetch = +refs/heads/master:refs/heads/master
> mergeoption
On Tue, Mar 12, 2013 at 8:41 AM, Miklos Szeredi wrote:
> Al and Linus,
>
> Please consider overlayfs for inclusion into 3.10.
Yes, I think we should just do it. It's in use, it's pretty small, and
the other alternatives are worse. Let's just plan on getting this
thing done with.
Al, I realize yo
On Tue, Mar 12, 2013 at 2:47 PM, Junio C Hamano wrote:
>
> I agree that "--ff-only" thing is too strict and sometimes you would
> want to allow back-merges, but when you do allow such a back-merge,
> is there a reason you want it to be --no-signatures merge? When a
> subtree maintainer decides to
On Wed, Mar 13, 2013 at 12:54 PM, Eric W. Biederman
wrote:
>>
>> Hehe, I just checked my new kernel... that does not work (nothing in the
>> logs).
>> But I think it's good to see if the filesystem is registered/loaded.
>
> lsmod | grep overlayfs
How about the compiled-in case? What's wrong with
On Mon, Feb 25, 2013 at 11:02 PM, Ingo Molnar wrote:
>
> Stephane Eranian (1):
> perf/x86: Add Intel IvyBridge event scheduling constraints
So thanks to my new Chromebook, I'm trying to do perf stuff on
IvyBridge. I was hoping the whole exact cycle counting would work
better, since the last
On Thu, Mar 14, 2013 at 1:32 PM, Linus Torvalds
wrote:
>
> And to make things interesting, I seem to be able to only reproduce
> this *after* a suspend cycle. That may be just happenstance, since it
> seemed to be hard to replicate and most of the time it has happened
> under X w
On Thu, Mar 14, 2013 at 3:09 PM, Stephane Eranian wrote:
>
> Could be related to suspend/resume. But were you running perf across
> that resume/suspend cycle?
No.
In most cases I was running a perf record before and after (but not
*while* suspending)
In at least one other crash, I didn't run pe
On Thu, Mar 14, 2013 at 5:24 PM, Stephane Eranian wrote:
>
> I bet if you force the affinity of your perf record to be on
> a CPU other than CPU0, you will not get the crash.
>
> This is what I am seeing now. I appears on resume,
> CPU0 hotplug callbacks for perf_events are not invoked
> leaving D
On Fri, Mar 15, 2013 at 6:26 AM, Stephane Eranian wrote:
>
> This patch fixes a kernel crash when using precise sampling (PEBS)
> after a suspend/resume.
Yup, works. Applied.
Can we please get rid of the crazy CPU notifier crap from the perf
code, and do this like we do most other wrmsr's etc? D
On Thu, Mar 14, 2013 at 10:09 PM, J. R. Okajima wrote:
>
> "no inodes at all"?
> Are you assuming the implementation in dcache only (with a new d_type
> flag)? And it is up to the real fs (layer or branch) whether it consumes
> inode or not?
Yes. That would be lovely. And trivial for most filesys
On Sat, Mar 16, 2013 at 9:11 AM, Parag Warudkar wrote:
>
> This seems to trigger a WARN_ON during suspend/resume.
Ugh, yes. It's practically harmless, but it's ugly and technically
wrong (we're using wrmsr_on_cpu() on our current cpu, but in a context
where using it on anything else would be horr
On Tue, Aug 28, 2012 at 9:09 AM, Yinghai Lu wrote:
>
> please check update one. -v7
Ugh. Ok, looking closer at this, I think I agree with Bjorn. This is too ugly.
The whole "reduce size/needed_size by 1" double loop is O(n**2). And
it does ugly "insert fake resource to check, and then remove it"
On Tue, Aug 28, 2012 at 10:05 AM, Linus Torvalds
wrote:
>
> Ugh. Ok, looking closer at this,
Btw, looking at that code, I also found what looks like a potential
locking bug in allocate_resource().
The code does
if (new->parent)
.. reallocate ..
to check whether a res
On Thu, Aug 30, 2012 at 9:05 PM, Andreas Bombe wrote:
>
> With that somewhat easy test I bisected it down to 4e8b14526 "time:
> Improve sanity checking of timekeeping inputs". The latest Linus git
> (155e36d40) with a revert of the bisected commit does not show the
> problem.
Ok, I guess we need
On Fri, Aug 31, 2012 at 10:41 AM, Andreas Bombe wrote:
>
> It triggers on ((unsigned long long)ts->tv_sec >= KTIME_SEC_MAX).
> Looking at some straces (I could have thought of that earlier…) X does
> in fact call select with unreasonable timeouts:
>
> | 17:46:55 select(256, [1 3 6 9 10 11 18 19 20
y for empty flushes
Lee Jones (2):
ARM: ux500: Fix merge error, no matching driver name for 'snd_soc_u8500'
ARM: ux500: Ensure probing of Audio devices when Device Tree is enabled
Linus Torvalds (1):
Linux 3.6-rc4
Liu Bo (2):
Btrfs: fix a dio write regression
On Wed, Sep 12, 2012 at 11:34 AM, James Morris wrote:
>
> - if (!err && len == hlen)
> - err = memcmp(out2, h, hlen);
> + if (err || len != hlen) {
> + err = -EINVAL;
> + goto err;
> + }
> +
> + err = memcmp(out2, h, hlen);
>
> err
On Wed, Sep 12, 2012 at 6:22 PM, Kasatkin, Dmitry
wrote:
>
> But I will re-send updated patch in a moment.
Ok, I took that updated patch instead of the pull request, since I
liked that much more, and hadn't actually pushed out the pull yet.
Linus
--
To unsubscribe from this list: send
On Thu, Sep 13, 2012 at 7:43 PM, Takashi Iwai wrote:
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git for-linus
*PLEASE* don't do this.
You point to a branch, but then the pull request clearly implies there
is a tag with extra informat
On Thu, Sep 13, 2012 at 11:23 PM, tip-bot for Jan Beulich
wrote:
>
> x86: Prefer TZCNT over BFS
This patch is insane.
> For the moment, only do this when the respective generic-CPU
> option is selected (as there are no specific-CPU options
> covering the CPUs supporting TZCNT), and don't do that
On Fri, Sep 14, 2012 at 2:27 PM, Borislav Petkov wrote:
>
> as Nikolay says below, we have a regression in 3.6 with pgbench's
> benchmark in postgresql.
>
> I was able to reproduce it on another box here and did a bisection run.
> It pointed to the commit below.
Ok. I guess we should just revert
On Fri, Sep 14, 2012 at 2:40 PM, Peter Zijlstra wrote:
>
> The problem the patch is trying to address is not having to scan an
> entire package for idle cores on every wakeup now that packages are
> getting stupid big.
No, it does something *else* too. That whole "left-right" logic to
(according
On Fri, Sep 14, 2012 at 2:56 PM, Peter Zijlstra wrote:
>
> Both things change semantics, not looking at the entire package is new
> too.
Well, the "idle_buddy" thing on its own could be considered to be
purely a caching thing.
Sure, it doesn't take tsk_cpus_allowed() into account while setting u
On Thu, 31 Jan 2008, Jaroslav Kysela wrote:
>
> Linus, please pull from [the linus branch at]:
>
> master.kernel.org:/pub/scm/linux/kernel/git/perex/alsa.git linus
Hmm. This has a number of commits that have a questionable sign-off
history (I complained about the same thing for the networki
On Thu, 31 Jan 2008, Matthew Wilcox wrote:
>
> To allow tasks to be interrupted by fatal signals, we introduce a new
> TASK_* bit; TASK_WAKEKILL. We also add a predicate fatal_signal_pending;
> the counterpart of signal_pending(). Then we add killable versions
> of lock_page(), mutex_lock(), s
On Thu, 31 Jan 2008, Robert Hancock wrote:
>
> I think so. There was one objection that it introduced a dependency on pnpacpi
> loading after PCI bus enumeration, though.
>
> Linus also suggested that pnpacpi could be marking the resources as "present
> but unused" so that drivers can request t
On Thu, 31 Jan 2008, Trond Myklebust wrote:
>
> Hmm... The current code won't compile as a module. We're at least going
> to require something like the attached patch.
Ahh, ok, I obviously only tested compiling it in.
No need to make that one-liner function be a GPL-only export, it's not
like
On Sat, 2 Feb 2008, Oliver Pinter (Pint?r Oliv?r) wrote:
>
> Linus it's go or drop it?
I should merge it, I was just a bit bummed that I think the right solution
is to switch the bitfield meaning around. But the patch is certainly not
wrong.
Linus
--
To unsubscribe from this
On Sat, 2 Feb 2008, Oliver Pinter (Pint?r Oliv?r) wrote:
>
> NOT IN MAINLINE
>
> Linus it's go or drop it?
I have no idea, because you've used some horrible and stupid attachment
format that I can't even read. Patches should be inline so that people can
see them and comment on them.
On Mon, 4 Feb 2008, James Bottomley wrote:
>
> The way a user space solution should work is to schedule mmapped I/O
> from the backing store and then send this mmapped region off for target
> I/O.
mmap'ing may avoid the copy, but the overhead of a mmap operation is
quite often much *bigger* th
On Mon, 4 Feb 2008, Bjorn Helgaas wrote:
>
> I think the problem here is that the PCI BAR is bigger and spans the
> region reported by ACPI:
Ok, then it doesn't help that it's not busy.
In that case, the only real fix is to simply do the ACPI reservations
*after* PCI probing. Which is what it
On Mon, 4 Feb 2008, Nicholas A. Bellinger wrote:
>
> While this does not have anything to do directly with the kernel vs.
> user discussion for target mode storage engine, the scaling and latency
> case is easy enough to make if we are talking about scaling TCP for 10
> Gb/sec storage fabrics
On Mon, 4 Feb 2008, Jeff Garzik wrote:
>
> For years I have been hoping that someone will invent a simple protocol (w/
> strong auth) that can transit ATA and SCSI commands and responses. Heck, it
> would be almost trivial if the kernel had a TLS/SSL implementation.
Why would you want authoriza
On Mon, 4 Feb 2008, Jeff Garzik wrote:
>
> Well, speaking as a complete nutter who just finished the bare bones of an
> NFSv4 userland server[1]... it depends on your approach.
You definitely are a complete nutter ;)
> If the userland server is the _only_ one accessing the data[2] -- i.e. the
On Mon, 4 Feb 2008, Matt Mackall wrote:
>
> But ATAoE is boring because it's not IP. Which means no routing,
> firewalls, tunnels, congestion control, etc.
The thing is, that's often an advantage. Not just for performance.
> NBD and iSCSI (for all its hideous growths) can take advantage of the
On Mon, 4 Feb 2008, Bjorn Helgaas wrote:
>
> I'm sure you're right, but I don't understand why yet. Here's what
> I think is happening; please correct me where I'm going wrong:
>
> 1) enumerate PNP & ACPI devices
> 2) initialize PNP & ACPI drivers
> 2a) register ACPI PCI root bridge d
On Mon, 4 Feb 2008, J. Bruce Fields wrote:
>
> I'd assumed the move was primarily because of the difficulty of getting
> correct semantics on a shared filesystem
.. not even shared. It was hard to get correct semantics full stop.
Which is a traditional problem. The thing is, the kernel always
On Mon, 4 Feb 2008, Jeff Garzik wrote:
>
> Both of these are easily handled if the server is 100% in charge of managing
> the filesystem _metadata_ and data. That's what I meant by complete control.
>
> i.e. it not ext3 or reiserfs or vfat, its a block device or 1000GB file
> managed by a user
On Tue, 5 Feb 2008, Maxim Levitsky wrote:
>
> The x86 tree was merged several times, but I don't see kgdb included in
> latest mainline -git.
>
> So just one question, will it be included or no?
I won't even consider pulling it unless it's offered as a separate tree,
not mixed up with other
101 - 200 of 13532 matches
Mail list logo
