Note that in the meantime, I've also applied (through Andrew) the
patch that reverts commit c654345924f7 (see commit 82b212f40059
'Revert "mm: remove __GFP_NO_KSWAPD"').
I wonder if that revert may be bogus, and a result of this same issue.
Maybe that revert should be reverted, and replaced with y
On Tue, Nov 27, 2012 at 2:26 PM, Johannes Weiner wrote:
> On Tue, Nov 27, 2012 at 05:02:36PM -0500, Rik van Riel wrote:
>>
>> Kswapd going crazy is certainly a large part of the problem.
>>
>> However, that leaves the issue of page_alloc.c waking up
>> kswapd when the system is not actually low on
On Tue, Nov 27, 2012 at 3:28 PM, Stephen Rothwell wrote:
>
> If that is what happened, it may be worth always using the --no-ff flag
> to git merge/pull to make sure that the top commit on your tree always
> has you as the committer (and maybe SOB).
>
> Linus, does that make sense in general for m
Adding more people (and the acpi list) to this report.
I'm seeing *very* few changes to the core suspend/resume path in 3.7,
and while there are some acpia updates, they seem to be pretty mild
too.
I think the acpi_os_wait_semaphore thing is a red herring - that's
just stale on the stack.
Do you
On Wed, Nov 28, 2012 at 8:22 AM, Kay Sievers wrote:
> On Wed, Nov 28, 2012 at 2:33 PM, Michael Kerrisk
> wrote:
>
>> On a 2.6.31 system, immediately after SYSLOG_ACTION_READ_CLEAR, a
>> SYSLOG_ACTION_SIZE_UNREAD returns 0.
>
> Hmm, sounds like the right thing to do.
Right.
And that's the *OLD*
On Wed, Nov 28, 2012 at 8:21 AM, Zdenek Kabelac wrote:
>
> I've opened https://bugzilla.kernel.org/show_bug.cgi?id=51071
> and attached picture there which is all I have.
>
> I'll try to decode exact code line.
Uhhuh. It's missing much of the relevant parts of the code line, in
particular the ac
On Wed, Nov 28, 2012 at 9:27 AM, Zdenek Kabelac wrote:
>
> I've attached bigger disasfun script output to BZ 51071.
> https://bugzilla.kernel.org/show_bug.cgi?id=51071#c1
>
>
> if (ACPI_GET_DESCRIPTOR_TYPE(prefix_node) !=
> 00a1 cmpb $0xf,0x8(%rbx)
> 00a5 je 0
No, this is crap.
We don't introduce random hooks like this just because the block layer
has shit-for-brains and cannot be bothered to do things right.
The fact is, the whole locking in the block layer open routine is
total and utter crap. It doesn't lock the right thing, even with your
change *a
On Wed, Nov 28, 2012 at 11:43 AM, Al Viro wrote:
> Have a
> private vm_operations - a copy of generic_file_vm_ops with ->open()/->close()
> added to it.
That sounds more reasonable.
However, I suspect the *most* reasonable thing to do is to just remove
the whole damn thing. W
On Wed, Nov 28, 2012 at 11:50 AM, Mikulas Patocka wrote:
>
> mmap_region() doesn't care about the block size. But a lot of
> page-in/page-out code does.
That seems a bogus argument.
mmap() is in *no* way special. The exact same thing happens for
regular read/write. Yet somehow the mmap code is s
On Wed, Nov 28, 2012 at 12:03 PM, Linus Torvalds
wrote:
>
> mmap() is in *no* way special. The exact same thing happens for
> regular read/write. Yet somehow the mmap code is special-cased, while
> the normal read-write code is not.
I just double-checked, because it's been a
On Wed, Nov 28, 2012 at 12:13 PM, Linus Torvalds
wrote:
>
> I dunno. Maybe there is some fundamental reason why the above is
> broken, but it seems to be a much simpler approach. Sure, you need to
> guarantee that the people who get the write-lock cannot possibly cause
> IO while
[ Hmm. For some reason this seems to have never gone out, and was in
my drafts folder. If you get it twice, my bad ]
On Thu, Nov 22, 2012 at 12:57 AM, Dave Airlie wrote:
>
> Doh!, yes I picked wrong place to generate report from, okay here is
> one corresponding to what you saw,
You should never
On Wed, Nov 28, 2012 at 12:32 PM, Linus Torvalds
wrote:
>
> Here is a *COMPLETELY* untested patch. Caveat emptor. It will probably
> do unspeakable things to your family and pets.
Btw, *if* this approach works, I suspect we could just switch the
bd_block_size_semaphore semaphore to be
On Wed, Nov 28, 2012 at 1:29 PM, Mikulas Patocka wrote:
>
> The problem with this approach is that it is very easy to miss points
> where it is assumed that the block size doesn't change - and if you miss a
> point, it results in a hidden bug that has a little possibility of being
> found.
Umm. M
On Wed, Nov 28, 2012 at 2:52 PM, Linus Torvalds
wrote:
>
>> For example, __block_write_full_page and __block_write_begin do
>> if (!page_has_buffers(page)) { create_empty_buffers... }
>> and then they do
>> WARN_ON(bh->b_size != blocksize)
>>
[ Sorry, I was offline for a while driving kids around ]
On Wed, Nov 28, 2012 at 4:38 PM, Mikulas Patocka wrote:
>
> It can happen. Take your patch (the one that moves bd_block_size_semaphore
> into blkdev_readpage, blkdev_writepage and blkdev_write_begin).
Interesting. The code *has* the block
On Wed, Nov 28, 2012 at 6:04 PM, Linus Torvalds
wrote:
>
> Interesting. The code *has* the block size (it's in "bh->b_size"), but
> it actually then uses the inode blocksize instead, and verifies the
> two against each other. It could just have used the block size
On Wed, Nov 28, 2012 at 6:58 PM, Linus Torvalds
wrote:
>
> But the fact that the code wants to do things like
>
> block = (sector_t)page->index << (PAGE_CACHE_SHIFT - bbits);
>
> seriously seems to be the main thing that keeps us using
> 'inode->
On Wed, Nov 28, 2012 at 10:25 PM, Al Viro wrote:
>
> Umm... set_blocksize() is calling kill_bdev(), which does
> truncate_inode_pages(mapping, 0). What's going to happen to data in
> the dirty pages? IO in progress is not the only thing to worry about...
Hmm. Yes. I think it works by v
On Wed, Nov 28, 2012 at 10:30 PM, Al Viro wrote:
>
> Note that sync_blockdev() a few lines prior to that is good only if we
> have no other processes doing write(2) (or dirtying the mmapped pages,
> for that matter). The window isn't too wide, but...
So with Mikulas' patches, the write actually
On Wed, Nov 28, 2012 at 2:01 PM, Mikulas Patocka wrote:
>
> This sounds sensible. I'm sending this patch.
This looks much better.
I think I'll apply this for 3.7 (since it's too late to do anything
fancier), and then for 3.8 I will rip out all the locking entirely,
because looking at the fs/buff
On Thu, Nov 29, 2012 at 6:12 AM, Chris Mason wrote:
>
> Jumping in based on Linus original patch, which is doing something like
> this:
>
> set_blocksize() {
> block new calls to writepage, prepare/commit_write
> set the block size
> unblock
>
> < --- can race in he
On Thu, Nov 29, 2012 at 9:51 AM, Chris Mason wrote:
>
> The bigger question is do we have users that expect to be able to set
> the blocksize after mmaping the block device (no writes required)? I
> actually feel a little bad for taking up internet bandwidth asking, but
> it is a change in behavi
On Thu, Nov 29, 2012 at 10:23 AM, Mikulas Patocka wrote:
>
>
> If you remove that percpu rw lock, you also need to rewrite direct i/o
> code.
>
> In theory, block device direct i/o doesn't need buffer block size at all.
> But in practice, it shares a lot of code with filesystem direct i/o, it
> re
On Thu, Nov 29, 2012 at 9:19 AM, Linus Torvalds
wrote:
>
> I think I'll apply this for 3.7 (since it's too late to do anything
> fancier), and then for 3.8 I will rip out all the locking entirely,
> because looking at the fs/buffer.c patch I wrote up, it's all totally
On Thu, Nov 29, 2012 at 11:15 AM, Chris Mason wrote:
>
> The fs/buffer.c part makes sense during a quick read. But
> fs/direct-io.c plays with i_blkbits too. The semaphore was fixing real
> bugs there.
Ugh. I _hate_ direct-IO. What a mess. And yeah, it seems to be
incestuously playing games tha
On Thu, Nov 29, 2012 at 11:26 AM, Linus Torvalds
wrote:
>
> (I now realize that Mikulas was talking about this mess, while I
> thought he was talking about the AIO code which is largely sane).
Oh wow.
The direct-IO code really doesn't seem to care at all. I don't think
it n
On Thu, Nov 29, 2012 at 11:48 AM, Chris Mason wrote:
>
> blkdev_get_blocks (called during DIO) is also checking i_blkbits, but I
> really don't get why that isn't byte based instead. DIO is already
> doing the shift & mask game.
The blkdev_get_blocks() this is just sad.
The underlying data stru
On Thu, Nov 29, 2012 at 11:55 AM, Linus Torvalds
wrote:
>
> The blkdev_get_blocks() this is just sad.
>
> The underlying data structure is actually byte-based (it's
> "i_size_read(bdev->bd_inode"), but we convert it to a block-based
> number.
>
> Oops.
O
On Thu, Nov 29, 2012 at 11:48 AM, Chris Mason wrote:
>
> It was all a trick to get you to say the AIO code was sane.
It's only sane compared to the DIO code.
That said, I hate AIO much less these days that we've largely merged
the code with the regular IO. It's still a horrible interface, but at
On Thu, Nov 29, 2012 at 1:29 PM, Chris Mason wrote:
>
> Just reading the new blkdev_get_blocks, it looks like we're mixing
> shifts. In direct-io.c map_bh->b_size is how much we'd like to map, and
> it has no relation at all to the actual block size of the device. The
> interface is abusing b_si
On Thu, Nov 29, 2012 at 2:16 PM, Linus Torvalds
wrote:
>
> 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.
It turns out fs/ioctl.c does the same - it fills in the buffer head
On Thu, Nov 29, 2012 at 5:16 PM, Chris Mason wrote:
>
> I searched through filemap.c for the magic i_size check that would let
> us get away with ignoring i_blkbits in get_blocks, but its just not
> there. The whole fallback-to-buffered scheme seems to rely on
> get_blocks checking for i_size. I
ext3: Fix format string issues
Laxman Dewangan (1):
mfd: palmas: Provide irq flags through DT/platform data
Ley Foon Tan (1):
tty/serial: Add support for Altera serial port
Li Zefan (1):
s390: Fix a header dependencies related build error
Linus Torvalds (2):
perf,x86:
On Mon, Mar 18, 2013 at 7:22 AM, Arnd Bergmann wrote:
>
> are available in the git repository at:
>
> git+ssh://gitol...@ra.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
> tags/fixes
What the heck happened to your script?
Please use the public address so that others could look at it if
This is apparently still outstanding, and Mantas hadn't cc'd the
people involved with the commit itself.
Background: with UEFI, commit f9a37be0f02a ("x86: Use PCI setup data")
apparently results in a black screen for Mantas. The commit reverts
fairly easily (there's been a trivial change to the fu
On Tue, Mar 19, 2013 at 10:09 AM, Linus Torvalds
wrote:
>
> Doing things like blindly trusting the firmware data without even
> validating it is a really really bad idea. The commit actually looks
> seriously broken in other ways too, like blindly doing phys_to_virt()
> on that, an
On Tue, Mar 19, 2013 at 12:59 PM, Matthew Garrett wrote:
>
> Because it's the only way to get the PCI ROM in some cases, like on
> pretty much all Apples with Radeons. Only using it if we have no other
> options probably makes sense, though. Something like this (entirely
> untested)?
This looks r
On Wed, Mar 20, 2013 at 12:55 PM, Rik van Riel wrote:
>
> This series makes the sysv semaphore code more scalable,
> by reducing the time the semaphore lock is held, and making
> the locking more scalable for semaphore arrays with multiple
> semaphores.
The series looks sane to me, and I like how
On Wed, Mar 20, 2013 at 1:49 PM, Linus Torvalds
wrote:
>
> It *would* be lovely to see this run with the actual Swingbench
> numbers. The microbenchmark always looked much nicer. Do the
> additional multi-semaphore scalability patches on top of Davidlohr's
> patches help with
On Thu, Mar 21, 2013 at 7:22 AM, Paul E. McKenney
wrote:
> [Reposting with corrected subject line.]
>
> Hello, Ingo,
>
> This series contains a single commit that fixes a regression in
> hlist_entry_safe(). ..
You do realize that I already merged this a week ago directly? (Merge
commit f4846e52c
On Wed, Feb 6, 2013 at 10:28 PM, Ingo Molnar wrote:
>
> Linus, Andrew, what is your thinking about the patch and about
> the timing of the patch?
Not for 3.8. Queue it for 3.9, with possibly a stable tag with a big
comment "apply after much testing".
Linus
--
To unsubscribe from th
No.
You guys need to realize that I'm not talking crap like this this late.
This is not major bugfixes. I already looked away once just because
it's a new filesystem, but enough is enough. This is way way WAY too
late to start sendign "enhancements". Seriously.
Send them for the next merge windo
Pulled.
However, there's still the r8169 regressions (see the emails with the
subject "regression: NETDEV WATCHDOG: eth0 (r8169): transmit queue 0
timed out"). It's bisected, and a revert is reported to fix things.
It's not in this pull request. Comments?
Linus
On Sat, Feb 9, 2013
On Sat, Feb 9, 2013 at 1:55 AM, Ingo Molnar wrote:
>
> I'll remove it if Linus insists on it, but I think you guys are
> putting form before substance and utility :-(
No. Your pull requests are just illogical. I have yet to see a single
reason why it should be merged.
I *thought* "ease of use" c
tlwifi: Fix the usage of the wrong variable in usb.c
rtlwifi: Fix scheduling while atomic bug
Lars Ellenberg (1):
drbd: fix potential protocol error and resulting disconnect/reconnect
Linus Torvalds (1):
Linux 3.8-rc7
Liu Bo (1):
Btrfs: fix race between snapshot deletion and
On Sat, Feb 9, 2013 at 10:57 AM, Pekka Enberg wrote:
>
> And yes, you are absolutely correct that living in the kernel tree is
> suboptimal for the casual user. However, it's a trade-off to make
> tools/kvm *development* easier especially when you need to touch both
> kernel and userspace code.
Q
ell continue to work the way you do, and I don't mind -
but none of it argues for me merging it into the kernel. There's no
reason why kvmtool couldn't be external the way all the other
virtualization projects are.
Linus
On Feb 9, 2013 2:01 AM, "Pekka Enberg"
On Sun, Feb 10, 2013 at 6:39 AM, Pekka Enberg wrote:
>
> The main argument for merging into the main kernel repository has always been
> that (we think) it improves the kernel because significant amount of
> development is directly linked to kernel code (think KVM ARM port here, for
> example). Th
On Mon, Feb 11, 2013 at 4:26 AM, Ingo Molnar wrote:
>
> If you are asking whether it is critical for the kernel project
> to have tools/kvm/ integrated then it isn't. The kernel will
> live just fine without it, even if that decision is a mistake.
You go on to explain how this helps kvmtool, and
On Mon, Feb 11, 2013 at 5:18 AM, David Woodhouse wrote:
>
> That's complete nonsense. If you want to use pieces of the kernel
> infrastructure, then just *take* them. There are loads of projects which
> use the kernel config tools, for example. There's no need to be *in* the
> kernel repo.
Exactl
On Mon, Feb 11, 2013 at 9:58 AM, Ingo Molnar wrote:
>
> So basically Pekka optimistically thought it's an eventual 'tit
> for tat', a constant stream of benefits to the kernel, in the
> hope of finding a home in the upstream kernel which would
> further help both projects. The kernel wants to keep
On Mon, Feb 11, 2013 at 5:37 PM, tip-bot for H. Peter Anvin
wrote:
>
> However, we can declare a bitfield using sizeof(), which is legal
> because sizeof() is a constant expression. This quiets the warning,
> although the code generated isn't 100% identical from the baseline
> before 96477b4 x86-
On Mon, Feb 11, 2013 at 8:21 PM, H. Peter Anvin wrote:
> On 02/11/2013 07:33 PM, Linus Torvalds wrote:
>
>> Has anybody run this past any gcc developers? And if so, did they run
>> away screaming?
>
> I haven't no... H.J., any comments on this patch?
I'd be mos
On Mon, Feb 11, 2013 at 8:42 PM, Linus Torvalds
wrote:
>
> But I don't see anything fundamentally wrong with it. Certainly it
> looks much better than the disgusting and warning-prone
>
> unsigned long long __val_gu8
>
> thing.
Oh. I just realized. That was your _ba
On Tue, Feb 12, 2013 at 1:50 AM, Steven Whitehouse wrote:
>
> That doesn't seem right to me... DLM has not been experimental for a
> long time now. Why not just select CRC32 in addition to IP_SCTP ?
Hmm. IP_SCTP already does a "select libcrc32c". So why doesn't that
end up working?
On Tue, Feb 12, 2013 at 8:38 AM, H.J. Lu wrote:
>
> Can you do something similar to what we did in glibc:
No. Because we use macros to be type-independent (i e"get_user()"
works *regardless* of type), so casting to "uintptr_t" doesn't work.
It throws away the type information, and truncates 64-bi
On Mon, Feb 11, 2013 at 10:25 PM, Artem S. Tashkinov wrote:
> Hello Linus,
>
> I've already posted a bug report
> (https://bugzilla.kernel.org/show_bug.cgi?id=53551),
> a message to LKML
> (http://lkml.indiana.edu/hypermail/linux/kernel/1302.1/00837.html)
> and so far I've received zero response
On Tue, Feb 12, 2013 at 9:14 AM, H. Peter Anvin wrote:
>
> No, I think what he is talking about it this bit:
Ok, I agree that the bitfield code actually looks cleaner.
That said, maybe gcc has an easier time using a few odd builtins and
magic typeof's. But at least the bitfield trick looks half-
On Tue, Feb 12, 2013 at 9:35 AM, H. Peter Anvin wrote:
>
> On the other hand, it still uses two gcc extensions: long long bitfields and
> typeof.
>
> I'll see what kind of code we get with the macro.
At least one thing to look out for is the poor LLVM people who are
trying to make the kernel comp
On Tue, Feb 12, 2013 at 10:25 AM, H. Peter Anvin wrote:
> I just thought up this variant, I'm about to test it, but H.J., do you
> see any problems with it?
Looks good to me. And we already use __builtin_choose_expr(), so it's
"portable". And it should avoid all the potential issues with
bitfield
On Tue, Feb 12, 2013 at 10:29 AM, Artem S. Tashkinov wrote:
> Feb 12, 2013 11:30:20 PM, Linus Torvalds wrote:
>>
>>A few things to try to pinpoint:
>>
>> (a) Is it *only* write performance that suffers, or is it other
>>performance too? Networking (DMA? Perhap
On Tue, Feb 12, 2013 at 11:39 AM, Dave Jones wrote:
> My Thinkpad T430s suspend/resumes fine most of the time. But every so often
> (like one in ten times or so), as soon as I suspend, I get a black screen,
> and a blinking power button.
>
> (Note: Not the capslock lights like when we panic, this
So this looks clean, but I noticed something (that was true even of
the old 64-bit accesses)
On Tue, Feb 12, 2013 at 12:55 PM, tip-bot for H. Peter Anvin
wrote:
> + register __inttype(*(ptr)) __val_gu asm("%edx");\
How does gcc even alllow this?
On x86-32, you cannot put a
On Tue, Feb 12, 2013 at 3:19 PM, H. Peter Anvin wrote:
>
> Yes, but there doesn't seem to be any other way to do this. gcc won't
> even allow "=cd" even if we know the variable is 64 bits, even though
> "=A" is documented to be equivalent to "=da".
No, "=da" means value "in edx _or_ %eax". Not t
On Tue, Apr 2, 2013 at 9:08 AM, Sasha Levin wrote:
>
> If you guys are already looking at this, the conversions between size_t,
> long and int in the do_msgrcv/load_msg/alloc_msg code are a mess. You could
> trigger anything from:
Good catch.
Let's just change the "(long)bufsz < 0" into "bufsz >
On Tue, Apr 2, 2013 at 9:08 AM, Sasha Levin wrote:
>
> By just playing with the 'msgsz' parameter with MSG_COPY set.
Hmm. Looking closer, I suspect you're testing without commit
88b9e456b164 ("ipc: don't allocate a copy larger than max"). That
should limit the size passed in to prepare_copy -> lo
[ Fixed odd legacy subject line that has nothing to do with the actual bug ]
Hmm. Can you double-check and verify that reverting that commit makes
things work again for you?
Also, what's your distribution and setup? I'd like this to get
verified, just to see that it's not some timing-dependent th
On Thu, Apr 4, 2013 at 11:35 AM, Hugh Dickins wrote:
>
> find_vma() can be called by multiple threads with read lock
> held on mm->mmap_sem and any of them can update mm->mmap_cache.
> Prevent compiler from re-fetching mm->mmap_cache, because other
> readers could update it in the meantime:
Ack.
On Thu, Apr 4, 2013 at 12:01 PM, Hugh Dickins wrote:
>
> When Paul reminded us of it yesterday, I came to wonder if actually
> every use of ACCESS_ONCE in the read form should strictly be matched
> by ACCESS_ONCE whenever modifying the location.
>
> My uneducated guess is that strictly it ought to
On Fri, Apr 5, 2013 at 12:46 AM, Takashi Iwai wrote:
>
> please pull sound fixes for v3.9-rc6 from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git for-linus
Argh, Takashi, you're usually so reliable...
But you actually meant for me to pull the sound-3.9 tag, didn't you?
That
On Fri, Apr 5, 2013 at 9:27 AM, David Teigland wrote:
> On Fri, Apr 05, 2013 at 11:34:45AM +0100, Steven Whitehouse wrote:
>> Please consider pulling the following changes,
>
> There's some mixup here that should be cleared up first.
>
>> David Teigland (2):
>> GFS2: Fix unlock of fcntl lock
On Fri, Apr 5, 2013 at 11:15 AM, Mike Marciniszyn
wrote:
> Commit e2eed58 ("IB/qib: change QLogic to Intel") moved a firmware file
> potentially breaking the ABI.
Please send things like this generated with the "-M" flag so that you
can see it as a rename, instead of a huge add/del patch.
Sure,
On Mon, Jan 28, 2013 at 3:42 PM, Benjamin Herrenschmidt
wrote:
>
> Whenever you have a chance between two dives, you might want to consider
> pulling my merge branch to pickup a few fixes for 3.8 that have been
> accumulating for the last couple of weeks (I was myself travelling
> then on vacation
On Thu, Jan 31, 2013 at 9:19 AM, Russell King wrote:
>
> So... what you seem to be telling me is that 3.9 is going to be a
> release which issues lockdep complaints when the console blanks, and
> you think that's acceptable?
>
> Adding Linus and Andrew so they're aware of this issue...
Oh, we're
On Thu, Jan 31, 2013 at 11:13 AM, Russell King wrote:
>
> Which may or may not be a good thing depending how you look at it; it
> means that once your kernel blanks, you get a lockdep dump. At that
> point you lose lockdep checking for everything else because lockdep
> disables itself after the f
On Fri, Feb 1, 2013 at 8:48 AM, Thomas Gleixner wrote:
>> Methinks Tejun needed a cc on this lot ;)
>
> Not really.
I think we want as many people as possible cc'd on this. You may think
it's an obvious improvement, but maybe it's just because you now
understand the code because you wrote it your
On Fri, Feb 1, 2013 at 9:44 AM, Thomas Gleixner wrote:
>
> Just face it. The current hotplug maze has 100+ states which are
> completely undocumented. They are asymetric vs. startup and
> teardown. They just exists and work somehow aside of the occasional
> hard to decode hickup.
>
> Do you really
Fix MAX_STACK_TRACE_ENTRIES too low warning for ppc32
Liam Girdwood (2):
regulator: MAINTAINERS: update email address
ASoC: MAINTAINERS: Update email address.
Lingzhu Xiang (1):
efivarfs: Drop link count of the right inode
Linus Torvalds (1):
Linux 3.8-rc6
Linus Walleij
On Thu, Jan 24, 2013 at 4:42 PM, Dave Airlie wrote:
>
> These patches have been sailing around long enough, waiting for a maintainer
> to reappear, so I've decided enough is enough, lockdep is kinda useful to
> have.
Last this was tried, these patches failed miserably.
They caused instant lockd
On Thu, Jan 24, 2013 at 5:45 PM, Dave Airlie wrote:
>
> Okay I've just sent out another fbcon patch to fix the locking harder.
>
> There was a path going into set_con2fb_path if an fb driver was
> already registered, I just pushed the locking out further on anyone
> going in there.
>
> it boots on
On Thu, Jan 24, 2013 at 1:52 PM, Chris Mason wrote:
>
> Update on this, we've tracked down the crc errors and are doing final
> checks on the patches. Linus are you planning on taking this pull? If
> not I can just fold the new stuff into a bigger request.
If you have them basically ready, add
On Sat, Jan 26, 2013 at 7:18 AM, H. Peter Anvin wrote:
> On the CPUs Ling is testing on the downsides of -Os probably matter less, in
> particular since rep movsb works well.
>
> It is questionable as a generic default, though.
So being the person who really pushed for -Os to begin with (I think
On Fri, Jan 25, 2013 at 11:53 PM, Wang YanQing wrote:
> I get below warning every day with 3.7,
> one or two times per day.
>
> [ 2235.186027] WARNING: at
> /mnt/sda7/kernel/linux/arch/x86/kernel/apic/ipi.c:109
> default_send_IPI_mask_logical+0x2f/0xb8()
> [ 2235.186030] Hardware name: Aspire 47
On Fri, Feb 22, 2013 at 1:16 PM, Helge Deller wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
> parisc-3.9
In general, I'd love to also get a short human-readable explanation of
what the pull does for the merge message. As it is, I just made
something up.
On Sat, Feb 23, 2013 at 10:21 AM, Frederic Weisbecker
wrote:
>
> But tick_nohz_irq_exit() may trigger the timer softirq itself.
Suggestion: merge it with the whole softirq handler.
The softirq code *already* knows about the whole "oops, one softirq
may trigger another" issue, and has a loop - wi
On Wed, Feb 20, 2013 at 2:52 PM, Al Viro wrote:
> * a bunch of signal-related syscalls (both native and compat) unified.
Ok, in the meantime I had merged the parisc and powerpc trees, which
had their own fixes in this area: powerpc added the transactional
memory support for power8 (which impacted
On Wed, Feb 20, 2013 at 5:17 PM, Marcelo Tosatti wrote:
>
> Please pull from
>
> git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/kvm-3.9-1
>
> to receive the KVM updates for the 3.9 merge window [..]
Ok, particularly the s390 people should check me resolution of the
conflicts, since they inclu
On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie wrote:
>
> So up front, this has a massive merge conflict in
> drivers/gpu/drm/radeon/evergreen_cs.c I've fixed it up in drm-next-merged
> in the same tree, I fixed up some small ordering issues in my merge as
> well, however they aren't important if yo
On Mon, Feb 25, 2013 at 7:28 PM, Matthew Garrett wrote:
>
> You're happy advising Linux vendors that they don't need to worry about
> module signing because it's "not obvious" that Microsoft would actually
> enforce the security model they've spent significant money developing
> and advertising?
On Mon, Feb 25, 2013 at 7:42 PM, Matthew Garrett wrote:
>
> The user Microsoft care about isn't running Linux
How f*cking hard is it for you to understand?
Stop arguing about what MS wants. We do not care. We care bout the
*user*. You are continually missing the whole point of security, and
then
On Mon, Feb 25, 2013 at 7:48 PM, Matthew Garrett wrote:
>
> Our users want to be able to boot Linux. If Microsoft blacklist a
> distribution's bootloader, that user isn't going to be able to boot
> Linux any more. How does that benefit our users?
How does bringing up an unlikely and bogus scenari
On Mon, Feb 25, 2013 at 8:23 PM, Matthew Garrett wrote:
>
> If the user has explicitly enrolled a hash then they're stepping outside
> the trust model.
This is the kind of totally bogus crap that no sane person should ever
spout. Stop it.
If the user has explicitly enrolled a hash, then that sho
On Sat, Feb 23, 2013 at 6:49 PM, Yinghai Lu wrote:
>
> Please check if attached diff is right, and hope it could save Linus some
> time.
Hmm. I did things a bit differently, moving things around more in
drivers/acpi/internal.h.
Also, my *gut* feel is that the new _handle_hotplug_event_root()
fu
On Mon, Feb 25, 2013 at 7:17 PM, Rafael J. Wysocki wrote:
>
> I wonder if this went unnoticed or there's anything wrong with it or it just
> needs to wait for some more time?
Just going through things slowly. It's merged in my tree now.
Oh, and a request: _please_ don't use unknown TLA's like OP
On Tue, Feb 26, 2013 at 4:57 AM, Heiko Carstens
wrote:
>
> I was wrong. -EFAULT will be returned, however the vma will grow nevertheless.
> Which in turn will cause trouble.
Ok. We should fix that too.
There whole "access just past the end of the previous vma" should
never cause the stack above
On Tue, Feb 26, 2013 at 7:51 AM, Linus Torvalds
wrote:
>
> I think the problem is that we add the guard page *after* we do the
> normal "let's try to expand" logic.
>
> I'll take a look.
Ahh, no. The guard page logic happens later at the fault tim
On Mon, Feb 25, 2013 at 10:46 PM, Yinghai Lu wrote:
> On Mon, Feb 25, 2013 at 9:19 PM, Linus Torvalds
> wrote:
>>
>> Also, my *gut* feel is that the new _handle_hotplug_event_root()
>> function should do that whole dance with
>> acpi_scan_lock_acquire()/acpi_sca
On Tue, Feb 26, 2013 at 8:10 AM, Nishanth Menon wrote:
> On 16:55-20130226, Rafael J. Wysocki wrote:
>>
>> It says that in "Introduction", but it would be clearer if the title of the
>> doc was something like "Operating Performance Points (OPP) Library".
>> Nishanth?
>
> Yes indeed. Will the fol
1 - 100 of 13554 matches
Mail list logo
