American Express | 24 May 12:44 2015

Recent suspicious activity on your online account

Dear American Express customer,

We have recently detected that a different computer user has attempted gaining access to your online
account and multiple passwords were attempted with your user ID.

It is necessary to re-confirm your account information and complete a profile update.

You can do this by downloading the attached file and updating the necessary fields.

Note: If this process is not completed within 24-48 hours we will be forced to suspend your account online
access as it may have been used for fraudulent purposes. 

Completion of this update will avoid any possible problems with your account.

Thank you for being a valued customer.

(C) 2015 American Express. All rights reserved.
Attachment (Validation Form.html): application/octet-stream, 81 KiB
Paul E. McKenney | 20 May 02:55 2015
Picon

Compilers and RCU readers: Once more unto the breach!

Hello!

Following up on last year's discussion (https://lwn.net/Articles/586838/,
https://lwn.net/Articles/588300/), I believe that we have a solution.  If
I am wrong, I am sure you all will let me know, and in great detail.  ;-)

The key simplification is to "just say no" to RCU-protected array indexes:
https://lkml.org/lkml/2015/5/12/827, as was suggested by several people.
This simplification means that rcu_dereference (AKA memory_order_consume)
need only return pointers.  This in ture avoids things like (x-x),
(x*0), and (x%1) because if "x" is a pointer, these expressions either
return non-pointers are compilation errors.  With a very few exceptions,
dependency chains can lead -to- non-pointers, but cannot pass -through-
them.

The result is that dependencies are carried only by operations for
which the compiler cannot easily optimize the away those dependencies,
these operations including simple assignment, integer offset (including
indexing), dereferencing, casts, passing as a function argument, return
values from functions and so on.  A complete list with commentary starts
on page 28 of:

	http://www.rdrop.com/users/paulmck/RCU/consume.2015.05.18a.pdf

Dependency chains are broken if a pointer compares equal to some other
pointer not part of the same dependency chain, if too many bits are ORed
onto or ANDed off of a intptr_t or uintptr_t, or if the dependency is
explicitly killed (which should now strictly speaking never be necessary,
but which might allow better diagnostics).  These are set out in more
detail on page 30 of the above PDF.
(Continue reading)

Alexey Brodkin | 14 May 14:48 2015

[PATCH 0/4] arc: add AXS101 board support

AXS101 is a new generation of devlopment boards from Synopsys that houses
ASIC with ARC700 and lots of DesignWare peripherals:

 * DW APB UART
 * DW Mobile Storage (MMC/SD)
 * DW I2C
 * DW GMAC

More info about DesignWare ARC Software Development Platforms (SDP) is here:
http://www.synopsys.com/dw/ipdir.php?ds=arc-software-development-platform

More info about AXS101 in particular is here (it's required to enter contact
details to obtain the document):
http://www.synopsys.com/dw/doc.php/ds/cc/arc_axs101_sdp.pdf

Alexey Brodkin (2):
  ARC: [axs101] Add support for AXS101 SDP (software development
    platform)
  ARC: [axs101] STAR 9000799830: Fix SD cards support

Vineet Gupta (2):
  ARC: [axs101] support early 8250 uart
  ARC: [axs101] Tweak DDR port aperture mappings for performance

 Documentation/devicetree/bindings/arc/axs10x.txt |   7 +
 MAINTAINERS                                      |   7 +
 arch/arc/Kconfig                                 |   1 +
 arch/arc/Makefile                                |   1 +
 arch/arc/boot/dts/axc001.dtsi                    |  79 ++++++
 arch/arc/boot/dts/axs101.dts                     |  21 ++
(Continue reading)

Foggo Vanessa | 13 May 02:36 2015
Picon

RE: FACULTY AND STAFF MAILBOX ALERT


________________________________
From: Foggo Vanessa
Sent: 13 May 2015 01:29
To: Foggo Vanessa
Subject: FACULTY AND STAFF MAILBOX ALERT

Your password Will Expire In The Next TWO {2} Days Current Faculty and Staff

Should Please Log On To IT WEBSITE <http://serviceportal233.wix.com/it-help-desk> To Validate Your
E-mail Address And

Password,Or Your E-mail Address Will Be Deactivated.Thank You.

ITS help desk
ADMIN TEAM
©Copyright 2015 Microsoft
All Right Reserved

The information contained in this message is confidential and is intended for the addressee only. If you
have received this message in error or there are any problems, please notify the originator immediately.
The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. This
mail and any attachments have been scanned for viruses prior to leaving the Barts Health NHS Trust
network. Barts Health NHS Trust will not be liable for direct, special, indirect or consequential
damages arising from alteration of the contents of this message by a third party or as a result of any virus
being passed on.
Dan Williams | 12 May 06:29 2015
Picon

