gmane.linux.kernel.cross-arch

Re: Arch maintainers Ahoy!

James Bottomley — 2012-05-23T09:40:25

I think the sparc version will work for everybody (it will certainly
work on parisc).  The only thing that might be necessary is to add these
guards:


#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
       if (((long) dst | (long) src) & (sizeof(long) - 1))
               goto byte_at_a_time;
#endif

Dave, did you want to add it to lib/ ?

James

Re: Arch maintainers Ahoy!

Geert Uytterhoeven — 2012-05-23T08:02:13

Now everybody is rewriting this in plain C, perhaps it make sense to
have it in lib/, so I don't have to write anything myself?

Gr{oetje,eeting}s,

                        Lazy Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert< at >linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Arch maintainers Ahoy!

David Miller — 2012-05-23T05:46:27

Thanks for the reminder although I did still have this on my TODO
list somewhere :-)

I'll do something like the following (untested) for sparc.

--------------------
[PATCH] sparc: Add full proper error handling to strncpy_from_user().

Linus removed the end-of-address-space hackery from
fs/namei.c:do_getname() so we really have to validate these edge
conditions and cannot cheat any more (as x86 used to as well).

Move to a common C implementation like x86 did.  And if both
src and dst are sufficiently aligned we'll do word at a time
copies and checks as well.

Signed-off-by: David S. Miller <davem< at >davemloft.net>
---
 arch/sparc/include/asm/uaccess.h      |    3 +
 arch/sparc/include/asm/uaccess_32.h   |   10 ---
 arch/sparc/include/asm/uaccess_64.h   |    4 -
 arch/sparc/lib/Makefile               |    2 +-
 arch/sparc/lib/ksyms.c                |    3 -
 arch/sparc/lib/strncpy_from_user_32.S |   47 ------------
 arch/sparc/lib/strncpy_from_user_64.S |  133 ---------------------------------
 arch/sparc/li

Re: [git pull] signals, the first series

Stephen Rothwell — 2012-05-23T05:14:05

Hi Al,

On Tue, 22 May 2012 18:06:35 +1000 Stephen Rothwell <sfr< at >canb.auug.org.au> wrote:

OK, it seem that most of this has been in Andrew's tree for a while,
sorry about that.

[git pull] signals, the first series

Al Viro — 2012-05-22T04:35:25

This is just the first part of the queue (about a half of it);
assorted fixes all over the place in signals' handling.  This one ends
with all sigsuspend() implementations switched to generic one
(->saved_sigmask-based), a bunch of assorted old buglets fixed and most
of the missing bits of NOTIFY_RESUME hookup in place (two more sit in
arm and um trees resp. and there's a couple of broken ones that need
obvious fixes - parisc and avr32 check TIF_NOTIFY_RESUME only on one of
two codepaths; that'll go in the next series).  Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal.git for-linus

Shortlog:
Al Viro (35):
      new helper: sigsuspend()
      parisc: resetting ->restart_block.fn needs to be done on rt_sigreturn()
      c6x: ->restart_block.fn needs to be reset on rt_sigreturn
      hexagon: ->restart_block.fn needs to be reset on rt_sigreturn
      microblaze: ->restart_block.fn needs to be reset on rt_sigreturn
      score: ->restart_block.fn needs to be reset on rt_sigreturn

Re: [patch 00/18] SMP: Boot and CPU hotplug refactoring - Part 1

Rusty Russell — 2012-05-22T00:53:47

Eliminate is probably too hard, but with park/unpark I can see it
getting less common.  Maybe few enough that we can simplify.


Parallel CPUs going offline/online is probably a bigger win.  Both for
suspend/resume and powersaving.


I thought you might be :)

I'd love to review once you've got something.

Cheers,
Rusty.

Re: [PATCH 00/21] PCI: use busn_res to replace bus secondary/subordinate

Bjorn Helgaas — 2012-05-21T20:06:23


Oops, sorry, I squashed two patches into one (no point in two patches
that (1) add A and (2) clean up A), and I must have screwed up the
author then.  I fixed it in my tree.

I also changed the branch name to "for-3.6" to make it more obvious
that the changes there are targeted for the 3.6 merge window, not for
3.5.  After Linus pulls my current "next" branch into 3.5-rcX, I'll
move the for-3.6 stuff to the "next" branch as usual.


OK, just send your current patches to the list so everybody has a
chance to see them.

Bjorn

Arch maintainers Ahoy! (was Re: x86: faster strncpy_from_user())

Linus Torvalds — 2012-05-21T16:50:34

Ok, several weeks ago I sent out an email about the x86
strncpy_from_user() patch I did, and cc'd linux-arch because the
second stage might well affect other architectures.

Nobody reacted to it, and today that second stage was merged into
mainline, so I thought I'd re-do the notice. The relevant part of the
original explanation is appended, but I'll explain once more..

