Quantcast
Channel: lkml.org : Vaidyanathan Srinivasan
Viewing all 890 articles
Browse latest View live

Re: [git pull] drm fixes for v4.15-rc3

$
0
0
Linus Torvalds writes: (Summary) wrote:

[...]

that were missing them,
Oh Christ, couldn't they have just added the one-liner SPDX tags rather than doing that crazy "new 22 line boiler plate garbage to fifteen random Makefiles"?
fifteen random Makefiles"?
I pulled it, but let's try to reign in the crazy "lets add filler lines" behavior, ok?
lines" behavior, ok?
Alex, can you talk to the AMD lawyers and ask them about just putting the SPDX line instead?
the SPDX line instead?
Linus
Linus
Linus

Re: [GIT PULL for v4.15-rc3] media fixes

$
0
0
Linus Torvalds writes: (Summary) On Fri, Dec 8, 2017 at 7:56 AM, Mauro Carvalho Chehab <mchehab@osg.samsung.com> wrote:

[...]

changes - just comment changes at the source files; Guys, this was just pure garbage, and obviously noboduy actually looked at that shit-for-brains patch.
looked at that shit-for-brains patch.
There were several idiotic things like this:
There were several idiotic things like this:
  -/******************************
  +/*****************************

because part of it was apparently generated with some overly stupid
search-and-replace. That pointless
noise may now be hiding the real changes.

Re: x86/ldt: Prevent ldt inheritance on exec

$
0
0
Linus Torvalds writes: (Summary) That said, can't we separate this out into the copy_mm() phase only?
phase only?
We have "arch_dup_mmap()" that is called on fork() only, so that could do the LDT copy from the old mm, and the actual init_new_context would just zero it out.
just zero it out.
Then there wouldn't be any odd "check if this is an execve" because the copying would be done in the right place.
the copying would be done in the right place.
Hmm?
Hmm?
Linus
Linus
Linus

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

$
0
0
Linus Torvalds writes: (Summary)

[...]

me commit id, that would help.
The fix in there should be 5b06bbcfc2c6 ("x86/power: Fix some ordering bugs in __restore_processor_context()") so you can certainly see if it works before that (or just reverting it).
works before that (or just reverting it).
But there are also a few other x86 low-level things there, and that fix really looks very safe, so I'd almost expect something else to have triggered your problem. Linus
Linus
Linus

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

$
0
0
Linus Torvalds writes: (Summary) Aha.
Yeah, people do.
Yeah, people do.
Andy?
Andy?

[...]

...should take 10 seconds or so.
I'm told 0day does *some* suspend/resume testing, but I think it's pretty limited, partly because the kinds of machines it primarily works on don't really support suspend/resume at all. This came in from the x86 trees (and those do their own tests too, but probably not suspend/resume either), but it hit my tree fairly soon after going into the x86 -tip trees.
fairly soon after going into the x86 -tip trees.
Linus
Linus
Linus

Re: [PATCH tip/core/rcu 02/20] torture: Prepare scripting for shif ...

$
0
0
Linus Torvalds writes: (Summary) Things like that.
So I think that if people worry about leaking pointers, they should primarily go for:
primarily go for:
- just use %p and now get the hashed value
- just use %p and now get the hashed value
- if the hashed value is pointless, ask yourself whether the pointer itself is important. Maybe it should be removed?
- as a last option, if you really think the true pointer value is important, why is root so special, and maybe you should use %px and make sure you have proper sensible permissions.
make sure you have proper sensible permissions.
..and %pK just isn't really the answer in any of those cases.

Re: [PATCH] mm/slab: Do not hash pointers when debugging slab

$
0
0
Linus Torvalds writes: (Summary) wrote:

[...]

*dbg_userword(cachep, objp));
Is there actually any point to the %px at all?
Is there actually any point to the %px at all?
Why not remove it?

[...]

realobj, size);
and here, is the pointer actually interesting, or should we just give the offset to the allocation?
the offset to the allocation?
But if the pointer is interesting, then ack.
But if the pointer is interesting, then ack.
Linus
Linus
Linus

Re: [PATCH 1/1] futex: futex_wake_op, fix sign_extend32 sign bits

$
0
0
Linus Torvalds writes: (Summary) On Thu, Nov 30, 2017 at 6:35 AM, Jiri Slaby <jslaby@suse.cz> I'm applying this directly to my tree since I didn't see anybody else react to it, but the whole pattern worries me.
react to it, but the whole pattern worries me.
Also, clearly nobody actually uses the odder corners of futex ops anyway. Maybe we should deprecate them entirely?
Jiri, did you notice by testing, or what?
Jiri, did you notice by testing, or what?
Linus
Linus
Linus

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

$
0
0
Linus Torvalds writes: (Summary) And the comment does seem relevant for 32-bit too:
relevant for 32-bit too:

[...]

* and LDT, which happen in fix_processor_context(). You've moved down the 32-bit fix_processor_context() call to after the loadsegment() calls, which smells wrong.
after the loadsegment() calls, which smells wrong.
That said, this *all* smells wrong. Why is there a special fix_processor_context() function at all with different 32-bit and 64-bit behavior? There's no logic to what is done where.
Linus
Linus
Linus

Linux 4.15-rc3

$
0
0
Linus Torvalds writes: (Summary) Johnson (1): firmware: cleanup FIRMWARE_IN_KERNEL message Robin Murphy (1): iommu/vt-d: Fix scatterlist offset handling Roger He (5): drm/ttm: use NUM_PAGES_TO_ALLOC always drm/ttm: add page order in page pool drm/ttm: add set_pages_wb for handling page order more than zero drm/ttm: add page order support in ttm_pages_put drm/ttm: roundup the shrink request to prevent skip huge pool Roger Quadros (1): usb: gadget: core: Fix ->udc_set_speed() speed handling Rudolf Marek (1): x86/cpufeatures: Make X86_BUG_FXSAVE_LEAK detectable in CPUID on AMD Russell King (4): sfp: fix RX_LOS signal handling sfp: improve RX_LOS handling sfp: warn about modules requiring address change sequence phylink: ensure we take the link down when phylink_stop() is called Sakari Ailus (2): media: ov13858: Select V4L2_FWNODE media: imx274: Fix error handling, add MAINTAINERS entry Sara Sharon (3): iwlwifi: pcie: fix erroneous "Read fa

Re: [PATCH] Fix resume on x86-32 machines

$
0
0
Linus Torvalds writes: (Summary) I think we actually leave the user-space percpu segment in %gs (or the stack canary base), so that one we should actually save/restore, but I'm getting the feeling that we should just reset the other segment registers to known values on 32-bit.
registers to known values on 32-bit.
Also, why does the 32-bit code do
Also, why does the 32-bit code do
loadsegment(es, ctxt->es);
loadsegment(es, ctxt->es);
but the 64-bit code does
but the 64-bit code does
asm volatile ("movw %0, %%es" :: "r" (ctxt->es)); It has been written as some kind of "save and restore registers", but that's not what it really then does - or what it should do.
then does - or what it should do.
It should make sure to restore a sane kernel state, not some random register state.
register state.
And the 32-bit and 64-bit code really should strive to be at least _sanely_ different, not this randomly and insanely different mess.

Re: [PATCH] Fix resume on x86-32 machines

$
0
0
Linus Torvalds writes: (Summary) On Mon, Dec 11, 2017 at 10:41 AM, Andy Lutomirski <luto@amacapital.net> wrote:

[...]

do some trivial fix/revert and fix it for real next time around? I don't think we want some trivial fix/revert just to keep it working. This code is too fragile as-is, and I think that "make it work" is more than reverting. You did fix real issues on x86-64 with odd segment use, for example.
segment use, for example.
Linus
Linus
Linus

Re: [GIT PULL] SCSI fixes for 4.15-rc3

$
0
0
Linus Torvalds writes: (Summary) If you save a pointer in an integer "hostdata[0]" field, then you damn well do the proper casts or helper functions or something, you don't just ignore the compiler when it very reasonably warns about it.
very reasonably warns about it.
What the hell is going on? Or nobody cares about new build warnings?
nobody cares about new build warnings?
That is not acceptable.
That is not acceptable.
Linus
Linus
Linus

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

$
0
0
Linus Torvalds writes: (Summary) Looking a bit more at this, I think it should be solved by: - load the original read-write GDT early, along with the IDT. We have already saved it off in __save_processor_state(), and it may have already gotten loaded very early in at least some of the paths, but it definitely hasn't gotten reloaded in all the paths (think "suspend/resume testing" etc).
"suspend/resume testing" etc).
- add the LDT descriptor to the save area too, exactly like we already have IDT/GDT.
already have IDT/GDT.
Then, we can do "load_ldt()" early (along with IDT and GDT).

Re: [GIT PULL] SCSI fixes for 4.15-rc3

$
0
0
Linus Torvalds writes: (Summary) On Tue, Dec 12, 2017 at 9:22 AM, Martin K. wrote:

[...]

Arnd and Johannes fixed this up right away:
The commit you point to _is_ the probnlem. It does: struct bfad_im_port_s *im_port = shost->hostdata[0]; It's assigning a pointer (im_port), from an integer value ("hostdata[0]" is "unsigned long"). The code is garbage.
The code is garbage.
Linus
Linus
Linus

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

$
0
0
Linus Torvalds writes: (Summary) We only do the fault protection on 32-bit.
only do the fault protection on 32-bit.
In fact, we really should try to avoid taking faults here anyway, shouldn't we? Hmm.
Hmm.
Maybe we should load only the fixed kernel segments at this point, and then do all the loadsegment() of gs/fs in the later phase when we're all set up.
all set up.
THERE we can do the swapgs dance with interrupt tracing etc, because *there* we actually are fully set up. I guess that means reloading the FS/GS base MSR's,
FS/GS base MSR's,
Linus
Linus
Linus

Re: [patch 13/16] x86/ldt: Introduce LDT write fault handler

$
0
0
Linus Torvalds writes: (Summary) wrote:

[...]

ACCESS bit in the handler.
This really scares me.
This really scares me.
We use segments in some critical code in the kernel, like the whole percpu data etc. Also, I worry about crazy errata with TSS etc - this whole RO LDT thing also introduces lots of possible new fault points in microcode that nobody sane has ever done before, no?
that nobody sane has ever done before, no?

[...]

+ desc[entry].type |= 0x01;
This is also pretty disgusting.
This is also pretty disgusting.
Why isn't it just something like
Why isn't it just something like
desc = (void *)(address &

Re: [patch 11/16] x86/ldt: Force access bit for CS/SS

$
0
0
Linus Torvalds writes: (Summary) On Tue, Dec 12, 2017 at 9:32 AM, Thomas Gleixner <tglx@linutronix.de> wrote:

[...]

the IRET to userspace.
Ok, so the other patch made me nervous, this just makes me go "Hell no!". This is exactly the kind of "now we get traps in random microcode places that have never been tested" kind of thing that I was talking about.
about.
Why is the iret exception unrecoverable anyway? Linus
Linus
Linus

Re: [patch 13/16] x86/ldt: Introduce LDT write fault handler

$
0
0
Linus Torvalds writes: (Summary) On Tue, Dec 12, 2017 at 11:21 AM, Thomas Gleixner <tglx@linutronix.de> We end up loading the selector for %gs and %fs, and those selectors end up being connected with whatever user-mode has set up for them.
up for them.
We then set the FS/GS base pointer to a kernel-specific value, but that is _separately_ from the actual accessed bit that is in the selector.
selector.
So the kernel doesn't care, but the kernel definitely uses them. So the kernel doesn't care, but the kernel definitely uses them. Linus
Linus
Linus

Re: Linux 4.15-rc2: Regression in resume from ACPI S3

$
0
0
Linus Torvalds writes: (Summary) I'm not sure what's up.) I think your link is just bogus.
I think your link is just bogus.
https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/fixeshttps://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/fixes works.
works.
Anyway, the code looks much better to me.
Anyway, the code looks much better to me.
Whether it _works_ is another matter, of course.
Whether it _works_ is another matter, of course.
Linus
Linus
Linus
Viewing all 890 articles
Browse latest View live




Latest Images