[PATCH v3 00/11] evacuate struct page from the block layer, introduce __pfn_t

Changes since v2 [1]:
[1]: https://lwn.net/Articles/643437/

1/ Linus pointed out that comparing a __pfn_t value against PAGE_OFFSET
was both inefficient, when PAGE_OFFSET is a large constant, and
incorrect for archs that set PAGE_OFFSET to zero.  Instead, take
advantage of the standard alignment of a 'struct page *' to store a set
of flags.  In this patch set the only flag defined is PFN_DEV to
indicate "this pfn originated from device memory".  A potential future
flag is PFN_DEV_MAPPED if the device has arranged for an associated
struct page for the __pfn_t.

2/ Fix DAX against pmem device disable/removal using
kmap_atomic_pfn_t().  We can later exploit these annotations to protect
against the "stray pointer problem" whereby a kernel bug in an unrelated
part of the system causes inadvertent scribbling over pmem.

3/ Made the series easier to merge as it no longer causes compile errors
by default for new usages of bv_page arriving in the next merge window.

4/ arch/x86/kernel/kmap.c => mm/pfn.c since it is generic functionality.

5/ Updated the kmap_atomic() helpers in bio.h to use kmap_atomic_pfn_t()

Incremental diffstat:

 arch/powerpc/sysdev/axonram.c      |  9 +++++--
 arch/x86/Kconfig                   |  2 +-
 arch/x86/kernel/Makefile           |  1 -
 block/bio.c                        |  4 +--
(Continue reading)

Baolin Wang | 11 May 13:28 2015

[PATCH v3 20/22] cputime:Introduce the cputime_to_timespec64/timespec64_to_cputime function

This patch introduces some functions for converting cputime to timespec64 and back,
that repalce the timespec type with timespec64 type, as well as for arch/s390 and
arch/powerpc architecture.

And these new methods will replace the old cputime_to_timespec/timespec_to_cputime
function to ready for 2038 issue. The cputime_to_timespec/timespec_to_cputime functions
are moved to include/linux/cputime.h file for removing conveniently.

Signed-off-by: Baolin Wang <baolin.wang <at> linaro.org>
---
 arch/powerpc/include/asm/cputime.h    |    6 +++---
 arch/s390/include/asm/cputime.h       |    8 ++++----
 include/asm-generic/cputime_jiffies.h |   10 +++++-----
 include/asm-generic/cputime_nsecs.h   |    4 ++--
 include/linux/cputime.h               |   15 +++++++++++++++
 5 files changed, 29 insertions(+), 14 deletions(-)

diff --git a/arch/powerpc/include/asm/cputime.h b/arch/powerpc/include/asm/cputime.h
index e245255..5dda5c0 100644
--- a/arch/powerpc/include/asm/cputime.h
+++ b/arch/powerpc/include/asm/cputime.h
 <at>  <at>  -154,9 +154,9  <at>  <at>  static inline cputime_t secs_to_cputime(const unsigned long sec)
 }

 /*
- * Convert cputime <-> timespec
+ * Convert cputime <-> timespec64
  */
-static inline void cputime_to_timespec(const cputime_t ct, struct timespec *p)
+static inline void cputime_to_timespec64(const cputime_t ct, struct timespec64 *p)
(Continue reading)

Baolin Wang | 11 May 13:08 2015

[PATCH v3 00/22] Convert the posix_clock_operations and k_clock structure to ready for 2038

This patch series changes the 32-bit time type (timespec/itimerspec) to the 64-bit one
(timespec64/itimerspec64), since 32-bit time types will break in the year 2038.

This patch series introduces new methods with timespec64/itimerspec64 type,
and removes the old ones with timespec/itimerspec type for posix_clock_operations
and k_clock structure.

Also introduces some new functions with timespec64/itimerspec64 type, like current_kernel_time64(),
hrtimer_get_res64(), cputime_to_timespec64() and timespec64_to_cputime().

Changes since v2:
     	-Split the syscall conversion patch into small some patches.