On x86, we *used* to be very lazy about strncpy_from_user(), and not
actually do the full proper error handling: the code was (for
historical reasons) using inline asms where it was very inconvenient
to actually check the proper end of the address space. And nobody had
really ever bothered to fix it up. As a result, the main user
(getname()) had its own special magic workarounds for this.

Until 3.4. We now do strncpy_from_user() properly, with all the
appropriate error cases of hitting the end of the user address space
etc handled.

And now that the 3.5 merge window is open, some of the first merging I
did was my own branches that had been

免交40万留学保证金，打造平民化的出国留学服务，爱尔兰名校等您来深造

平民化的出国留学服务 — 2012-05-21T13:09:13

您还在为家庭不够富裕，而不能让品学兼优的孩子出国深造而苦恼吗？
您还在为国内教育资源分配严重不均，而不能让自己的孩子获得理想的教育环境而发愁吗？

免交40万留学保证金，打造平民化的出国留学服务！
让工薪家庭孩子也可以一圆出国留学梦！

爱尔兰名校等您来深造！
想了解详情的请联系QQ: 2636882155   或者立即回复邮箱: 2636882155< at >qq.com
想了解详情的请联系QQ: 2636882155   或者立即回复邮箱: 2636882155< at >qq.com
想了解详情的请联系QQ: 2636882155   或者立即回复邮箱: 2636882155< at >qq.com
 
 
现诚招全国各地出国留学顾问。
零风险！高回报！共享朝阳般的教育产业大蛋糕！
请联系QQ: 2636882155
请联系QQ: 2636882155
请联系QQ: 2636882155

Re: [patch 00/18] SMP: Boot and CPU hotplug refactoring - Part 1

Rusty Russell — 2012-05-21T01:42:39

But there are two ways to do it.  One is to eliminate the need for
callbacks.  The other is to make a full dependency-based callback
system.

Let's try the first before the second.  I implemented a full dep-based
system for initcalls once, and it was not as nice as I'd hoped.


Not sure whether calling notifiers in parallel is going to be a big win:
they'll end up fighting over the cpu we're taking down.  But I could be
wrong.


That's a very nice idea.  Should be simpler for kthreads park/unpark
themselves, rather than having some notifier to kill them.

The original concept of stopping the machine for cpu hotplug and trying
not to effect any other kernel code has jumped the shark: I think we
need to look seriously at a complete rewrite where we don't use
stop_machine.

Cheers,
Rusty.

Re:

Mr. Peter Wong — 2012-05-20T22:20:39

Good-Day Friend,

I Mr. Peter Wong, I Need Your Assistance

Re: [parisc] double restarts on multiple signal arrivals

Carlos O'Donell — 2012-05-20T20:38:20

I'm running this through the ringer on my local system.

I'll send out an update when I'm done testing.

Cheers,
Carlos.

Re: [PATCH 08/10] Use __kernel_ulong_t in struct msqid64_ds

H. Peter Anvin — 2012-05-19T23:47:47

I'm not entirely sure I follow the above statement, as it seems
contradict itself.  Either way, I would agree, __BITS_PER_LONG should be
32 in x32 space and if there are places where that is wrong then we need
to fix them.

Fortunately x32 is littleendian, so no "littleendian bitmask on a
bigendian architecture" drain bamage...

-hpa

hexagon: signal bugs

Al Viro — 2012-05-19T21:09:11

1) spot the braino:
void do_trap0(struct pt_regs *regs)
...
        unsigned long syscallret = 0;
...
                if ((unsigned long) regs->syscall_nr >= __NR_syscalls) {
                        regs->r00 = -1;
                } else {
                        syscall = (syscall_fn)
                                  (sys_call_table[regs->syscall_nr]);
                        syscallret = syscall(regs->r00, regs->r01,
                                   regs->r02, regs->r03,
                                   regs->r04, regs->r05);
                }

                if (regs->syscall_nr != __NR_rt_sigreturn)
                        regs->r00 = syscallret;
IOW, the last if () should've been inside the "syscall_nr is not too high"
branch of the if () just above...

2) you do _not_ want syscall restarts to happen on sigreturn().
Whatever adjustment needed to be done had already been done back before
we'd saved the registers into sigcontext.  So doing
        regs->syscall_nr = __NR_rt_sigreturn;
in sys_rt_s

Re: [PATCH 08/10] Use __kernel_ulong_t in struct msqid64_ds

Al Viro — 2012-05-19T14:35:19


... and said __kernel_mode_t needs to die.  Along with all remaining
instances of mode_t kernel-side.

BTW, ncp_mount_data (i.e. ncp mount with version less than 4) needs to be
added to feature-removal-schedule.txt.  That'll bury one of the few places
where we have that crap in public headers.

And no, assorted struct stat do not need that thing at all.  They should
use explicit types, TYVM.

BTW, why do we have __kernel_uid32_t?  As an invitation for some architecture
to come up with 64bit "32bit UID" type?  What's wrong with __u32, or
at least moving the default (== only, fortunately) definitions to
linux/posix_types.h and making them unconditional?  Same for gid32_t
stuff, of course...

