Joe Perches | 17 Dec 21:58 2014

rfc: remove early_printk from a few arches? (blackfin, m68k, mips)

It seems like early_printk can be configured into
a few architectures but also appear not to be used.

$ git grep -w "early_printk"
arch/arm/kernel/Makefile:obj-$(CONFIG_EARLY_PRINTK)	+= early_printk.o
arch/arm/kernel/early_printk.c: *  linux/arch/arm/kernel/early_printk.c
arch/arm/mach-socfpga/socfpga.c:	early_printk("Early printk initialized\n");
arch/blackfin/kernel/Makefile:obj-$(CONFIG_EARLY_PRINTK)           += early_printk.o
arch/blackfin/kernel/bfin_dma.c:#include <asm/early_printk.h>
arch/blackfin/kernel/early_printk.c: * derived from arch/x86/kernel/early_printk.c
arch/blackfin/kernel/early_printk.c:#include <asm/early_printk.h>
arch/blackfin/kernel/setup.c:#include <asm/early_printk.h>
arch/blackfin/kernel/shadow_console.c:#include <asm/early_printk.h>
arch/blackfin/mm/init.c:#include <asm/early_printk.h>
arch/ia64/sn/kernel/setup.c:	 * IO on SN2 is done via SAL calls, early_printk won't work without this.
arch/m68k/kernel/Makefile:obj-$(CONFIG_EARLY_PRINTK)	+= early_printk.o
arch/microblaze/kernel/Makefile:obj-$(CONFIG_EARLY_PRINTK)	+= early_printk.o
arch/microblaze/kernel/cpu/cpuinfo-pvr-full.c:	early_printk("ERROR: Microblaze " x "-different
for PVR and DTS\n");
arch/microblaze/kernel/cpu/cpuinfo-static.c:	early_printk("ERROR: Microblaze " x "-different
for kernel and DTS\n");
arch/microblaze/kernel/setup.c:/* initialize device tree for usage in early_printk */
arch/mips/ath25/Makefile:obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
arch/mips/ath79/Makefile:obj-$(CONFIG_EARLY_PRINTK)		+= early_printk.o
arch/mips/bcm63xx/Makefile:obj-$(CONFIG_EARLY_PRINTK)	+= early_printk.o
arch/mips/include/asm/mach-lantiq/falcon/lantiq_soc.h: * during early_printk no ioremap possible
at this early stage
arch/mips/include/asm/mach-lantiq/xway/lantiq_soc.h: * during early_printk no ioremap is possible
arch/mips/kernel/Makefile:obj-$(CONFIG_EARLY_PRINTK)	+= early_printk.o
arch/mips/lantiq/Makefile:obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
(Continue reading)

Michael S. Tsirkin | 14 Dec 17:51 2014
Picon

[PATCH 00/18] uaccess: fix sparse warning on get_user for bitwise types

At the moment, if p and x are both tagged as bitwise types,
get_user(x, p) produces a sparse warning on many architectures.
This is because *p on these architectures is loaded into long
(typically using asm), then cast back to typeof(*p).

When typeof(*p) is a bitwise type (which is uncommon), such a cast needs
__force, otherwise sparse produces a warning.

Some architectures already have the __force tag, add it
where it's missing.

Specificlly, vhost wants to read bitwise types from userspace using get_user.
At the moment this triggers sparse errors, since the value is passed through an
integer.

For now, I worked around this by converting vhost code to access_ok +
__get_user, but that's not robust, I'd like to switch to get_user for 3.19.

I tested this on x86 only so far. Since it's just adding __force, should be
trivially safe everywhere?

Please review, and consider for 3.19.

Who can merge this? Arnd?

Michael S. Tsirkin (18):
  x86/uaccess: fix sparse errors
  alpha/uaccess: fix sparse errors
  arm64/uaccess: fix sparse errors
  avr32/uaccess: fix sparse errors
(Continue reading)

luv2charitys | 14 Dec 03:03 2014
Picon

charity message

Hello,this is Mr Paul N,i sent you an email on charity work but i am yet
to hear fom you,do reply with this code CHA-2015 to my email address
paulcharity <at> qq.com  i Look forward to hearing from you this time,God
bless  Brother Paul 
Arnd Bergmann | 9 Dec 23:01 2014
Picon

[GIT PULL] asm-generic: asm/io.h rewrite

The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1:

  Linux 3.18-rc1 (2014-10-19 18:08:38 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git tags/asm-generic-for-linus

for you to fetch changes up to cb61f6769b8836081940ba26249f1b756400c7df:

  ARM64: use GENERIC_PCI_IOMAP (2014-11-19 14:09:07 +0100)

----------------------------------------------------------------
asm-generic: asm/io.h rewrite

While there normally is no reason to have a pull request for asm-generic
but have all changes get merged through whichever tree needs them, I do
have a series for 3.19. There are two sets of patches that change
significant portions of asm/io.h, and this branch contains both in order
to resolve the conflicts:

- Will Deacon has done a set of patches to ensure that all architectures
  define {read,write}{b,w,l,q}_relaxed() functions or get them by
  including asm-generic/io.h. These functions are commonly used on ARM
  specific drivers to avoid expensive L2 cache synchronization implied by
  the normal {read,write}{b,w,l,q}, but we need to define them on all
  architectures in order to share the drivers across architectures and
  to enable CONFIG_COMPILE_TEST configurations for them

- Thierry Reding has done an unrelated set of patches that extends
(Continue reading)

christain147 | 8 Dec 15:05 2014
Picon

Re

Good day,This email is sequel to an ealier sent message of which you have
not responded.I have a personal charity project which I will want you to
execute on my behalf.Please kindly get back to me with this code
MHR/3910/2014 .You can reach me on mrsalimqadri <at> gmail.com .

Thank you

Salim Qadri
George Spelvin | 5 Dec 22:38 2014

Re: [PATCH 1/9] kernel: Provide READ_ONCE and ASSIGN_ONCE

> Of prefer it to match the put_user model, which is (val, ptr). But as long
> as there is your safety (and the whole point of the macro is that it
> figures out the type from the pointer), I guess it doesn't matter too much
> in practice.
> 
> I think my original suggestion also wrote it in lower case, since it
> actually works like a function (well, template, whatever). Again kind of
> like the user copy "functions".
> 
> But I don't care *that* strongly.

That's an excellent point.  But it means that Christian, you're free to
do whatever seems good to you.

I'm not rabid about it, either; I just figure that now is a good time
to think carefully about it.

Personally, after running through some different names that work
with (src,dst) order I'd try the pairs:

	READ_ONCE(var) / WRITE_ONCE(value,var)
or
	LOAD_ONCE(var) / STORE_ONCE(value,var)

Of the two, I think I prefer the latter, because that's what the
operations are called at the hardware level, so it's most evocative of
the actual semantics.  "Assignment" is a higher-level concept.

But as I said, whatever you think best.  I'd just like to advocate for
some actual thinking, because it's going to be all over the kernel and
(Continue reading)

David Hildenbrand | 5 Dec 12:18 2014
Picon

[PATCH v1 0/5] Reenable might_sleep() checks for might_fault()

I recently discovered that might_fault() doesn't call might_sleep() anymore.
Therefore bugs like:
	spin_lock(&lock);
	rc = copy_to_user(...);
	spin_unlock(&lock);
would not be detected with CONFIG_DEBUG_ATOMIC_SLEEP. The code was changed to
disable false positives for code like:
	pagefault_disable();
	rc = copy_to_user(...);
	pagefault_enable();

Until now, pagefault_disable() and pagefault_enable() simply modified the
preempt count, therefore telling the pagefault handler that the context is
atomic and sleeping is disallowed.

In order to reenable might_sleep() checks for the correct path, we need a way to
detect whether we run in a pagefault_disable() context.

This series therefore introduces a separate pagefault_count and uses it to count
the levels of pagefault_disable() per thread. might_sleep() checks are
reactivated for the !pagefault_disable() path.

So this should now work:
	spin_lock(&lock); /* also if left away */
	pagefault_disable()
	rc = copy_to_user(...);
	pagefault_enable();
	spin_unlock(&lock);
And this should report a warning again:
	spin_lock(&lock);
(Continue reading)

Paul E. McKenney | 4 Dec 08:02 2014
Picon

Re: [PATCH RFC] locking: Add volatile to arch_spinlock_t structures

On Wed, Dec 03, 2014 at 10:40:45PM -0800, Linus Torvalds wrote:
> On Dec 3, 2014 10:31 PM, "Linus Torvalds" <torvalds <at> linux-foundation.org>
> wrote:
> >
> > So no, no, no. C got this wrong. Volatile data structures are a
> fundamental mistake and a bug.
> 
> BTW, I'm not at all interested in language lawyering and people who say
> "but but we can do x". A compiler that modifies adjacent fields because the
> standard leaves is open is a crap compiler, and we won't use it, or disable
> the broken optimization. It is wrong from a concurrency standpoint anyway,
> and adding broken volatiles is just making things worse.

Understood, for example, adjacent fields protected by different locks
as one example, where adjacent-field overwriting completely breaks even
very conservatively designed code.  Should be entertaining!  ;-)

							Thanx, Paul

Paul E. McKenney | 4 Dec 07:57 2014
Picon

Re: [PATCH RFC] locking: Add volatile to arch_spinlock_t structures

One point of the patch is "one more thing to watch for" in generated code,
namely temporary clobbering of synchronization variables, locks included,
due to overzealous optimization.  If this happens to the kernel, I guess
that the other quick workaround is to add alignment directives or padding.
(And yes, I have seen reports of non-kernel examples where gcc actually
does this sort of thing.)

But I don't feel strongly about this patch, not yet anyway, so will set
it aside for the time being.

							Thanx, Paul

On Wed, Dec 03, 2014 at 10:31:06PM -0800, Linus Torvalds wrote:
> NAK. Volatile on data structures (as opposed to in code) is a disease. This
> is wrong.
> 
> We very much pass spinlock values around. They aren't volatile. The only
> thing volatile is when you load the value from the lock itself. See for
> example the stuff we do when we load a reflock from memory. Once we've
> loaded the value into registers it's no longer volatile, and putting
> violators into the data structures is actively *wrong*.
> 
> So no, no, no. C got this wrong. Volatile data structures are a fundamental
> mistake and a bug. The only good volatile is in an access (ie like
> ACCESS_ONCE() and anything else is making things worse.
> 
> We're not catering to crazy compiler people that can't understand that
> fact. I'm not even seeing the point of your patch, since it seems to be
> entirely about "let's make excuses for crap compilers"
> 
(Continue reading)

Paul E. McKenney | 4 Dec 07:20 2014
Picon

[PATCH RFC] locking: Add volatile to arch_spinlock_t structures

More concern about compilers...

Most architectures mark the fields in their arch_spinlock_t structures
as volatile, which forces the compiler to respect the integrity of
those fields.  Without volatile markings, the compiler is within its
rights to overwrite these fields, for example, by using a wide store
to update an adjacent field as long as it fixes them up later.  This
sort of thing could come as a rather nasty surprise to any task attempting
to concurrently acquire that lock.

For example, on x86 for smallish NR_CPUS, arch_spinlock_t is 16 bits wide.
If there were three adjacent 16-bit fields in the structure containing
the arch_spinlock_t, a compiler might reasonably use 64-bit accesses
for those three fields.  After a 64-bit load, the arch_spinlock_t's
value would be available in a register, so that the compiler might use
a 64-bit store followed by a 16-bit fixup store to update the three
adjacent 16-bit fields.

This commit therefore adds volatile to the arch_spinlock_t and
arch_rwlock_t fields that don't already have them.

Signed-off-by: Paul E. McKenney <paulmck <at> linux.vnet.ibm.com>
Cc: linux-arch <at> vger.kernel.org
Cc: Dmitry Vyukov <dvyukov <at> google.com>
Cc: Davidlohr Bueso <dave <at> stgolabs.net>
Cc: Ingo Molnar <mingo <at> kernel.org>
Cc: Peter Zijlstra <peterz <at> infradead.org>
Cc: Linus Torvalds <torvalds <at> linux-foundation.org>

diff --git a/arch/arm/include/asm/spinlock_types.h b/arch/arm/include/asm/spinlock_types.h
(Continue reading)

Quan Han | 1 Dec 14:02 2014

Re:


Hello,

Compliments of the day to you and I believe all is well. My name is Mr. Quan Han and I work in bank of china. I have
a transaction that I believe will be of mutual benefits to both of us. It involves an investment portfolio
worth(eight million,three hundred and seventy thousand USD) which I like to acquire with your help and
assistance. 
Yours sincerely,
Quan Han.

Gmane