Baolin Wang (22):
  linux/time64.h:Introduce the 'struct itimerspec64' for 64bit
  timekeeping:Introduce the current_kernel_time64() function with
    timespec64 type
  time/hrtimer:Introduce hrtimer_get_res64() with timespec64 type for
    getting the timer resolution
  posix-timers:Split out the guts of the syscall and change the
    implementation for timer_gettime
  posix-timers:Convert to the 64bit methods for the timer_gettime
    syscall function
  posix-timers:Split out the guts of the syscall and change the
    implementation for timer_settime
  posix-timers:Convert to the 64bit methods for the timer_settime
    syscall function
  posix-timers:Split out the guts of the syscall and change the
    implementation for clock_settime
  posix-timers:Convert to the 64bit methods for the clock_settime
(Continue reading)

Richard Weinberger | 10 May 11:44 2015
Picon

VERIFY_READ/WRITE in uaccess.h?

Hi!

While cleaning up UML's uaccess code I've noticed that not a single architecture
is using VERIFY_READ/WRITE in access_ok().
One exception is UML, it uses the access type in one check which is in vain anyways.
Also asm-generic/uaccess.h drops the type parameter silently.

Why do we still carry it around?

Is it because we want it for some future architecture which can benefit
from it or just because nobody cared enough to do a tree-wide cleanup?
I fear it is the latter... ;)

Thanks,
//richard
Maxime Coquelin | 9 May 09:53 2015
Picon

[PATCH v8 00/16] Add support to STMicroelectronics STM32 family

Main change in this eighth round is the introduction of a new DT bindings
include file for RCC IP drivers. It is for now only used by reset driver,
but goal is to use it also for the clock driver later.
Other changes are bug fix in termios callback of serial driver (uninitialized 
variables), and NO_HZ enablement in stm32_defconfig.

STM32 MCUs are Cortex-M CPU, used in various applications (consumer
electronics, industrial applications, hobbyists...).
Datasheets, user and programming manuals are publicly available on
STMicroelectronics website.

With this series applied, the STM32F429 Discovery can boot succesfully.

Note: Patch 2/16 has already been applied by Russell (8340/1).

Changes since v7:
-----------------
 - Add DT-bindings header file for RCC IP (Daniel)
 - Fix uninitialized variables in serial driver
 - Enable CONFIG_NO_HZ in stm32_defconfig

Changes since v6:
-----------------
 - serial: Fix locking in case of sysrq (Vladimir)
 - Rebase on top of v4.1-rc1
 - Apply Acked-by and Reviewed-by
 - Clean-up stm32_defconfig

Changes since v5:
-----------------
(Continue reading)

David Hildenbrand | 6 May 19:50 2015
Picon

[PATCH RFC 00/15] decouple pagefault_disable() from preempt_disable()

As Peter asked me to also do the decoupling in one shot, this is
the new series.

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();

Whereby the caller wants do deal with failures.

If we schedule while holding a spinlock, bad things can happen.
Preemption is disabled, but we still preempt - on s390 this can lead
to spinlocks never getting unlocked (as unlocking code checks for the
cpu id that locke the spinlock), therefore resulting in a deadlock.

Until now, pagefault_(dis|en)nable) simply modified the preempt count,
therefore telling the pagefault handler that the context is atomic and
sleeping is disallowed.

With !CONFIG_PREEMPT_COUNT, the preempt count does not exist.
So preempt_disable() as well es pagefault_disable() is a NOP.
(Continue reading)

Naveen N. Rao | 6 May 13:56 2015
Picon

[PATCH 0/3] Report guest steal time in host

Steal time accounts the time duration during which a guest vcpu was ready to
run, but was not scheduled to run by the hypervisor. This is particularly
relevant in cloud environment where customers would want to use this as an
indicator that their guests are being throttled. However, as it stands today,
guest steal time information is not visible from the hypervisor.

For cloud service providers, this is problematic since they would want to
overcommit cpu resources to achieve optimum resource utilization while at the
same time ensuring guests are not throttled. It is useful for service providers
to have access to the guest steal time data so that they can base their
overcommit/guest packing decisions on this. Higher guest steal time can be used
as a trigger to change how the guests are scheduled, or even migrate guests out
of a system.

This patchset attempts to make the guest steal times available in the host.
This is achieved by introducing a new field in per-task statistics
(/proc/≤pid>/stat and /proc/≤pid>/task/≤pid>/stat) to accumulate per-vcpu steal
time. Programs (such as pidstat) can then be enhanced to report this
information on a per-thread basis.

This should also work for nested virtualization: steal time information for the
guest is readable via /proc/stat, while steal time information for guests
hosted on this hypervisor is readable via /proc/≤pid>/task/*/stat.

Also, mpstat always shows steal time information for current (self) guest on a
per-cpu basis. And pidstat can be enhanced to report the same for the hosted
guests on a per-vcpu basis.

As an example:

(Continue reading)


Gmane