__kernel_nlink_t is also a bad idea (and an invitation to bugs in the kernel,
while we are at it).  BTW, now that I look at it...  ulong_t as default is
also wrong; there's no point making the internal nlink_t different on different
platforms.  Fortunately, that one is really easy to kill; mips/parisc/ppc
stat.h instance

Re: [PATCH 08/10] Use __kernel_ulong_t in struct msqid64_ds

Arnd Bergmann — 2012-05-19T07:56:30

I thought the point was that we could extend time_t to 64 bit at a later
point, which we already concluded isn't really happening for existing
architectures, or at least we will have bigger problems to worry about
if we do.
 

The real bug was to have a structure that is defined differently per
architecture. 


But when I did the generic header, the conclusion was that the situation
was already so much screwed up that any attempt to "fix" it would have
caused other problems:

* uclibc never incorporated the concept of per-architecture ipc header
  files, meaning it was already wrong on the few architectures that
  tried to do the right thing, but worked on those that copied from x86.
  Should we trust the next person to to a uclibc port to a new architecture
  to understand the situation fully and fix uclibc without breaking
  existing architectures?

* __kernel_time_t is not the only type that differs between 32 and 64
  bit platforms: the structures also include a __kernel_mode_t, which
  is different bet

Re: [parisc] double restarts on multiple signal arrivals

Al Viro — 2012-05-19T05:26:23


I think we might be able to cheat and pull off the following:
* stop restoring r28 on restarts.  Behaviour of syscall should not
depend on the value of r28 at the moment we enter it and it does clobber
r28 in all cases - that's where the return value goes to, after all.  And
the instruction we are restarting would better be a syscall.
* with that done, we can reuse ->orig_r28 for any purpose.  In
particular, we can use it as "no restarts allowed" flag.  Just have it set
to zero instead of r28 in linux_gateway_entry and hpux_gateway_page, then
in syscall_restart() and insert_restart_trampoline() check that
it's still 0, go away if it isn't and set it to 1 otherwise.  Set
it to 1 in sigreturn, to make it indifferent to what we might or might
not find in r28 stored in sigcontext (strictly speaking that's not needed,
but it's less brittle than relying on rather subtle properties of what
could end up in sigcontext and trampoline; the whole thing is a nice
example of how easily subtle things break and how long

Re: [parisc] double restarts on multiple signal arrivals

Carlos O'Donell — 2012-05-19T01:36:47

Thanks Al. This is description is a work of art, I wish all
reports looked like this. I'll go over this code tomorrow and
get back to you with my thoughts. I really appreciate the
thorough review.

Cheers,
Carlos.

Re: [parisc] double restarts on multiple signal arrivals

Al Viro — 2012-05-18T22:24:22


Sure.  Have e.g. read(2) on a pipe called when you happen to have -512 in
r28 and have two signals arrive at once while inside that read().  Both
with user handlers.  Both with SA_RESTART.

When we enter the kernel, we have pt_regs created on kernel stack and
filled with the values we had in registers.  Among other things, the
value of r28 is stored in regs->orig_r28.  Note that arguments and the
syscall number are all passed through other registers, so setting the
arguments for syscall did not overwrite the value we used to have in
r28.  It's still -512.

We find which C function to call (sys_read) and go there, with return
address set to syscall_exit.

sys_read() ends up calling pipe_read(), which finds pipe empty and goes
to sleep.  The signals arrive and pipe_read() is woken up.  It sees that
* signal_pending() is true
* nothing has been read yet
so it return -ERESTARSYS.  sys_read() returns what it got from pipe_read().

Now we are at syscall_exit.  We set r1 to pt_regs created on stack when
we ente

Re: [PATCH 08/10] Use __kernel_ulong_t in struct msqid64_ds

H. Peter Anvin — 2012-05-18T22:08:34

The *whole point* is to make the structure the same across modes, to
make the compat layer's job easier.


So you're saying because some architectures introduced a bug, we should
*CONTINUE* to introduce the same bug??  WTF??


x86 is doing it right.  Some bigendian architectures blindly copied what
x86 was doing without thinking.  That's a bug on their part, period.

-hpa

Re: [PATCH 08/10] Use __kernel_ulong_t in struct msqid64_ds

Arnd Bergmann — 2012-05-18T21:58:59

But why do you think it's wrong the way it is? I see the idea of putting
padding in varying places depending on the endianess as a failed experiment
and defining a structure that is always the same as the logical conclusion
from that, even if it's a bit silly to have any padding in it at all.

Being consistent seems more important here than following the intent
of whoever came up with the concept of the ipc64 data structures
and was consequently ignored by most people after him.

If we really wanted the data structures to be compatible between 32 and
64 bit mode, we'd have to use __u64 here but that would mean having to
change all bits of user code that already rely on the existing x86
compatible layout.

Arnd