Re: [GIT PULL] Detaching mounts on unlink for 3.15

[Al Viro]

On Thu, Apr 17, 2014 at 11:12:03PM +0100, Al Viro wrote:

> I'd probably turn mntput_no_expire() into something like
> static struct mount *__mntput(struct mount *m)
> that would return NULL if nothing needs to be killed and returned m
> if m really needs killing.  Leaving the caller to decide what to do
> with that puppy.  We have, as it is, exactly two callers - exit path
> in sys_umount() and mntput().  So we add two more functions:
> static void kill_mnt_async(struct mount *m)
> and
> static void kill_mnt_sync(struct mount *m)
> both being no-op on NULL.  Then in sys_umount() and mntput() we do
>   kill_mnt_async(__mntput(mnt));
> and in mntput_sync() - kill_mnt_sync(__mntput(mnt));
> For that matter, kill_mnt_sync() (basically, your variant with completions)
> can be folded into mntput_sync().

Actually, all kern_unmount() callers are doing that from fairly shallow
stack depth and all simple_release_fs() ones are dealing with rather
trivial ->kill_sb().  So mntput_sync() is an overkill; all we need is
if (mnt->mnt_flags & MNT_INTERNAL) {
cleanup_mnt(mnt);
return;
}

right in the end of mntput_no_expire().  OK, now I have something that
looks like a complete solution.  The last missing bit is to take all
filp_close() of acct->file to kernel thread, and have them done via
__fput_sync() there.  Then auto-close (done from cleanup_mnt()) will
consist of shutting down all affected acct and waiting for that kernel
thread to run through everything currently in its queue.  That'll take
care of waiting until acct(NULL) done by somebody else gets through closing
the file and through corresponding mntput().  And *those* mntput() also
can be synchronous - they are clones of the one we hadn't finished shutting
down yet, so both dput() and deactivate_super() will bugger off immediately.
So we just mark those instead-of-mnt_pin() clones as MNT_INTERNAL.  Voila.
After that ->mnt_pinned crap dies, acct auto-close ought to be race-free
and we get the actual fs shutdown guaranteed to be on shallow stack, without
extra context switches, etc. in the normal case.

Let's see if that survives testing...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bug in 3.15-rc1: Scheduling while atomic splats filling log - bisected to commit 27f6c57

[Larry Finger]

On 04/17/2014 02:16 PM, Larry Finger wrote:

On kernel 3.15-rc1, I get log entries for scheduling while atomic. These BUG
splats are repeated many times, and start early in the boot. I tried to bisect
this problem, but the bug does not always show on every boot, and I must have
had a faulty kernel boot without error. In any case, I ended up at a merge pull.
What I can definitively report is that a kernel generated from commit fd1df00 is
bad.

Fortunately, I have retained the kernels from the bisection onward, and I will
retry them to see if I reported any of them incorrectly. As far as I know, the
configuration was unchanged during the bisection.

The logged messages are as follows:

2014-04-16T10:51:25.205576-05:00 larrylap systemd[1]: Starting Name Service
Cache Daemon...
2014-04-16T10:51:25.197425-05:00 larrylap kernel: [   27.176133] Call Trace:
2014-04-16T10:51:25.205599-05:00 larrylap kernel: [   27.176139]
[] dump_stack+0x4e/0x71
2014-04-16T10:51:25.205605-05:00 larrylap kernel: [   27.176144]
[] __schedule_bug+0x5d/0x6d
2014-04-16T10:51:25.205615-05:00 larrylap kernel: [   27.176149]
[] __schedule+0x775/0x810
2014-04-16T10:51:25.205618-05:00 larrylap kernel: [   27.176154]
[] schedule+0x24/0x70
2014-04-16T10:51:25.205620-05:00 larrylap kernel: [   27.176159]
[] schedule_preempt_disabled+0x11/0x20
2014-04-16T10:51:25.205623-05:00 larrylap kernel: [   27.176164]
[] cpu_startup_entry+0x123/0x430
2014-04-16T10:51:25.205625-05:00 larrylap kernel: [   27.176170]
[] start_secondary+0x1d3/0x290
2014-04-16T10:51:25.205627-05:00 larrylap kernel: [   27.176175]
[] ? acpi_ps_parse_aml+0x186/0x476
2014-04-16T10:51:25.205629-05:00 larrylap kernel: [   27.177033] BUG: scheduling
while atomic: swapper/1/0/0x0004
2014-04-16T10:51:25.205638-05:00 larrylap kernel: [   27.177037] no locks held
by swapper/1/0.
2014-04-16T10:51:25.205641-05:00 larrylap kernel: [   27.177039] Modules linked
in: arc4 b43 mac80211 cfg80211 snd_hda_codec_generic snd_hda_intel snd_hda_co
ntroller snd_hda_codec snd_hwdep snd_pcm snd_seq powernow_k8 kvm_amd kvm rfkill
bcma snd_timer snd_seq_device snd r852 pcspkr ssb serio_raw sdhci_pci sm_comm
on sdhci nand forcedeth mmc_core sg mtd r592 nand_ids nand_bch memstick bch
nand_ecc sr_mod cdrom soundcore battery ac autofs4 nouveau ttm drm_kms_helper 
drm
  i2c_algo_bit i2c_core thermal wmi video processor button thermal_sys hwmon
ata_generic pata_amd


This bug has now been bisected to commit 27f6c57 by Chen, Gong entitled "x86, 
CMCI: Add proper detection of end of CMCI storms".


The problem may not affect the system during a warm reboot, but it is much more 
likely to show during a cold boot.


My CPUs are as follows:

finger@larrylap:~/wireless-testing> hwinfo --cpu
01: None 00.0: 10103 CPU
  [Created at cpu.374]
  Unique ID: rdCR.j8NaKXDZtZ6
  Hardware Class: cpu
  Arch: X86-64
  Vendor: "AuthenticAMD"
  Model: 15.104.2 "AMD Turion(tm) 64 X2 TL-60"
  Features: 
fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,mmx,fxsr,sse,sse2,ht,syscall,nx,mmxext,fxsr_opt,rdtscp,lm,3dnowext,3dnow,rep_good,nopl,extd_apicid,pni,cx16,lahf_lm,cmp_legacy,svm,extapic,cr8_legacy,3dnowprefetch,lbrv

  Clock: 800 MHz
  BogoMips: 1600.16
  Cache: 512 kb
  Units/Processor: 2
  Config Status: cfg=no, avail=yes, need=no, active=unknown

02: None 01.0: 10103 CPU
  [Created at cpu.374]
  Unique ID: wkFv.j8NaKXDZtZ6
  Hardware Class: cpu
  Arch: X86-64
  Vendor: "AuthenticAMD"
  Model: 15.104.2 "AMD Turion(tm) 64 X2 TL-60"
  Features: 
fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,mmx,fxsr,sse,sse2,ht,syscall,nx,mmxext,fxsr_opt,rdtscp,lm,3dnowext,3dnow,rep_good,nopl,extd_apicid,pni,cx16,lahf_lm,cmp_legacy,svm,extapic,cr8_legacy,3dnowprefetch,lbrv

  Clock: 800 MHz
  BogoMips: 1600.16
  Cache: 512 kb
  Units/Processor: 2
  Config Status: cfg=no, avail=yes, need=no, active=unknown
finger@larrylap:~/wireless-testing>

Thank you,

Larry



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ced1401 coding style fixes

[Jinqiang Zeng]

Signed-off-by: Jinqiang Zeng 
---
 drivers/staging/ced1401/usb1401.c   |8 ++--
 drivers/staging/ced1401/use14_ioc.h |4 
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/ced1401/usb1401.c 
b/drivers/staging/ced1401/usb1401.c
index 284abc0..5028318 100644
--- a/drivers/staging/ced1401/usb1401.c
+++ b/drivers/staging/ced1401/usb1401.c
@@ -896,7 +896,7 @@ static bool ReadWord(unsigned short *pWord, char *pBuf, 
unsigned int *pdDone,
 ** to indicate three byte total.
 **
 */
-static bool ReadHuff(volatile unsigned int *pDWord, char *pBuf,
+static bool ReadHuff(unsigned int *pDWord, char *pBuf,
 unsigned int *pdDone, unsigned int dGot)
 {
unsigned char ucData;   /* for each read to ReadChar */
@@ -941,7 +941,7 @@ static bool ReadHuff(volatile unsigned int *pDWord, char 
*pBuf,
 **  we start handling the data at offset zero.
 **
 */
-static bool ReadDMAInfo(volatile DMADESC *pDmaDesc, DEVICE_EXTENSION *pdx,
+static bool ReadDMAInfo(DMADESC *pDmaDesc, DEVICE_EXTENSION *pdx,
char *pBuf, unsigned int dwCount)
 {
bool bResult = false;   /*  assume we won't succeed */
@@ -1122,6 +1122,7 @@ static void ced_readchar_callback(struct urb *pUrb)
spin_lock(>charInLock);/*  already at irq 
level */
if (nGot > 0) {
unsigned int i;
+
if (nGot < INBUF_SZ) {
pdx->pCoherCharIn[nGot] = 0;/*  
tidy the string */
dev_dbg(>interface->dev,
@@ -1514,6 +1515,7 @@ static void ced_disconnect(struct usb_interface 
*interface)
 void ced_draw_down(DEVICE_EXTENSION *pdx)
 {
int time;
+
dev_dbg(>interface->dev, "%s: called\n", __func__);
 
pdx->bInDrawDown = true;
@@ -1548,6 +1550,7 @@ static int ced_resume(struct usb_interface *intf)
 static int ced_pre_reset(struct usb_interface *intf)
 {
DEVICE_EXTENSION *pdx = usb_get_intfdata(intf);
+
dev_dbg(>interface->dev, "%s\n", __func__);
mutex_lock(>io_mutex);
ced_draw_down(pdx);
@@ -1557,6 +1560,7 @@ static int ced_pre_reset(struct usb_interface *intf)
 static int ced_post_reset(struct usb_interface *intf)
 {
DEVICE_EXTENSION *pdx = usb_get_intfdata(intf);
+
dev_dbg(>interface->dev, "%s\n", __func__);
 
/* we are sure no URBs are active - no locking needed */
diff --git a/drivers/staging/ced1401/use14_ioc.h 
b/drivers/staging/ced1401/use14_ioc.h
index 42d2e4e..c27b3b9 100644
--- a/drivers/staging/ced1401/use14_ioc.h
+++ b/drivers/staging/ced1401/use14_ioc.h
@@ -267,15 +267,11 @@ typedef union /* to communicate with 1401 driver 
status & control funcs */
T1401REGISTERS registers;
 } TCSBLOCK;
 
-typedef TCSBLOCK*  LPTCSBLOCK;
-
 typedef struct paramBlk {
 short   sState;
 TCSBLOCKcsBlock;
 } PARAMBLK;
 
-typedef PARAMBLK*   PPARAMBLK;
-
 struct transfer_area_desc  /* Structure and type for SetTransArea */
 {
unsigned shortwArea;/* number of transfer area to 
set up   */
-- 
1.7.7.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Staging:dgap:dgap_tty.c: Upgraded driver to use Mutex instead of semaphore

[Kumar Gaurav]

Hi All,

Any update on below patch. Do i need to make any modification?

On Thursday 17 April 2014 09:25 PM, Kumar Gaurav wrote:

dgap driver uses semaphore for obtaining lock. I upgraded it to use MUTEX.

Signed-off-by: Kumar Gaurav 
---
  drivers/staging/dgap/dgap_tty.c |   17 +
  1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/dgap/dgap_tty.c b/drivers/staging/dgap/dgap_tty.c
index 2a7a372..0ca72a2 100755
--- a/drivers/staging/dgap/dgap_tty.c
+++ b/drivers/staging/dgap/dgap_tty.c
@@ -52,7 +52,7 @@
  #include /* For copy_from_user/copy_to_user */
  #include  /* For read[bwl]/write[bwl] */
  #include 
-
+#include
  #include "dgap_driver.h"
  #include "dgap_tty.h"
  #include "dgap_types.h"
@@ -61,18 +61,12 @@
  #include "dgap_conf.h"
  #include "dgap_sysfs.h"
  
-#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,37)

-#define init_MUTEX(sem) sema_init(sem, 1)
-#define DECLARE_MUTEX(name) \
-struct semaphore name = __SEMAPHORE_INITIALIZER(name, 1)
-#endif
-
  /*
   * internal variables
   */
  static struct board_t *dgap_BoardsByMajor[256];
  static uchar  *dgap_TmpWriteBuf = NULL;
-static DECLARE_MUTEX(dgap_TmpWriteSem);
+static DEFINE_MUTEX(dgap_TmpWriteSem);
  
  /*

   * Default transparent print information.
@@ -2004,12 +1998,11 @@ static int dgap_tty_write(struct tty_struct *tty, const 
unsigned char *buf, int
 * the board.
 */
/* we're allowed to block if it's from_user */
-   if (down_interruptible(_TmpWriteSem)) {
+   if (mutex_lock_interruptible(_TmpWriteSem))
return (-EINTR);
-   }
  
  		if (copy_from_user(dgap_TmpWriteBuf, (const uchar __user *) buf, count)) {

-   up(_TmpWriteSem);
+   mutex_unlock(_TmpWriteSem);
printk("Write: Copy from user failed!\n");
return -EFAULT;
}
@@ -2093,7 +2086,7 @@ static int dgap_tty_write(struct tty_struct *tty, const 
unsigned char *buf, int
  
  	if (from_user) {

DGAP_UNLOCK(ch->ch_lock, lock_flags);
-   up(_TmpWriteSem);
+   mutex_unlock(_TmpWriteSem);
}
else {
DGAP_UNLOCK(ch->ch_lock, lock_flags);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 9/9 V2] idr: remove useless C-PreProcessor branch

[Lai Jiangshan]

On Sun, Apr 20, 2014 at 7:51 AM, Tejun Heo  wrote:
> $SUBJ: idr: remove useless #ifndef TEST
>
> On Sat, Apr 19, 2014 at 07:38:16PM +0800, Lai Jiangshan wrote:
>> "#ifndef TEST" can't work for user space test now, just remove it.
>>
>> Signed-off-by: Lai Jiangshan 
>
> Acked-by: Tejun Heo 

Hi, Tejun

Will you accept the acked patches into your tj/misc.git tree?
(Or somebody else accepts the idr patches?).

5/9 will be sent later (in other patchset)
6/8 will be dropped.

Thanks,
Lai

>
> Thanks.
>
> --
> tejun
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/3] staging: gdm72xx: Minor cleanup

[Michalis Pappas]

Replaced comparisons on jiffies values with wrap-safe functions.

Signed-off-by: Michalis Pappas 
---
 drivers/staging/gdm72xx/gdm_usb.c   | 2 +-
 drivers/staging/gdm72xx/sdio_boot.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/gdm72xx/gdm_usb.c 
b/drivers/staging/gdm72xx/gdm_usb.c
index 20539d8..9ddf8f5 100644
--- a/drivers/staging/gdm72xx/gdm_usb.c
+++ b/drivers/staging/gdm72xx/gdm_usb.c
@@ -730,7 +730,7 @@ static int k_mode_thread(void *arg)
spin_unlock_irqrestore(_lock, flags2);
 
expire = jiffies + K_WAIT_TIME;
-   while (jiffies < expire)
+   while (time_before(jiffies, expire))
schedule_timeout(K_WAIT_TIME);
 
spin_lock_irqsave(>lock, flags);
diff --git a/drivers/staging/gdm72xx/sdio_boot.c 
b/drivers/staging/gdm72xx/sdio_boot.c
index cbe5dcf..2c02842 100644
--- a/drivers/staging/gdm72xx/sdio_boot.c
+++ b/drivers/staging/gdm72xx/sdio_boot.c
@@ -41,11 +41,11 @@ static u8 *tx_buf;
 
 static int ack_ready(struct sdio_func *func)
 {
-   unsigned long start = jiffies;
+   unsigned long wait = jiffies + HZ;
u8 val;
int ret;
 
-   while ((jiffies - start) < HZ) {
+   while (time_before(jiffies, wait)) {
val = sdio_readb(func, 0x13, );
if (val & 0x01)
return 1;
-- 
1.7.12.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/3] staging: gdm72xx: Minor cleanup

[Michalis Pappas]

Removed line related to replacement of kernel_thread with kthread,
as issue was fixed on ff5e4a1d2702582614996f6f6d005e9b5caadeb8.

Signed-off-by: Michalis Pappas 
---
 drivers/staging/gdm72xx/TODO | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/gdm72xx/TODO b/drivers/staging/gdm72xx/TODO
index 5ab27fb..62d0cd6 100644
--- a/drivers/staging/gdm72xx/TODO
+++ b/drivers/staging/gdm72xx/TODO
@@ -1,3 +1,2 @@
 TODO:
-- Replace kernel_thread with kthread in gdm_usb.c
 - Clean up coding style to meet kernel standard.
-- 
1.7.12.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/3] staging: gdm72xx: Minor cleanup

[Michalis Pappas]

Minor white-space fixes as suggested by checkpatch.pl.

Signed-off-by: Michalis Pappas 
---
 drivers/staging/gdm72xx/gdm_qos.c   | 2 +-
 drivers/staging/gdm72xx/gdm_wimax.c | 2 ++
 drivers/staging/gdm72xx/usb_boot.c  | 1 +
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/gdm72xx/gdm_qos.c 
b/drivers/staging/gdm72xx/gdm_qos.c
index 50d43ad..245109e 100644
--- a/drivers/staging/gdm72xx/gdm_qos.c
+++ b/drivers/staging/gdm72xx/gdm_qos.c
@@ -377,7 +377,7 @@ void gdm_recv_qos_hci_packet(void *nic_ptr, u8 *buf, int 
size)
index = get_csr(qcb, SFID, 1);
if (index == -1) {
netdev_err(nic->netdev,
-  "QoS ERROR: csr Update Error / Wrong index (%d) \n",
+  "QoS ERROR: csr Update Error / Wrong index (%d)\n",
   index);
return;
}
diff --git a/drivers/staging/gdm72xx/gdm_wimax.c 
b/drivers/staging/gdm72xx/gdm_wimax.c
index 05ce2a2..5d05cdb 100644
--- a/drivers/staging/gdm72xx/gdm_wimax.c
+++ b/drivers/staging/gdm72xx/gdm_wimax.c
@@ -199,6 +199,7 @@ static void gdm_wimax_event_rcv(struct net_device *dev, u16 
type, void *msg,
u8 *buf = (u8 *) msg;
u16 hci_cmd =  (buf[0]<<8) | buf[1];
u16 hci_len = (buf[2]<<8) | buf[3];
+
netdev_dbg(dev, "H=>D: 0x%04x(%d)\n", hci_cmd, hci_len);
 
gdm_wimax_send(nic, msg, len);
@@ -310,6 +311,7 @@ static int gdm_wimax_event_send(struct net_device *dev, 
char *buf, int size)
 
u16 hci_cmd =  ((u8)buf[0]<<8) | (u8)buf[1];
u16 hci_len = ((u8)buf[2]<<8) | (u8)buf[3];
+
netdev_dbg(dev, "D=>H: 0x%04x(%d)\n", hci_cmd, hci_len);
 
spin_lock_irqsave(_event.evt_lock, flags);
diff --git a/drivers/staging/gdm72xx/usb_boot.c 
b/drivers/staging/gdm72xx/usb_boot.c
index 0d45eb6..4d7c61c 100644
--- a/drivers/staging/gdm72xx/usb_boot.c
+++ b/drivers/staging/gdm72xx/usb_boot.c
@@ -67,6 +67,7 @@ struct fw_info {
 static void array_le32_to_cpu(u32 *arr, int num)
 {
int i;
+
for (i = 0; i < num; i++, arr++)
*arr = __le32_to_cpu(*arr);
 }
-- 
1.7.12.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/3] staging: gdm72xx: Minor cleanup

[Michalis Pappas]

The following patches perform various cleanups on the gdm72xx driver.

PATCH 1/3 fixes some small coding style issues
PATCH 2/3 removes an already completed item from the TODO list
PATCH 3/3 replaces some jiffies comparisons with wrap-safe functions

After all patches have been applied, the only remaining issue on the
TODO list is to conform to the coding standards. The remaining issues
reported by checkpatch.pl are probably pedantic, so if agreed, that task
can be removed from the list too.

-Michalis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Staging: rtl8192e: Fix declaration of symbols

[Joel Pelaez Jorge]

The two declarations with issues in rtl_wx.h:

  * function: struct iw_statistics *r8192_get_wireless_stats();
  * variable: extern struct iw_handler_def r8192_wx_handlers_def;

The symbol 'r8192_get_wireless_stats' is declared as 'extern'
but it is only used in the local scope. The declaration is deleted
of rtl_wx.h, fixing the conflict with the 'extern' and 'static' scope.

The symbol 'r8192_wx_handlers_def' was fixed of some issues related
to variable declaration marked as 'extern' implicitly,
causing this sparse warning:

drivers/staging/rtl8192e/rtl8192e/rtl_wx.c:1323:24: warning: symbol
'r8192_wx_handlers_def' was not declared. Should it be static?

Resolved incluing the fixed header to rtl_wx.c

Also, isn't declared as constant variable, so it declared as such.
And delete unnecessary cast in rtl_core.c.

Signed-off-by: Joel Pelaez Jorge 
---
 drivers/staging/rtl8192e/rtl8192e/rtl_core.c | 3 +--
 drivers/staging/rtl8192e/rtl8192e/rtl_wx.c   | 3 ++-
 drivers/staging/rtl8192e/rtl8192e/rtl_wx.h   | 3 +--
 3 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c 
b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
index c01abc2..fa087b6 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
@@ -2926,8 +2926,7 @@ static int rtl8192_pci_probe(struct pci_dev *pdev,
 
dev->netdev_ops = _netdev_ops;
 
-   dev->wireless_handlers = (struct iw_handler_def *)
-_wx_handlers_def;
+   dev->wireless_handlers = _wx_handlers_def;
dev->ethtool_ops = _ethtool_ops;
 
dev->type = ARPHRD_ETHER;
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_wx.c 
b/drivers/staging/rtl8192e/rtl8192e/rtl_wx.c
index 498995d..7d8fcde 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_wx.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_wx.c
@@ -19,6 +19,7 @@
 
 #include 
 #include "rtl_core.h"
+#include "rtl_wx.h"
 
 #define RATE_COUNT 12
 static u32 rtl8192_rates[] = {
@@ -1320,7 +1321,7 @@ static struct iw_statistics 
*r8192_get_wireless_stats(struct net_device *dev)
return wstats;
 }
 
-struct iw_handler_def  r8192_wx_handlers_def = {
+const struct iw_handler_def r8192_wx_handlers_def = {
.standard = r8192_wx_handlers,
.num_standard = ARRAY_SIZE(r8192_wx_handlers),
.private = r8192_private_handler,
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_wx.h 
b/drivers/staging/rtl8192e/rtl8192e/rtl_wx.h
index 6a51a25..5839851 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_wx.h
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_wx.h
@@ -24,8 +24,7 @@ struct net_device;
 struct iw_handler_def;
 struct iw_statistics;
 
-extern struct iw_handler_def r8192_wx_handlers_def;
-struct iw_statistics *r8192_get_wireless_stats(struct net_device *dev);
+extern const struct iw_handler_def r8192_wx_handlers_def;
 u16 rtl8192_11n_user_show_rates(struct net_device *dev);
 
 #endif
-- 
1.9.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/8] ARM: mvebu: Add USB3 UTMI support

[Felipe Balbi]

Hi,

On Fri, Apr 18, 2014 at 12:22:39PM +0200, Gregory CLEMENT wrote:
> The usb3-utmi registers allow to configure the internal USB PHY of the
> Armada 380/385 SoCs. A small initialization is needed to be able to use
> the USB3 ports.
> 
> Signed-off-by: Gregory CLEMENT 

looks like this should be a generic drivers/phy/phy-utmi.c driver

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 3/8] xhci-platform: Add a new controller using xhci: Armada 38x

[Felipe Balbi]

On Fri, Apr 18, 2014 at 12:22:38PM +0200, Gregory CLEMENT wrote:
> Extend the compatible string list with xhci-armada-380. It is used to
> describe xhci controller which is in the Armada 38x SoCs.
> 
> Signed-off-by: Gregory CLEMENT 
> ---
>  Documentation/devicetree/bindings/usb/usb-xhci.txt | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt 
> b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> index 90f8f607d125..c49c14037afe 100644
> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> @@ -1,7 +1,8 @@
>  USB xHCI controllers
>  
>  Required properties:
> -  - compatible: should be "generic-xhci" (deprecated: "xhci-platform").
> +  - compatible: should be on of "generic-xhci",

should be "one" of.

> +"marvell,xhci-armada-380" (deprecated: "xhci-platform").

and this gives me a better idea, instead of using the quirk I suggested
before, match against this compatible:

if (of_device_is_compatible(dev, "marvell,xhci-armada-380")
xhci_marvel_mbus_init_quirk(dev);

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 2/8] usb: host: xhci-plat: Add support for the Armada 38x glue code

[Felipe Balbi]

On Fri, Apr 18, 2014 at 12:22:37PM +0200, Gregory CLEMENT wrote:
> For the armada 38x SoCs which come with an xhci controller, specific
> initialization must be done during probe, especially in relation with
> the MBus windows initialization. This patch adds this support.
> 
> Signed-off-by: Gregory CLEMENT 
> ---
>  drivers/usb/host/Kconfig  |   7 +++
>  drivers/usb/host/Makefile |   1 +
>  drivers/usb/host/xhci-mvebu.c | 105 
> ++
>  drivers/usb/host/xhci-mvebu.h |  21 +
>  drivers/usb/host/xhci-plat.c  |  10 
>  5 files changed, 144 insertions(+)
>  create mode 100644 drivers/usb/host/xhci-mvebu.c
>  create mode 100644 drivers/usb/host/xhci-mvebu.h
> 
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 3d9e54062d62..e70943fac4a1 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -29,6 +29,13 @@ if USB_XHCI_HCD
>  config USB_XHCI_PLATFORM
>   tristate
>  
> +config USB_XHCI_MVEBU
> + tristate "xHCI support for Marvell Armada 38x"
> + select USB_XHCI_PLATFORM
> + ---help---
> +   Say 'Y' to enable the support for the xHCI host controller
> +   found in Marvell Armada 38x ARM SOCs.
> +
>  endif # USB_XHCI_HCD
>  
>  config USB_EHCI_HCD
> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> index 7530468c9a4f..7a8db7f7dc01 100644
> --- a/drivers/usb/host/Makefile
> +++ b/drivers/usb/host/Makefile
> @@ -19,6 +19,7 @@ xhci-hcd-$(CONFIG_PCI)  += xhci-pci.o
>  
>  ifneq ($(CONFIG_USB_XHCI_PLATFORM), )
>   xhci-hcd-y  += xhci-plat.o
> + xhci-hcd-$(CONFIG_USB_XHCI_MVEBU)   += xhci-mvebu.o
>  endif
>  
>  obj-$(CONFIG_USB_WHCI_HCD)   += whci/
> diff --git a/drivers/usb/host/xhci-mvebu.c b/drivers/usb/host/xhci-mvebu.c
> new file mode 100644
> index ..dc9c7648ab65
> --- /dev/null
> +++ b/drivers/usb/host/xhci-mvebu.c
> @@ -0,0 +1,105 @@
> +/*
> + * Copyright (C) 2014 Marvell
> + * Author: Gregory CLEMENT 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "xhci.h"
> +
> +#define USB3_MAX_WINDOWS 4
> +#define USB3_WIN_CTRL(w) (0x0 + ((w) * 8))
> +#define USB3_WIN_BASE(w) (0x4 + ((w) * 8))
> +
> +static void __init mv_usb3_conf_mbus_windows(void __iomem *base,
> + const struct mbus_dram_target_info *dram)
> +{
> + int win;
> +
> + /* Clear all existing windows */
> + for (win = 0; win < USB3_MAX_WINDOWS; win++) {
> + writel(0, base + USB3_WIN_CTRL(win));
> + writel(0, base + USB3_WIN_BASE(win));
> + }
> +
> + /* Program each DRAM CS in a seperate window */
> + for (win = 0; win < dram->num_cs; win++) {
> + const struct mbus_dram_window *cs = dram->cs + win;
> +
> + writel(((cs->size - 1) & 0x) | (cs->mbus_attr << 8) |
> +(dram->mbus_dram_target_id << 4) | 1,
> +base + USB3_WIN_CTRL(win));
> +
> + writel((cs->base & 0x), base + USB3_WIN_BASE(win));
> + }
> +}
> +
> +int xhci_mvebu_probe(struct platform_device *pdev)
> +{
> + struct resource *res;
> + void __iomem*base;
> + const struct mbus_dram_target_info *dram;
> + int ret;
> + struct clk *clk;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + if (!res)
> + return -ENODEV;
> +
> + /*
> +  * We don't use devm_ioremap() because this mapping should
> +  * only exists for the duration of this probe function.
> +  */
> + base = ioremap(res->start, resource_size(res));
> + if (!base)
> + return -ENODEV;
> +
> + clk = devm_clk_get(>dev, NULL);
> + if (IS_ERR(clk)) {
> + iounmap(base);
> + return PTR_ERR(clk);
> + }
> +
> + ret = clk_prepare_enable(clk);
> + if (ret < 0) {
> + iounmap(base);
> + return ret;
> + }

it's best to teach generic xhci-plat about clocks, just make it
optional.

> + dram = mv_mbus_dram_info();
> + mv_usb3_conf_mbus_windows(base, dram);
> +
> + /*
> +  * This memory area was only needed to configure the MBus
> +  * windows, and is therefore no longer useful.
> +  */
> + iounmap(base);

so I suppose MBus is the Marvell interconnect, am I right ? Wouldn't you
be duplicating this sort of initialization for most drivers ?

> + ret = common_xhci_plat_probe(pdev, clk);

I would much rather reverse this, instead of exposing xhci-plat's probe,
turn this mbus initialization into a quirk which will ioremap the extra
resource, initialize some registers and iounmap it.

> diff --git a/drivers/usb/host/xhci-mvebu.h b/drivers/usb/host/xhci-mvebu.h
> new file mode 

Re: [PATCH] KVM: x86: Check for host supported fields in shadow vmcs

[Paolo Bonzini]

Il 19/04/2014 19:34, Bandan Das ha scritto:


We track shadow vmcs fields through two static lists,
one for read only fields and another for r/w. However, with
addition of new vmcs fields, not all fields may be supported on
all hosts. If so, copy_vmcs12_to_shadow() trying to vmwrite on older
hosts will result in a vmwrite error. For example, commit
36be0b9deb23161 introduced GUEST_BNDCFGS, which is not supported
for all processors. Create new lists based out of intersection of
static lists and host support and use them for tracking
shadow fields instead

Signed-off-by: Bandan Das 
---
 arch/x86/kvm/vmx.c | 98 +++---
 1 file changed, 79 insertions(+), 19 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 7bed3e3..ffc2232 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -502,7 +502,10 @@ static inline struct vcpu_vmx *to_vmx(struct kvm_vcpu 
*vcpu)
 #define FIELD64(number, name)  [number] = VMCS12_OFFSET(name), \
[number##_HIGH] = VMCS12_OFFSET(name)+4

-
+/*
+ * Do not use the two lists below directly
+ * Use vmcs_shadow_fields instead
+ */
 static const unsigned long shadow_read_only_fields[] = {
/*
 * We do NOT shadow fields that are modified when L0
@@ -526,8 +529,6 @@ static const unsigned long shadow_read_only_fields[] = {
GUEST_LINEAR_ADDRESS,
GUEST_PHYSICAL_ADDRESS
 };
-static const int max_shadow_read_only_fields =
-   ARRAY_SIZE(shadow_read_only_fields);

 static const unsigned long shadow_read_write_fields[] = {
GUEST_RIP,
@@ -558,8 +559,18 @@ static const unsigned long shadow_read_write_fields[] = {
HOST_FS_SELECTOR,
HOST_GS_SELECTOR
 };
-static const int max_shadow_read_write_fields =
-   ARRAY_SIZE(shadow_read_write_fields);


Can we just remove the "const" here, and compress the arrays down 
similar to what kvm_init_msr_list does.



+/* If new shadow fields are added, these should be modified appropriately */
+#define VMCS_MAX_RO_FIELDS 10
+#define VMCS_MAX_RW_FIELDS 30
+
+struct vmcs_shadow_fields_data {
+   int shadow_ro_fields_len;
+   int shadow_rw_fields_len;
+   unsigned long shadow_read_only_fields[VMCS_MAX_RO_FIELDS];
+   unsigned long shadow_read_write_fields[VMCS_MAX_RW_FIELDS];
+};
+static struct vmcs_shadow_fields_data vmcs_shadow_fields;

 static const unsigned short vmcs_field_to_offset_table[] = {
FIELD(VIRTUAL_PROCESSOR_ID, virtual_processor_id),
@@ -3027,6 +3038,56 @@ static __init int alloc_kvm_area(void)
return 0;
 }

+static void cleanup_vmcs_shadow_fields(void)
+{
+   memset(_shadow_fields, 0,
+  sizeof(struct vmcs_shadow_fields_data));
+}
+
+static void init_vmcs_shadow_fields(void)
+{
+   struct vmcs_shadow_fields_data *vmcs_ptr = _shadow_fields;
+   int max_shadow_read_write_fields = ARRAY_SIZE(shadow_read_write_fields);
+   int max_shadow_read_only_fields = ARRAY_SIZE(shadow_read_only_fields);
+   int i, j;
+
+   for (i = 0, j = 0; i < max_shadow_read_write_fields; i++) {
+   if (i >= VMCS_MAX_RW_FIELDS) {
+   WARN(1, "Shadow RW fields index out of bounds\n");
+   break;
+   }
+   if ((shadow_read_write_fields[i] == GUEST_BNDCFGS) &&
+   !vmx_mpx_supported())
+   continue;


Please code this as a "switch" statement for easier future 
extensibility.  Again, this would be similar to kvm_init_msr_list.


How did you find this?  Do you have access to a machine with shadow 
VMCS?  Is that Ivy Bridge Xeon E5 or does some lower-end Haswell have it?


Paolo


+   vmcs_ptr->shadow_read_write_fields[j++] =
+   shadow_read_write_fields[i];
+   vmcs_ptr->shadow_rw_fields_len++;
+   }
+
+   for (i = 0, j = 0; i < max_shadow_read_only_fields; i++) {
+   if (i >= VMCS_MAX_RO_FIELDS) {
+   WARN(1, "Shadow RO fields index out of bounds\n");
+   break;
+   }
+   vmcs_ptr->shadow_read_only_fields[j++] =
+   shadow_read_only_fields[i];
+   vmcs_ptr->shadow_ro_fields_len++;
+   }
+
+   /* shadowed read/write fields */
+   for (i = 0; i < vmcs_ptr->shadow_rw_fields_len; i++) {
+   clear_bit(vmcs_ptr->shadow_read_write_fields[i],
+ vmx_vmwrite_bitmap);
+   clear_bit(vmcs_ptr->shadow_read_write_fields[i],
+ vmx_vmread_bitmap);
+   }
+   /* shadowed read only fields */
+   for (i = 0; i < vmcs_ptr->shadow_ro_fields_len; i++)
+   clear_bit(vmcs_ptr->shadow_read_only_fields[i],
+ vmx_vmread_bitmap);
+
+}
+
 static __init int hardware_setup(void)
 {
if (setup_vmcs_config(_config) < 0)
@@ -3039,6 +3100,8 @@ static __init int hardware_setup(void)
 

Re: [PATCH 1/8] usb: host: xhci-plat: Allow to register glue code using the device tree

[Felipe Balbi]

Hi,

On Fri, Apr 18, 2014 at 12:22:36PM +0200, Gregory CLEMENT wrote:
> This patch allow to register specific glue code for xhci controller.
> It creates a structure called xhci_plat_ops to register functions
> specific to an SoC. Currently there are only probe() and remove() but

What SoC-specific code do you need ?

> it can be extended later, it was the point to create such a structure.
> 
> Each compatible string can then be associated to an instance of this
> structure. In the non device tree case a default structure is used.
> 
> Signed-off-by: Gregory CLEMENT 
> ---
>  drivers/usb/host/xhci-plat.c | 72 
> +---
>  drivers/usb/host/xhci.h  |  4 +++
>  2 files changed, 72 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 151901ce1ba9..8029cc82edc4 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "xhci.h"
>  
> @@ -85,7 +86,7 @@ static const struct hc_driver xhci_plat_xhci_driver = {
>   .bus_resume =   xhci_bus_resume,
>  };
>  
> -static int xhci_plat_probe(struct platform_device *pdev)
> +int common_xhci_plat_probe(struct platform_device *pdev, void *priv)

no, I rather not see this sort of hack.

-- 
balbi


signature.asc
Description: Digital signature

[PATCH 1/2] Staging: dgnc: dgnc_driver: fixed coding style of dgnc_pci_tbl

[Son P. Nguyen]

From: "Son P. Nguyen" 

Fixed coding style of dgnc_pci_tbl definition (longer than 80 chars)

Signed-off-by: Son P. Nguyen 
---
 drivers/staging/dgnc/dgnc_driver.c | 36 +++-
 1 file changed, 19 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_driver.c 
b/drivers/staging/dgnc/dgnc_driver.c
index b1a39b2..e91d3a7 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -124,25 +124,27 @@ static ulong  dgnc_poll_time; 
/* Time of next poll */
 static uintdgnc_poll_stop; /* Used to tell 
poller to stop */
 static struct timer_list dgnc_poll_timer;
 
+#define DIGIVID_PCI_DEVICE_ID(subdevice, driver_data) \
+   { DIGI_VID, PCI_DEVICE_##subdevice, PCI_ANY_ID, 0, 0, driver_data }
 
 static struct pci_device_id dgnc_pci_tbl[] = {
-   {   DIGI_VID, PCI_DEVICE_CLASSIC_4_DID, PCI_ANY_ID, PCI_ANY_ID, 0, 
0,   0 },
-   {   DIGI_VID, PCI_DEVICE_CLASSIC_4_422_DID, PCI_ANY_ID, PCI_ANY_ID, 
0, 0,   1 },
-   {   DIGI_VID, PCI_DEVICE_CLASSIC_8_DID, PCI_ANY_ID, PCI_ANY_ID, 0, 
0,   2 },
-   {   DIGI_VID, PCI_DEVICE_CLASSIC_8_422_DID, PCI_ANY_ID, PCI_ANY_ID, 
0, 0,   3 },
-   {   DIGI_VID, PCI_DEVICE_NEO_4_DID, PCI_ANY_ID, PCI_ANY_ID, 0, 0,   
4 },
-   {   DIGI_VID, PCI_DEVICE_NEO_8_DID, PCI_ANY_ID, PCI_ANY_ID, 0, 0,   
5 },
-   {   DIGI_VID, PCI_DEVICE_NEO_2DB9_DID, PCI_ANY_ID, PCI_ANY_ID, 0, 
0,6 },
-   {   DIGI_VID, PCI_DEVICE_NEO_2DB9PRI_DID, PCI_ANY_ID, PCI_ANY_ID, 
0, 0, 7 },
-   {   DIGI_VID, PCI_DEVICE_NEO_2RJ45_DID, PCI_ANY_ID, PCI_ANY_ID, 0, 
0,   8 },
-   {   DIGI_VID, PCI_DEVICE_NEO_2RJ45PRI_DID, PCI_ANY_ID, PCI_ANY_ID, 
0, 0,9 },
-   {   DIGI_VID, PCI_DEVICE_NEO_1_422_DID, PCI_ANY_ID, PCI_ANY_ID, 0, 
0,   10 },
-   {   DIGI_VID, PCI_DEVICE_NEO_1_422_485_DID, PCI_ANY_ID, PCI_ANY_ID, 
0, 0,   11 },
-   {   DIGI_VID, PCI_DEVICE_NEO_2_422_485_DID, PCI_ANY_ID, PCI_ANY_ID, 
0, 0,   12 },
-   {   DIGI_VID, PCI_DEVICE_NEO_EXPRESS_8_DID, PCI_ANY_ID, PCI_ANY_ID, 
0, 0,13 },
-   {   DIGI_VID, PCI_DEVICE_NEO_EXPRESS_4_DID, PCI_ANY_ID, PCI_ANY_ID, 
0, 0,   14 },
-   {   DIGI_VID, PCI_DEVICE_NEO_EXPRESS_4RJ45_DID, PCI_ANY_ID, 
PCI_ANY_ID, 0, 0,   15 },
-   {   DIGI_VID, PCI_DEVICE_NEO_EXPRESS_8RJ45_DID, PCI_ANY_ID, 
PCI_ANY_ID, 0, 0,   16 },
+   { DIGIVID_PCI_DEVICE_ID(CLASSIC_4_DID,  0 },
+   { DIGIVID_PCI_DEVICE_ID(CLASSIC_4_422_DID,  1 },
+   { DIGIVID_PCI_DEVICE_ID(CLASSIC_8_DID,  2 },
+   { DIGIVID_PCI_DEVICE_ID(CLASSIC_8_422_DID,  3 },
+   { DIGIVID_PCI_DEVICE_ID(NEO_4_DID,  4 },
+   { DIGIVID_PCI_DEVICE_ID(NEO_8_DID,  5 },
+   { DIGIVID_PCI_DEVICE_ID(NEO_2DB9_DID,   6 },
+   { DIGIVID_PCI_DEVICE_ID(NEO_2DB9PRI_DID,7 },
+   { DIGIVID_PCI_DEVICE_ID(NEO_2RJ45_DID,  8 },
+   { DIGIVID_PCI_DEVICE_ID(NEO_2RJ45PRI_DID,   9 },
+   { DIGIVID_PCI_DEVICE_ID(NEO_1_422_DID,  10 },
+   { DIGIVID_PCI_DEVICE_ID(NEO_1_422_485_DID,  11 },
+   { DIGIVID_PCI_DEVICE_ID(NEO_2_422_485_DID,  12 },
+   { DIGIVID_PCI_DEVICE_ID(NEO_EXPRESS_8_DID,  13 },
+   { DIGIVID_PCI_DEVICE_ID(NEO_EXPRESS_4_DID,  14 },
+   { DIGIVID_PCI_DEVICE_ID(NEO_EXPRESS_4RJ45_DID,  15 },
+   { DIGIVID_PCI_DEVICE_ID(NEO_EXPRESS_8RJ45_DID,  16 },
{0,}/* 0 terminated list. */
 };
 MODULE_DEVICE_TABLE(pci, dgnc_pci_tbl);
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] Staging: dgnc: dgnc_driver: fixed coding style braces

[Son P. Nguyen]

From: "Son P. Nguyen" 

Fixed incorrect braces (coding style)

PS: This is for task 10 of eudyptula-challenge.

Signed-off-by: Son P. Nguyen 
---
 drivers/staging/dgnc/dgnc_driver.c | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_driver.c 
b/drivers/staging/dgnc/dgnc_driver.c
index e91d3a7..c8b02f5 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -88,8 +88,7 @@ module_exit(dgnc_cleanup_module);
 /*
  * File operations permitted on Control/Management major.
  */
-static const struct file_operations dgnc_BoardFops =
-{
+static const struct file_operations dgnc_BoardFops = {
.owner  =   THIS_MODULE,
.unlocked_ioctl =   dgnc_mgmt_ioctl,
.open   =   dgnc_mgmt_open,
@@ -155,8 +154,7 @@ struct board_id {
unsigned int is_pci_express;
 };
 
-static struct board_id dgnc_Ids[] =
-{
+static struct board_id dgnc_Ids[] = {
{   PCI_DEVICE_CLASSIC_4_PCI_NAME,  4,  0   },
{   PCI_DEVICE_CLASSIC_4_422_PCI_NAME,  4,  0   },
{   PCI_DEVICE_CLASSIC_8_PCI_NAME,  8,  0   },
@@ -221,9 +219,8 @@ int dgnc_init_module(void)
 */
rc = dgnc_start();
 
-   if (rc < 0) {
+   if (rc < 0)
return rc;
-   }
 
/*
 * Find and configure all the cards
@@ -241,8 +238,7 @@ int dgnc_init_module(void)
pr_warn("WARNING: dgnc driver load failed.  No Digi Neo 
or Classic boards found.\n");
 
dgnc_cleanup_module();
-   }
-   else {
+   } else {
dgnc_create_driver_sysfiles(_driver);
}
 
@@ -521,9 +517,8 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
 
brd->state  = BOARD_FOUND;
 
-   for (i = 0; i < MAXPORTS; i++) {
-   brd->channels[i] = NULL;
-   }
+   for (i = 0; i < MAXPORTS; i++)
+   brd->channels[i] = NULL;
 
/* store which card & revision we have */
pci_read_config_word(pdev, PCI_SUBSYSTEM_VENDOR_ID, >subvendor);
-- 
1.8.1.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/6] m68k: call find_vma with the mmap_sem held in sys_cacheflush()

[Davidlohr Bueso]

Performing vma lookups without taking the mm->mmap_sem is asking
for trouble. While doing the search, the vma in question can be
modified or even removed before returning to the caller. Take the
lock (shared) in order to avoid races while iterating through
the vmacache and/or rbtree.

This patch is completely *untested*.

Signed-off-by: Davidlohr Bueso 
Cc: Geert Uytterhoeven 
Cc: linux-m...@lists.linux-m68k.org
---
 arch/m68k/kernel/sys_m68k.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/m68k/kernel/sys_m68k.c b/arch/m68k/kernel/sys_m68k.c
index 3a480b3..d2263a0 100644
--- a/arch/m68k/kernel/sys_m68k.c
+++ b/arch/m68k/kernel/sys_m68k.c
@@ -376,7 +376,6 @@ cache_flush_060 (unsigned long addr, int scope, int cache, 
unsigned long len)
 asmlinkage int
 sys_cacheflush (unsigned long addr, int scope, int cache, unsigned long len)
 {
-   struct vm_area_struct *vma;
int ret = -EINVAL;
 
if (scope < FLUSH_SCOPE_LINE || scope > FLUSH_SCOPE_ALL ||
@@ -389,16 +388,23 @@ sys_cacheflush (unsigned long addr, int scope, int cache, 
unsigned long len)
if (!capable(CAP_SYS_ADMIN))
goto out;
} else {
+   struct vm_area_struct *vma;
+   bool invalid;
+
+   /* Check for overflow.  */
+   if (addr + len < addr)
+   goto out;
+
/*
 * Verify that the specified address region actually belongs
 * to this process.
 */
-   vma = find_vma (current->mm, addr);
ret = -EINVAL;
-   /* Check for overflow.  */
-   if (addr + len < addr)
-   goto out;
-   if (vma == NULL || addr < vma->vm_start || addr + len > 
vma->vm_end)
+   down_read(>mm->mmap_sem);
+   vma = find_vma(current->mm, addr);
+   invalid = !vma || addr < vma->vm_start || addr + len > 
vma->vm_end;
+   up_read(>mm->mmap_sem);
+   if (invalid)
goto out;
}
 
-- 
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/6] arc: call find_vma with the mmap_sem held

[Davidlohr Bueso]

Performing vma lookups without taking the mm->mmap_sem is asking
for trouble. While doing the search, the vma in question can be
modified or even removed before returning to the caller. Take the
lock (shared) in order to avoid races while iterating through
the vmacache and/or rbtree.

This patch is completely *untested*.

Signed-off-by: Davidlohr Bueso 
Cc: Vineet Gupta 
---
 arch/arc/kernel/troubleshoot.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arc/kernel/troubleshoot.c b/arch/arc/kernel/troubleshoot.c
index 73a7450..3a5a5c1 100644
--- a/arch/arc/kernel/troubleshoot.c
+++ b/arch/arc/kernel/troubleshoot.c
@@ -90,7 +90,7 @@ static void show_faulting_vma(unsigned long address, char 
*buf)
/* can't use print_vma_addr() yet as it doesn't check for
 * non-inclusive vma
 */
-
+   down_read(>active_mm->mmap_sem);
vma = find_vma(current->active_mm, address);
 
/* check against the find_vma( ) behaviour which returns the next VMA
@@ -110,9 +110,10 @@ static void show_faulting_vma(unsigned long address, char 
*buf)
vma->vm_start < TASK_UNMAPPED_BASE ?
address : address - vma->vm_start,
nm, vma->vm_start, vma->vm_end);
-   } else {
+   } else
pr_info("@No matching VMA found\n");
-   }
+
+   up_read(>active_mm->mmap_sem);
 }
 
 static void show_ecr_verbose(struct pt_regs *regs)
-- 
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/6] drivers,sgi-gru/grufault.c: call find_vma with the mmap_sem held

[Davidlohr Bueso]

From: Jonathan Gonzalez V 

Performing vma lookups without taking the mm->mmap_sem is asking
for trouble. While doing the search, the vma in question can
be modified or even removed before returning to the caller.
Take the lock in order to avoid races while iterating through
the vmacache and/or rbtree.

This patch is completely *untested*.

Signed-off-by: Jonathan Gonzalez V 
Signed-off-by: Davidlohr Bueso 
Cc: Dimitri Sivanich mmap_sem);
vma = find_vma(mm, vaddr);
if (!vma)
goto inval;
@@ -277,22 +278,26 @@ static int gru_vtop(struct gru_thread_state *gts, 
unsigned long vaddr,
rmb();  /* Must/check ms_range_active before loading PTEs */
ret = atomic_pte_lookup(vma, vaddr, write, , );
if (ret) {
-   if (atomic)
-   goto upm;
+   if (atomic) {
+   up_write(>mmap_sem);
+   return VTOP_RETRY;
+   }
if (non_atomic_pte_lookup(vma, vaddr, write, , ))
goto inval;
}
if (is_gru_paddr(paddr))
goto inval;
+
+   up_write(>mmap_sem);
+
paddr = paddr & ~((1UL << ps) - 1);
*gpa = uv_soc_phys_ram_to_gpa(paddr);
*pageshift = ps;
return VTOP_SUCCESS;
 
 inval:
+   up_write(>mmap_sem);
return VTOP_INVALID;
-upm:
-   return VTOP_RETRY;
 }
 
 
-- 
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/6] mips: call find_vma with the mmap_sem held

[Davidlohr Bueso]

Performing vma lookups without taking the mm->mmap_sem is asking
for trouble. While doing the search, the vma in question can be
modified or even removed before returning to the caller. Take the
lock (exclusively) in order to avoid races while iterating through
the vmacache and/or rbtree.

Updates two functions:
  - process_fpemu_return()
  - cteon_flush_cache_sigtramp()

This patch is completely *untested*.

Signed-off-by: Davidlohr Bueso 
Cc: Ralf Baechle 
Cc: linux-m...@linux-mips.org
---
 arch/mips/kernel/traps.c | 2 ++
 arch/mips/mm/c-octeon.c  | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index 074e857..c51bd20 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -712,10 +712,12 @@ int process_fpemu_return(int sig, void __user *fault_addr)
si.si_addr = fault_addr;
si.si_signo = sig;
if (sig == SIGSEGV) {
+   down_read(>mm->mmap_sem);
if (find_vma(current->mm, (unsigned long)fault_addr))
si.si_code = SEGV_ACCERR;
else
si.si_code = SEGV_MAPERR;
+   up_read(>mm->mmap_sem);
} else {
si.si_code = BUS_ADRERR;
}
diff --git a/arch/mips/mm/c-octeon.c b/arch/mips/mm/c-octeon.c
index f41a5c5..05b1d7c 100644
--- a/arch/mips/mm/c-octeon.c
+++ b/arch/mips/mm/c-octeon.c
@@ -137,8 +137,10 @@ static void octeon_flush_cache_sigtramp(unsigned long addr)
 {
struct vm_area_struct *vma;
 
+   down_read(>mm->mmap_sem);
vma = find_vma(current->mm, addr);
octeon_flush_icache_all_cores(vma);
+   up_read(>mm->mmap_sem);
 }
 
 
-- 
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/6] drm/exynos: call find_vma with the mmap_sem held

[Davidlohr Bueso]

From: Jonathan Gonzalez V 

Performing vma lookups without taking the mm->mmap_sem is asking
for trouble. While doing the search, the vma in question can be
modified or even removed before returning to the caller. Take the
lock (exclusively) in order to avoid races while iterating through
the vmacache and/or rbtree.

This patch is completely *untested*.

Signed-off-by: Jonathan Gonzalez V 
Signed-off-by: Davidlohr Bueso 
Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: David Airlie 
Cc: dri-de...@lists.freedesktop.org
Cc: linux-samsung-...@vger.kernel.org
---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 6c1885e..8001587 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -467,14 +467,17 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct 
drm_device *drm_dev,
goto err_free;
}
 
+   down_read(>mm->mmap_sem);
vma = find_vma(current->mm, userptr);
if (!vma) {
+   up_read(>mm->mmap_sem);
DRM_ERROR("failed to get vm region.\n");
ret = -EFAULT;
goto err_free_pages;
}
 
if (vma->vm_end < userptr + size) {
+   up_read(>mm->mmap_sem);
DRM_ERROR("vma is too small.\n");
ret = -EFAULT;
goto err_free_pages;
@@ -482,6 +485,7 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct 
drm_device *drm_dev,
 
g2d_userptr->vma = exynos_gem_get_vma(vma);
if (!g2d_userptr->vma) {
+   up_read(>mm->mmap_sem);
DRM_ERROR("failed to copy vma.\n");
ret = -ENOMEM;
goto err_free_pages;
@@ -492,10 +496,12 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct 
drm_device *drm_dev,
ret = exynos_gem_get_pages_from_userptr(start & PAGE_MASK,
npages, pages, vma);
if (ret < 0) {
+   up_read(>mm->mmap_sem);
DRM_ERROR("failed to get user pages from userptr.\n");
goto err_put_vma;
}
 
+   up_read(>mm->mmap_sem);
g2d_userptr->pages = pages;
 
sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
-- 
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/6] mm: audit find_vma() callers

[Davidlohr Bueso]

Ensure find_vma() callers do so with the mmap_sem held. 

I'm sure there are a few more places left to fix, but 
this is a pretty good start. Following the call chain,
some users become all tangled up, but I believe these
fixes are correct. Furthermore, the bulk of the callers
of find_vma are in a lot of functions where it is well
known that the mmap_sem is taken way before, such as
get_unmapped_area() family.

Please note that none of the patches are tested.

Thanks!

  blackfin/ptrace: call find_vma with the mmap_sem held
  m68k: call find_vma with the mmap_sem held in sys_cacheflush()
  mips: call find_vma with the mmap_sem held
  arc: call find_vma with the mmap_sem held
  drivers/misc/sgi-gru/grufault.c: call find_vma with the mmap_sem held
  drm/exynos: call find_vma with the mmap_sem held

 arch/arc/kernel/troubleshoot.c  |  7 ---
 arch/blackfin/kernel/ptrace.c   |  8 ++--
 arch/m68k/kernel/sys_m68k.c | 18 --
 arch/mips/kernel/traps.c|  2 ++
 arch/mips/mm/c-octeon.c |  2 ++
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |  6 ++
 drivers/misc/sgi-gru/grufault.c | 13 +
 7 files changed, 41 insertions(+), 15 deletions(-)

-- 
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/6] blackfin/ptrace: call find_vma with the mmap_sem held

[Davidlohr Bueso]

Performing vma lookups without taking the mm->mmap_sem is asking
for trouble. While doing the search, the vma in question can be
modified or even removed before returning to the caller. Take the
lock (shared) in order to avoid races while iterating through the
vmacache and/or rbtree.

This patch is completely *untested*.

Signed-off-by: Davidlohr Bueso 
Cc: Steven Miao 
Cc: adi-buildroot-de...@lists.sourceforge.net
---
 arch/blackfin/kernel/ptrace.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/blackfin/kernel/ptrace.c b/arch/blackfin/kernel/ptrace.c
index e1f88e0..8b8fe67 100644
--- a/arch/blackfin/kernel/ptrace.c
+++ b/arch/blackfin/kernel/ptrace.c
@@ -117,6 +117,7 @@ put_reg(struct task_struct *task, unsigned long regno, 
unsigned long data)
 int
 is_user_addr_valid(struct task_struct *child, unsigned long start, unsigned 
long len)
 {
+   bool valid;
struct vm_area_struct *vma;
struct sram_list_struct *sraml;
 
@@ -124,9 +125,12 @@ is_user_addr_valid(struct task_struct *child, unsigned 
long start, unsigned long
if (start + len < start)
return -EIO;
 
+   down_read(>mm->mmap_sem);
vma = find_vma(child->mm, start);
-   if (vma && start >= vma->vm_start && start + len <= vma->vm_end)
-   return 0;
+   valid = vma && start >= vma->vm_start && start + len <= vma->vm_end;
+   up_read(>mm->mmap_sem);
+   if (valid)
+   return 0;
 
for (sraml = child->mm->context.sram_list; sraml; sraml = sraml->next)
if (start >= (unsigned long)sraml->addr
-- 
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 3/3] atmel: dt: Add supports for the lcdc support on the sama5d36ek

[Jean-Jacques Hiblot]

2014-04-18 16:48 GMT+02:00 Robert Nelson :
>
> On Fri, Apr 18, 2014 at 4:45 AM, Jean-Jacques Hiblot
>  wrote:
>> Signed-off-by: Jean-Jacques Hiblot 
>> ---
>>  arch/arm/boot/dts/sama5d36ek.dts | 27 ++-
>>  1 file changed, 26 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/sama5d36ek.dts 
>> b/arch/arm/boot/dts/sama5d36ek.dts
>> index 59576c6..df01037 100644
>> --- a/arch/arm/boot/dts/sama5d36ek.dts
>> +++ b/arch/arm/boot/dts/sama5d36ek.dts
>> @@ -11,12 +11,17 @@
>>  #include "sama5d3xmb.dtsi"
>>  #include "sama5d3xdm.dtsi"
>>
>> +
>
> extra space
>
>>  / {
>> model = "Atmel SAMA5D36-EK";
>> compatible = "atmel,sama5d36ek", "atmel,sama5d3xmb", 
>> "atmel,sama5d3xcm", "atmel,sama5d36", "atmel,sama5d3", "atmel,sama5";
>>
>> ahb {
>> apb {
>> +   hlcdc: hlcdc@f003 {
>> +   status = "okay";
>> +   };
>> +
>> spi0: spi@f0004000 {
>> status = "okay";
>> };
>> @@ -46,7 +51,27 @@
>> };
>> };
>> };
>> -
>> +   panel {
>> +   compatible = "atmel,hlcdc,panel";
>> +   invert-hsync;
>> +   invert-vsync;
>> +   status = "okay";
>> +   display-timings {
>> +   800x480p60 {
>> +   clock-frequency = <3326>;
>> +   hactive = <800>;
>> +   vactive = <480>;
>> +   hfront-porch = <168>;
>> +   hback-porch = <88>;
>> +   hsync-len = <64>;
>> +   vback-porch = <8>;
>> +   vfront-porch = <37>;
>> +   vsync-len = <2>;
>> +   hsync-active = <1>;
>> +   vsync-active = <1>;
>> +   };
>> +   };
>> +   };
>> sound {
>> status = "okay";
>> };
>> --
>> 1.9.1
>
> Feel free to merge in this patch:
>
> https://github.com/RobertCNelson/armv7_devel/blob/v3.15.x-sama5-armv7/patches/drm/0005-atmel-dt-Add-supports-for-the-lcdc-support-on-the-sa.patch
>
Thanks for the patch.
> With this commit..
>
> All tested with sama5d31/33/34/36ek board's..

and many thanks for the testing.

>
> Regards,
>
> --
> Robert Nelson
> http://www.rcn-ee.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] smc91x: fix compile error when SMC_DEBUG >= 2

[Zi Shen Lim]

Hi Joe,

On Fri, Apr 18, 2014 at 09:06:53PM -0700, Joe Perches wrote:
> On Fri, 2014-04-18 at 20:47 -0700, Zi Shen Lim wrote:
> > When SMC_DEBUG >= 2, we hit the following compilation error:
> > 
> > drivers/net/ethernet/smsc/smc91x.c:85:0:
> > drivers/net/ethernet/smsc/smc91x.c: In function ‘smc_findirq’:
> > drivers/net/ethernet/smsc/smc91x.c:1784:9: error: ‘dev’ undeclared (first 
> > use in this function)
> >   DBG(2, dev, "%s: %s\n", CARDNAME, __func__);
> >  ^
> > Fix it by passing in the appropriate netdev pointer.
> 
> Perhaps verifying the format and args in all cases
> would help avoid more of these in the future.

Sounds good. I can add it as the second patch in the series.

> ---
>  drivers/net/ethernet/smsc/smc91x.c | 25 +++--
>  1 file changed, 15 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/net/ethernet/smsc/smc91x.c 
> b/drivers/net/ethernet/smsc/smc91x.c
> index d1b4dca..a8302f5 100644
> --- a/drivers/net/ethernet/smsc/smc91x.c
> +++ b/drivers/net/ethernet/smsc/smc91x.c
> @@ -148,16 +148,19 @@ MODULE_ALIAS("platform:smc91x");
>  #define MII_DELAY1
>  
>  #if SMC_DEBUG > 0
> -#define DBG(n, dev, args...) \
> - do {\
> - if (SMC_DEBUG >= (n))   \
> - netdev_dbg(dev, args);  \
> - } while (0)
> -
> -#define PRINTK(dev, args...)   netdev_info(dev, args)
> +#define DBG(n, dev, fmt, ...)\
> +do { \
> + if (SMC_DEBUG >= (n))   \
> + netdev_dbg(dev, fmt, ##__VA_ARGS__);\
> +} while (0)
> +#define PRINTK(dev, fmt, ...)   netdev_info(dev, fmt, ##__VA_ARGS__)
>  #else
> -#define DBG(n, dev, args...)   do { } while (0)
> -#define PRINTK(dev, args...)   netdev_dbg(dev, args)
> +#define DBG(n, dev, fmt, ...)\
> +do { \
> + if (0)  \
> + netdev_dbg(dev, fmt, ##__VA_ARGS__);\
> +} while (0)
> +#define PRINTK(dev, fmt, ...)   netdev_dbg(dev, fmt, ##__VA_ARGS__)
>  #endif
>  
>  #if SMC_DEBUG > 3
> @@ -191,7 +194,9 @@ static void PRINT_PKT(u_char *buf, int length)
>   pr_cont("\n");
>  }
>  #else
> -#define PRINT_PKT(x...)  do { } while (0)
> +static inline void PRINT_PKT(u_char *buf, int length)
> +{
> +}
>  #endif
>  

How about the following?
Ok to add your Signed-off-by as well?

Thanks.

---
 drivers/net/ethernet/smsc/smc91x.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/smsc/smc91x.c 
b/drivers/net/ethernet/smsc/smc91x.c
index d1b4dca..796355a 100644
--- a/drivers/net/ethernet/smsc/smc91x.c
+++ b/drivers/net/ethernet/smsc/smc91x.c
@@ -147,18 +147,19 @@ MODULE_ALIAS("platform:smc91x");
  */
 #define MII_DELAY  1
 
-#if SMC_DEBUG > 0
-#define DBG(n, dev, args...)   \
-   do {\
-   if (SMC_DEBUG >= (n))   \
-   netdev_dbg(dev, args);  \
+#define DBG(n, dev, fmt, ...)  \
+   do {\
+   if (SMC_DEBUG >= (n))   \
+   netdev_dbg(dev, fmt, ##__VA_ARGS__);\
} while (0)
 
-#define PRINTK(dev, args...)   netdev_info(dev, args)
-#else
-#define DBG(n, dev, args...)   do { } while (0)
-#define PRINTK(dev, args...)   netdev_dbg(dev, args)
-#endif
+#define PRINTK(dev, fmt, ...)  \
+   do {\
+   if (SMC_DEBUG > 0)  \
+   netdev_info(dev, fmt, ##__VA_ARGS__);   \
+   else\
+   netdev_dbg(dev, fmt, ##__VA_ARGS__);\
+   } while (0)
 
 #if SMC_DEBUG > 3
 static void PRINT_PKT(u_char *buf, int length)
@@ -191,7 +192,7 @@ static void PRINT_PKT(u_char *buf, int length)
pr_cont("\n");
 }
 #else
-#define PRINT_PKT(x...)  do { } while (0)
+static inline void PRINT_PKT(u_char *buf, int length) { }
 #endif
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git pull] drm fixes

[Alex Deucher]

On Sat, Apr 19, 2014 at 3:03 PM, Markus Trippelsdorf
 wrote:
> On 2014.04.19 at 08:19 +0100, Dave Airlie wrote:
>>
>> Unfortunately this contains no easter eggs, its a bit larger than I'd
>> like, but I included a patch that just moves code from one file to another
>> and I'd like to avoid merge conflicts with that later, so it makes it seem
>> worse than it is,
>
>> Christian König (2):
>>   drm/radeon: apply more strict limits for PLL params v2
>>   drm/radeon: improve PLL params if we don't match exactly v2
>
> commit f8a2645ecede4eaf90b3d785f2805c8ecb76d43e
> Author: Christian König 
> Date:   Wed Apr 16 11:54:21 2014 +0200
>
> drm/radeon: improve PLL params if we don't match exactly v2
>
> The commit above causes my monitor to just stay blank after boot.
> No framebuffer, no Xorg, no nothing. I'm using a Radeon RS780.

Can you try the patch on:
https://bugs.freedesktop.org/show_bug.cgi?id=77673

Alex

>
>
> Apr 19 20:55:45 x4 kernel: Serial: 8250/16550 driver, 4 ports, IRQ sharing 
> disabled
> Apr 19 20:55:45 x4 kernel: [drm] Initialized drm 1.1.0 20060810
> Apr 19 20:55:45 x4 kernel: [drm] radeon kernel modesetting enabled.
> Apr 19 20:55:45 x4 kernel: [drm] initializing kernel modesetting (RS780 
> 0x1002:0x9614 0x1043:0x834D).
> Apr 19 20:55:45 x4 kernel: [drm] register mmio base: 0xFBEE
> Apr 19 20:55:45 x4 kernel: [drm] register mmio size: 65536
> Apr 19 20:55:45 x4 kernel: ATOM BIOS: 113
> Apr 19 20:55:45 x4 kernel: radeon :01:05.0: VRAM: 128M 0xC000 
> - 0xC7FF (128M used)
> Apr 19 20:55:45 x4 kernel: radeon :01:05.0: GTT: 512M 0xA000 
> - 0xBFFF
> Apr 19 20:55:45 x4 kernel: [drm] Detected VRAM RAM=128M, BAR=128M
> Apr 19 20:55:45 x4 kernel: [drm] RAM width 32bits DDR
> Apr 19 20:55:45 x4 kernel: [TTM] Zone  kernel: Available graphics memory: 
> 4083362 kiB
> Apr 19 20:55:45 x4 kernel: [TTM] Zone   dma32: Available graphics memory: 
> 2097152 kiB
> Apr 19 20:55:45 x4 kernel: [TTM] Initializing pool allocator
> Apr 19 20:55:45 x4 kernel: [TTM] Initializing DMA pool allocator
> Apr 19 20:55:45 x4 kernel: [drm] radeon: 128M of VRAM memory ready
> Apr 19 20:55:45 x4 kernel: [drm] radeon: 512M of GTT memory ready.
> Apr 19 20:55:45 x4 kernel: [drm] Loading RS780 Microcode
> Apr 19 20:55:45 x4 kernel: == power state 0 ==
> Apr 19 20:55:45 x4 kernel:  ui class: none
> Apr 19 20:55:45 x4 kernel:  internal class: boot
> Apr 19 20:55:45 x4 kernel:  caps: video
> Apr 19 20:55:45 x4 kernel:  uvdvclk: 0 dclk: 0
> Apr 19 20:55:45 x4 kernel:  power level 0sclk: 5 
> vddc_index: 2
> Apr 19 20:55:45 x4 kernel:  power level 1sclk: 5 
> vddc_index: 2
> Apr 19 20:55:45 x4 kernel:  status: c r b
> Apr 19 20:55:45 x4 kernel: == power state 1 ==
> Apr 19 20:55:45 x4 kernel:  ui class: performance
> Apr 19 20:55:45 x4 kernel:  internal class: none
> Apr 19 20:55:45 x4 kernel:  caps: video
> Apr 19 20:55:45 x4 kernel:  uvdvclk: 0 dclk: 0
> Apr 19 20:55:45 x4 kernel:  power level 0sclk: 5 
> vddc_index: 1
> Apr 19 20:55:45 x4 kernel:  power level 1sclk: 7 
> vddc_index: 2
> Apr 19 20:55:45 x4 kernel:  status:
> Apr 19 20:55:45 x4 kernel: == power state 2 ==
> Apr 19 20:55:45 x4 kernel:  ui class: none
> Apr 19 20:55:45 x4 kernel:  internal class: uvd
> Apr 19 20:55:45 x4 kernel:  caps: video
> Apr 19 20:55:45 x4 kernel:  uvdvclk: 53300 dclk: 4
> Apr 19 20:55:45 x4 kernel:  power level 0sclk: 5 
> vddc_index: 1
> Apr 19 20:55:45 x4 kernel:  power level 1sclk: 5 
> vddc_index: 1
> Apr 19 20:55:45 x4 kernel:  status:
> Apr 19 20:55:45 x4 kernel: [drm] radeon: dpm initialized
> Apr 19 20:55:45 x4 kernel: [drm] GART: num cpu pages 131072, num gpu pages 
> 131072
> Apr 19 20:55:45 x4 kernel: [drm] PCIE GART of 512M enabled (table at 
> 0xC004).
> Apr 19 20:55:45 x4 kernel: radeon :01:05.0: WB enabled
> Apr 19 20:55:45 x4 kernel: radeon :01:05.0: fence driver on ring 0 use 
> gpu addr 0xac00 and cpu addr 0x8800db8d0c00
> Apr 19 20:55:45 x4 kernel: [drm] Supports vblank timestamp caching Rev 2 
> (21.10.2013).
> Apr 19 20:55:45 x4 kernel: [drm] Driver supports precise vblank timestamp 
> query.
> Apr 19 20:55:45 x4 kernel: [drm] radeon: irq initialized.
> Apr 19 20:55:45 x4 kernel: [drm] ring test on 0 succeeded in 1 usecs
> Apr 19 20:55:45 x4 kernel: [drm] ib test on ring 0 succeeded in 0 usecs
> Apr 19 20:55:45 x4 kernel: [drm] Radeon Display Connectors
> Apr 19 20:55:45 x4 kernel: [drm] Connector 0:
> Apr 19 20:55:45 x4 kernel: [drm]   VGA-1
> Apr 19 20:55:45 x4 kernel: [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 
> 0x7e48 0x7e4c 0x7e4c
> Apr 19 20:55:45 x4 kernel: [drm]   Encoders:
> Apr 19 20:55:45 x4 kernel: [drm] CRT1: INTERNAL_KLDSCP_DAC1
> Apr 19 20:55:45 x4 kernel: [drm] Connector 1:
> Apr 19 20:55:45 x4 

Re: [tip:x86/efi] x86/efi: Save and restore FPU context around efi_calls (x86_64)

[Borislav Petkov]

On Sat, Apr 19, 2014 at 03:50:44PM -0700, tip-bot for Ricardo Neri wrote:
> Commit-ID:  de05764e0b2a3d9559e099a2e134f8cef4500fdd
> Gitweb: http://git.kernel.org/tip/de05764e0b2a3d9559e099a2e134f8cef4500fdd
> Author: Ricardo Neri 
> AuthorDate: Thu, 27 Mar 2014 15:10:42 -0700
> Committer:  Matt Fleming 
> CommitDate: Thu, 17 Apr 2014 13:26:32 +0100
> 
> x86/efi: Save and restore FPU context around efi_calls (x86_64)
> 
> Do a complete FPU context save/restore around the EFI calls. This required
> as runtime EFI firmware may potentially use the FPU.
> 
> This change covers only the x86_64 configuration.
> 
> Signed-off-by: Ricardo Neri 
> Cc: Borislav Petkov 
> Signed-off-by: Matt Fleming 
> ---
>  arch/x86/include/asm/efi.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
> index 19292e7..0b19187 100644
> --- a/arch/x86/include/asm/efi.h
> +++ b/arch/x86/include/asm/efi.h
> @@ -1,6 +1,7 @@
>  #ifndef _ASM_X86_EFI_H
>  #define _ASM_X86_EFI_H
>  
> +#include 
>  /*
>   * We map the EFI regions needed for runtime services non-contiguously,
>   * with preserved alignment on virtual addresses starting from -4G down
> @@ -54,7 +55,9 @@ extern u64 asmlinkage efi_call(void *fp, ...);
>   \
>   efi_sync_low_kernel_mappings(); \
>   preempt_disable();  \
> + __kernel_fpu_begin();   \
>   __s = efi_call((void *)efi.systab->runtime->f, __VA_ARGS__);\
> + __kernel_fpu_end(); \
>   preempt_enable();   \

I guess you can use the kernel_fpu_begin/end() variants here (i.e.,
without the "__") which disable and enable preemption and thus drop the
preempt_* calls:

efi_sync_low_kernel_mappings();
kernel_fpu_begin();
 __s = efi_call((void *)efi.systab->runtime->f, __VA_ARGS__);
 kernel_fpu_end();
 __s;

I'm not sure about the

WARN_ON_ONCE(!irq_fpu_usable());

thing in kernel_fpu_begin() though, I guess it wouldn't hurt...

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 9/9 V2] idr: remove useless C-PreProcessor branch

[Tejun Heo]

$SUBJ: idr: remove useless #ifndef TEST

On Sat, Apr 19, 2014 at 07:38:16PM +0800, Lai Jiangshan wrote:
> "#ifndef TEST" can't work for user space test now, just remove it.
> 
> Signed-off-by: Lai Jiangshan 

Acked-by: Tejun Heo 

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] tracing:Do not profile dumpstack utilities to fix stack trace output

[Jiaxing Wang]

On 04/19/2014 11:18 PM, Steven Rostedt wrote:
> On Sat, 19 Apr 2014 15:45:46 +0800
> Jiaxing Wang  wrote:
> 
>> When function_graph tracer is enabled, we get stack trace like this:
>>
>>  DepthSize   Location(88 entries)
>>  -   
>>0) 3232   0   update_curr+0xe/0x1e0
>>1) 3232   0   dump_trace+0xb5/0x1b0
>>2) 3232   0   ftrace_ops_list_func+0xe6/0x100
>>3) 3232  68   ftrace_call+0x5/0xb
>>4) 3164  92   enqueue_entity+0x38/0xe20
>>5) 3072   0   return_to_handler+0x0/0xf
>>6) 3072  80   save_stack_trace+0x30/0x50
>>7) 2992   0   return_to_handler+0x0/0xf
>>8) 2992  28   stack_trace_call+0x119/0x340
>>9) 2964   0   return_to_handler+0x0/0xf
>>   10) 2964  12   enqueue_task_fair+0x47/0x7e0
>>   11) 2952   0   return_to_handler+0x0/0xf
>>   12) 2952  16   enqueue_task+0x45/0x70
>>   ... ...
>>
>> The 'save_stack_trace+0x30/0x50' and 'stack_trace_call+0x119/0x340'
>> entries are misplaced below the ftrace_ops_list_func and ftrace_call entries,
>> which looks very confusing.
>>
>> And dump_stack() is also affected when function_graph tracer is enabled:
>>
>>   [  425.353391] Call Trace:
>>   [  425.353449]  [] ftrace_graph_caller+0x19/0x19
>>   [  425.353496]  [] print_context_stack+0xc6/0xd0
>>   [  425.353547]  [] enqueue_entity+0x894/0xe60
>>   [  425.353597]  [] ? enqueue_task+0x45/0x70
>>   [  425.353649]  [] ? enqueue_task_fair+0x9/0x7e0
>>   [  425.353694]  [] ? enqueue_task+0x45/0x70
>>   [  425.353743]  [] ? prepare_ftrace_return+0x77/0xa0
>>   [  425.353791]  [] ? enqueue_task_fair+0x9/0x7e0
>>   [  425.353856]  [] ftrace_graph_caller+0x19/0x19
>>   [  425.353901]  [] dump_trace+0xb5/0x1b0
>>   [  425.353958]  [] ? enqueue_task+0x5d/0x70
>>   [  425.354002]  [] ? update_rq_clock.part.80+0x6/0x50
>>   [  425.354074]  [] ftrace_graph_caller+0x19/0x19
>>   [  425.354120]  [] show_trace_log_lvl+0x46/0x50
>>   [  425.354178]  [] ftrace_graph_caller+0x19/0x19
>>   [  425.354222]  [] show_stack_log_lvl+0x52/0xe0
>>   [  425.354272]  [] ftrace_graph_caller+0x19/0x19
>>   [  425.354317]  [] show_stack+0x26/0x50
>>   [  425.354369]  [] ftrace_graph_caller+0x19/0x19
>>   [  425.354415]  [] dump_stack+0x41/0x52
>>   [  425.354483]  [] ftrace_graph_caller+0x19/0x19
>>   [  425.354527]  [] enqueue_task_fair+0x47/0x7e0
>>   [  425.354576]  [] ftrace_graph_caller+0x19/0x19
>>   [  425.354621]  [] enqueue_task+0x45/0x70
>>   ... ...
>>
>> This happens because the functions in the route of stack_trace and
>> dump_stack() get function_graph traced, their return addresses on stack are
>> replaced by 'return_to_handler' and their real return addresses are
>> saved in current->ret_stack[].(Specifically, these functons include
>> save_stack_trace,dump_trace,print_context_stack,print_ftrace_graph_addr
>> in the case of stack_trace and 
>> show_stack,show_stack_log_lvl,show_trace_log_lvl
>> ,dump_trace,print_context_stack,print_ftrace_graph_addr in the case of
>> dump_stack()).
>>
>> When dumping the stack, their 'return_to_handler' on stack are skipped
>> but not their corresponding current->ret_stack entries which then are matched
>> with other function's 'return_to_handler' on the stack and resulting the
>> wrong output above.
> 
> This sounds like a separate bug that should be fixed.
> 
Return addresses are skipped as stack_trace dump stack from the return
address of dump_trace() and dump_stack() dump stack from the return address
of show_stack().

Here is the stack_trace case:
  stack   current->ret_stack[]
  -   
  return_to_handler   print_context_stack+0xc6/0xd0
  return_to_handler   dump_trace+0xb5/0x1b0
  return_to_handler   save_stack_trace+0x30/0x50
  return_to_handler   stack_trace_call+0x119/0x340
  ftrace_ops_listfunc+0xe6/0x100
  ftrace_call+0x5/0xb

So when dump, the first two 'return_to_handler' entries are skipped but
not the current->ret_stack[] entries.

And the following is the dump_stack() case:

  stack   current->ret_stack[]
  -   
  return_to_handler   print_context_stack+0xc6/0xd0
  return_to_handler   dump_trace+0xb5/0x1b0
  return_to_handler   show_trace_log_lvl+0x46/0x50
  return_to_handler   show_stack_log_lvl+0x52/0xe0
  return_to_handler   show_stack+0x26/0x50
  return_to_handler   dump_stack+0x41/0x52

In this case the first five 'return_to_handler' entries on stack are
skipped but not the current->ret_stack[] entries.

So the problem is caused by dumpstack utilities get traced by function_graph
tracer, and disable the profiling of them fixes this.

Thanks.
>>
>> To fix this, we can disable the 

Re: [PATCH 5/9 V2] idr: covert BUG_ON() to WARN_ON_ONCE() if the argument is invalid.

[Tejun Heo]

Hello,

On Sat, Apr 19, 2014 at 10:04:06PM +0800, Lai Jiangshan wrote:
> On Sat, Apr 19, 2014 at 9:07 PM, Tejun Heo  wrote:
> WARN_ON_ONCE() for invalid id (negative id).
> idr_remove_warning() for unallocated id.

I don't know.  Seem like an unnecessary distinction.

> >> @@ -1030,6 +1030,9 @@ void ida_remove(struct ida *ida, int id)
> >>   int n;
> >>   struct ida_bitmap *bitmap;
> >>
> >> + if (WARN_ON_ONCE(id < 0))
> >> + return;
> >
> > Why not jump to err?
> 
> WARN_ON_ONCE() for invalid id (negative id).
> "goto err" for unallocated id.

Ditto.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] KVM: x86: Check for host supported fields in shadow vmcs

[Bandan Das]

We track shadow vmcs fields through two static lists,
one for read only fields and another for r/w. However, with
addition of new vmcs fields, not all fields may be supported on
all hosts. If so, copy_vmcs12_to_shadow() trying to vmwrite on older
hosts will result in a vmwrite error. For example, commit
36be0b9deb23161 introduced GUEST_BNDCFGS, which is not supported
for all processors. Create new lists based out of intersection of
static lists and host support and use them for tracking
shadow fields instead

Signed-off-by: Bandan Das 
---
 arch/x86/kvm/vmx.c | 98 +++---
 1 file changed, 79 insertions(+), 19 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 7bed3e3..ffc2232 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -502,7 +502,10 @@ static inline struct vcpu_vmx *to_vmx(struct kvm_vcpu 
*vcpu)
 #define FIELD64(number, name)  [number] = VMCS12_OFFSET(name), \
[number##_HIGH] = VMCS12_OFFSET(name)+4
 
-
+/*
+ * Do not use the two lists below directly
+ * Use vmcs_shadow_fields instead
+ */
 static const unsigned long shadow_read_only_fields[] = {
/*
 * We do NOT shadow fields that are modified when L0
@@ -526,8 +529,6 @@ static const unsigned long shadow_read_only_fields[] = {
GUEST_LINEAR_ADDRESS,
GUEST_PHYSICAL_ADDRESS
 };
-static const int max_shadow_read_only_fields =
-   ARRAY_SIZE(shadow_read_only_fields);
 
 static const unsigned long shadow_read_write_fields[] = {
GUEST_RIP,
@@ -558,8 +559,18 @@ static const unsigned long shadow_read_write_fields[] = {
HOST_FS_SELECTOR,
HOST_GS_SELECTOR
 };
-static const int max_shadow_read_write_fields =
-   ARRAY_SIZE(shadow_read_write_fields);
+
+/* If new shadow fields are added, these should be modified appropriately */
+#define VMCS_MAX_RO_FIELDS 10
+#define VMCS_MAX_RW_FIELDS 30
+
+struct vmcs_shadow_fields_data {
+   int shadow_ro_fields_len;
+   int shadow_rw_fields_len;
+   unsigned long shadow_read_only_fields[VMCS_MAX_RO_FIELDS];
+   unsigned long shadow_read_write_fields[VMCS_MAX_RW_FIELDS];
+};
+static struct vmcs_shadow_fields_data vmcs_shadow_fields;
 
 static const unsigned short vmcs_field_to_offset_table[] = {
FIELD(VIRTUAL_PROCESSOR_ID, virtual_processor_id),
@@ -3027,6 +3038,56 @@ static __init int alloc_kvm_area(void)
return 0;
 }
 
+static void cleanup_vmcs_shadow_fields(void)
+{
+   memset(_shadow_fields, 0,
+  sizeof(struct vmcs_shadow_fields_data));
+}
+
+static void init_vmcs_shadow_fields(void)
+{
+   struct vmcs_shadow_fields_data *vmcs_ptr = _shadow_fields;
+   int max_shadow_read_write_fields = ARRAY_SIZE(shadow_read_write_fields);
+   int max_shadow_read_only_fields = ARRAY_SIZE(shadow_read_only_fields);
+   int i, j;
+
+   for (i = 0, j = 0; i < max_shadow_read_write_fields; i++) {
+   if (i >= VMCS_MAX_RW_FIELDS) {
+   WARN(1, "Shadow RW fields index out of bounds\n");
+   break;
+   }
+   if ((shadow_read_write_fields[i] == GUEST_BNDCFGS) &&
+   !vmx_mpx_supported())
+   continue;
+   vmcs_ptr->shadow_read_write_fields[j++] =
+   shadow_read_write_fields[i];
+   vmcs_ptr->shadow_rw_fields_len++;
+   }
+
+   for (i = 0, j = 0; i < max_shadow_read_only_fields; i++) {
+   if (i >= VMCS_MAX_RO_FIELDS) {
+   WARN(1, "Shadow RO fields index out of bounds\n");
+   break;
+   }
+   vmcs_ptr->shadow_read_only_fields[j++] =
+   shadow_read_only_fields[i];
+   vmcs_ptr->shadow_ro_fields_len++;
+   }
+
+   /* shadowed read/write fields */
+   for (i = 0; i < vmcs_ptr->shadow_rw_fields_len; i++) {
+   clear_bit(vmcs_ptr->shadow_read_write_fields[i],
+ vmx_vmwrite_bitmap);
+   clear_bit(vmcs_ptr->shadow_read_write_fields[i],
+ vmx_vmread_bitmap);
+   }
+   /* shadowed read only fields */
+   for (i = 0; i < vmcs_ptr->shadow_ro_fields_len; i++)
+   clear_bit(vmcs_ptr->shadow_read_only_fields[i],
+ vmx_vmread_bitmap);
+
+}
+
 static __init int hardware_setup(void)
 {
if (setup_vmcs_config(_config) < 0)
@@ -3039,6 +3100,8 @@ static __init int hardware_setup(void)
enable_vpid = 0;
if (!cpu_has_vmx_shadow_vmcs())
enable_shadow_vmcs = 0;
+   if (enable_shadow_vmcs)
+   init_vmcs_shadow_fields();
 
if (!cpu_has_vmx_ept() ||
!cpu_has_vmx_ept_4levels()) {
@@ -3084,6 +3147,8 @@ static __init int hardware_setup(void)
 
 static __exit void hardware_unsetup(void)
 {
+   if (enable_shadow_vmcs)
+   

Re: [PATCH] coredump: fix va_list corruption

[Neil Horman]

On Sat, Apr 19, 2014 at 10:15:07AM -0700, Eric Dumazet wrote:
> From: Eric Dumazet 
> 
> A va_list needs to be copied in case it needs to be used twice.
> 
> Thanks to Hugh for debugging this issue, leading to various panics.
> 
> Tested:
> 
> lpq84:~# echo "|/foobar12345 %h %h %h %h %h %h %h %h %h %h %h %h %h %h %
> h %h %h %h %h %h" >/proc/sys/kernel/core_pattern
> 
> 'produce_core' is simply : main() { *(int *)0 = 1;}
> 
> lpq84:~# ./produce_core
> Segmentation fault (core dumped)
> lpq84:~# dmesg | tail -1
> [  614.352947] Core dump to |/foobar12345 lpq84 lpq84 lpq84 lpq84 lpq84
> lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84
> lpq84 lpq84 (null) pipe failed
> 
> Notice the last argument was replaced by a NULL (we were lucky enough to
> not crash, but do not try this on your production machine !)
> 
> After fix :
> 
> lpq83:~# echo "|/foobar12345 %h %h %h %h %h %h %h %h %h %h %h %h %h %h %
> h %h %h %h %h %h" >/proc/sys/kernel/core_pattern
> lpq83:~# ./produce_core
> Segmentation fault
> lpq83:~# dmesg | tail -1
> [  740.800441] Core dump to |/foobar12345 lpq83 lpq83 lpq83 lpq83 lpq83
> lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83
> lpq83 lpq83 lpq83 pipe failed
> 
> Fixes: 5fe9d8ca21cc ("coredump: cn_vprintf() has no reason to call 
> vsnprintf() twice")
> Signed-off-by: Eric Dumazet 
> Diagnosed-by: Hugh Dickins 
> Cc: Oleg Nesterov 
> Cc: Neil Horman 
> Cc: Andrew Morton 
> Cc: sta...@vger.kernel.org # 3.11+
> ---
> 
> Note: This patch applies cleanly to 3.11+ but might need some
> adjustments for older linux kernels...
> 
>  fs/coredump.c |7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/coredump.c b/fs/coredump.c
> index e3ad709a4232..0b2528fb640e 100644
> --- a/fs/coredump.c
> +++ b/fs/coredump.c
> @@ -73,10 +73,15 @@ static int expand_corename(struct core_name *cn, int size)
>  static int cn_vprintf(struct core_name *cn, const char *fmt, va_list arg)
>  {
>   int free, need;
> + va_list arg_copy;
>  
>  again:
>   free = cn->size - cn->used;
> - need = vsnprintf(cn->corename + cn->used, free, fmt, arg);
> +
> + va_copy(arg_copy, arg);
> + need = vsnprintf(cn->corename + cn->used, free, fmt, arg_copy);
> + va_end(arg_copy);
> +
>   if (need < free) {
>   cn->used += need;
>   return 0;
> 
> 
> 

Thanks Eric!
Acked-by: Neil Horman 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] RTC: rtc-cmos: drivers/char/rtc.c features for DECstation support

[Maciej W. Rozycki]

This brings in drivers/char/rtc.c functionality required for DECstation 
and, should the maintainers decide to switch, Alpha systems to use 
rtc-cmos.

Specifically these features are made available:

* RTC iomem rather than x86/PCI port I/O mapping, controlled with the 
  RTC_IOMAPPED macro as with the original driver.  The DS1287A chip in all 
  DECstation systems is mapped in the host bus address space as a 
  contiguous block of 64 32-bit words of which the least significant byte 
  accesses the RTC chip for both reads and writes.  All the address and 
  data window register accesses are made transparently by the chipset glue 
  logic so that the device appears directly mapped on the host bus.

* A way to set the size of the address space explicitly with the 
  newly-added `address_space' member of the platform part of the RTC 
  device structure.  This avoids the unreliable heuristics that does not 
  work in a setup where the RTC is not explicitly accessed with the usual 
  address and data window register pair.

* The ability to use the RTC periodic interrupt as a system clock device,
  which is implemented by arch/mips/kernel/cevt-ds1287.c for DECstation 
  systems and takes the RTC interrupt away from the RTC driver.  
  Eventually hooking back to the clock device's interrupt handler should 
  be possible for the purpose of the alarm clock and possibly also 
  update-in-progress interrupt, but this is not done by this change.

  o To avoid interfering with the clock interrupt all the places where the 
RTC interrupt mask is fiddled with are only executed if and IRQ has 
been assigned to the RTC driver.

  o To avoid changing the clock setup Register A is not fiddled with if 
CMOS_RTC_FLAGS_NOFREQ is set in the newly-added `flags' member of the 
platform part of the RTC device structure.  Originally, in 
drivers/char/rtc.c, this was keyed with the absence of the RTC 
interrupt, just like the interrupt mask, but there only the periodic 
interrupt frequency is set, whereas rtc-cmos also sets the divider 
bits.  Therefore a new flag is introduced so that systems where the 
RTC interrupt is not usable rather than used as a system clock device 
can fully initialise the RTC.

* A small clean-up is made to the IRQ assignment code that makes the IRQ 
  number hardcoded to -1 rather than arbitrary -ENXIO (or whatever error 
  happens to be returned by platform_get_irq) where no IRQ has been 
  assigned to the RTC driver (NO_IRQ might be another candidate, but it 
  looks like this macro has inconsistent or missing definitions and 
  limited use and might therefore be unsafe).

Verified to work correctly with a DECstation 5000/240 system.

Signed-off-by: Maciej W. Rozycki 
---
Alessandro,

 Please apply or otherwise let me know if you have any issues with this 
proposal.

 Thanks,

  Maciej

linux-rtc-cmos-dec.patch
Index: linux-20140404-3maxp/drivers/rtc/rtc-cmos.c
===
--- linux-20140404-3maxp.orig/drivers/rtc/rtc-cmos.c
+++ linux-20140404-3maxp/drivers/rtc/rtc-cmos.c
@@ -647,6 +647,7 @@ cmos_do_probe(struct device *dev, struct
int retval = 0;
unsigned char   rtc_control;
unsignedaddress_space;
+   u32 flags = 0;
 
/* there can be only one ... */
if (cmos_rtc.dev)
@@ -660,9 +661,12 @@ cmos_do_probe(struct device *dev, struct
 * REVISIT non-x86 systems may instead use memory space resources
 * (needing ioremap etc), not i/o space resources like this ...
 */
-   ports = request_region(ports->start,
-   resource_size(ports),
-   driver_name);
+   if (RTC_IOMAPPED)
+   ports = request_region
+   (ports->start, resource_size(ports), driver_name);
+   else
+   ports = request_mem_region
+   (ports->start, resource_size(ports), driver_name);
if (!ports) {
dev_dbg(dev, "i/o registers already in use\n");
return -EBUSY;
@@ -699,6 +703,11 @@ cmos_do_probe(struct device *dev, struct
 * expect CMOS_READ and friends to handle.
 */
if (info) {
+   if (info->flags)
+   flags = info->flags;
+   if (info->address_space)
+   address_space = info->address_space;
+
if (info->rtc_day_alarm && info->rtc_day_alarm < 128)
cmos_rtc.day_alrm = info->rtc_day_alarm;
if (info->rtc_mon_alarm && info->rtc_mon_alarm < 128)
@@ -726,18 +735,21 @@ cmos_do_probe(struct device *dev, struct
 
spin_lock_irq(_lock);
 
-   /* force periodic irq to CMOS reset default of 1024Hz;
-*
-* REVISIT it's been reported that at least one x86_64 ALI mobo
-* doesn't 

[PATCH 2/2] DEC: Switch DECstation systems to rtc-cmos

[Maciej W. Rozycki]

This adds an RTC platform device for DECstation systems so that they can 
use the rtc-cmos driver for their RTC device.

Signed-off-by: Maciej W. Rozycki 
---
Ralf,

 This part requires the other change or it won't build at all, so it can't 
be pushed to the LMO tree by itself.  I'm not sure which route, either RTC 
or LMO, will be the best for upstreaming this patch pair, but surely the 
rtc-cmos part will have to be reviewed first.

  Maciej

linux-dec-rtc.patch
Index: linux-20140404-3maxp/arch/mips/dec/Makefile
===
--- linux-20140404-3maxp.orig/arch/mips/dec/Makefile
+++ linux-20140404-3maxp/arch/mips/dec/Makefile
@@ -3,7 +3,7 @@
 #
 
 obj-y  := ecc-berr.o int-handler.o ioasic-irq.o kn01-berr.o \
-  kn02-irq.o kn02xa-berr.o reset.o setup.o time.o
+  kn02-irq.o kn02xa-berr.o platform.o reset.o setup.o time.o
 
 obj-$(CONFIG_TC)   += tc.o
 obj-$(CONFIG_CPU_HAS_WB)   += wbflush.o
Index: linux-20140404-3maxp/arch/mips/dec/platform.c
===
--- /dev/null
+++ linux-20140404-3maxp/arch/mips/dec/platform.c
@@ -0,0 +1,44 @@
+/*
+ * DEC platform devices.
+ *
+ * Copyright (c) 2014  Maciej W. Rozycki
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static struct resource dec_rtc_resources[] = {
+   {
+   .name = "rtc",
+   .flags = IORESOURCE_MEM,
+   },
+};
+
+static struct cmos_rtc_board_info dec_rtc_info = {
+   .flags = CMOS_RTC_FLAGS_NOFREQ,
+   .address_space = 64,
+};
+
+static struct platform_device dec_rtc_device = {
+   .name = "rtc_cmos",
+   .id = PLATFORM_DEVID_NONE,
+   .dev.platform_data = _rtc_info,
+   .resource = dec_rtc_resources,
+   .num_resources = ARRAY_SIZE(dec_rtc_resources),
+};
+
+static int __init dec_add_devices(void)
+{
+   dec_rtc_resources[0].start = RTC_PORT(0);
+   dec_rtc_resources[0].end = RTC_PORT(0) + dec_kn_slot_size - 1;
+   return platform_device_register(_rtc_device);
+}
+
+device_initcall(dec_add_devices);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] EFI changes for v3.16

[H. Peter Anvin]

On 04/19/2014 03:06 AM, Matt Fleming wrote:
> Hi folks,
> 
> Please pull the following changes for v3.16. I'd like to get these in
> early so that they've got plenty of time to bake in linux-next. In
> particular, the ARM folks have had a hard time getting the generic EFI
> cleanups/improvements picked up via other trees.
> 
> Obviously by taking these through tip we're creating a dependency with
> whatever tree the ARM patches live in. Do we need to inform Stephen
> Rothwell explicitly of this dependency? How should we handle things when
> the v3.16 merge window opens?
> 

It doesn't hurt to inform Stephen, although I think it will simply fall
out automatically since he uses git to merge and git will recognize the
graph.

During the merge window, it means they should not push their patches
until Linus has accepted the precondition patches from the tip tree.
Since Ingo and I try to push most of the tip tree as early as possible
in the merge window, this is usually not a problem.

-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] perf test x86: Fit memory leak in sample_ustack()

[Jiri Olsa]

On Sun, Apr 20, 2014 at 12:19:13AM +0200, Jiri Olsa wrote:
> On Sun, Apr 20, 2014 at 12:16:41AM +0900, Masanari Iida wrote:
> > buf is not freed, when kernel failed to get stack map
> > and return.
> > 
> > Signed-off-by: Masanari Iida 
> 
> Acked-by: Jiri Olsa 
> 
> thanks,
> jirka
> 
> > ---
> >  tools/perf/arch/x86/tests/dwarf-unwind.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/tools/perf/arch/x86/tests/dwarf-unwind.c 
> > b/tools/perf/arch/x86/tests/dwarf-unwind.c
> > index b602ad9..68f2711 100644
> > --- a/tools/perf/arch/x86/tests/dwarf-unwind.c
> > +++ b/tools/perf/arch/x86/tests/dwarf-unwind.c
> > @@ -26,6 +26,7 @@ static int sample_ustack(struct perf_sample *sample,
> > map = map_groups__find(>mg, MAP__FUNCTION, (u64) sp);
> > if (!map) {
> > pr_debug("failed to get stack map\n");
> > +   kfree(buf);

and changing this to free(buf) ;-)

jirka

> > return -1;
> > }
> >  
> > -- 
> > 1.9.2.468.g3f0c02a
> > 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] perf test x86: Fit memory leak in sample_ustack()

[Jiri Olsa]

On Sun, Apr 20, 2014 at 12:16:41AM +0900, Masanari Iida wrote:
> buf is not freed, when kernel failed to get stack map
> and return.
> 
> Signed-off-by: Masanari Iida 

Acked-by: Jiri Olsa 

thanks,
jirka

> ---
>  tools/perf/arch/x86/tests/dwarf-unwind.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/perf/arch/x86/tests/dwarf-unwind.c 
> b/tools/perf/arch/x86/tests/dwarf-unwind.c
> index b602ad9..68f2711 100644
> --- a/tools/perf/arch/x86/tests/dwarf-unwind.c
> +++ b/tools/perf/arch/x86/tests/dwarf-unwind.c
> @@ -26,6 +26,7 @@ static int sample_ustack(struct perf_sample *sample,
>   map = map_groups__find(>mg, MAP__FUNCTION, (u64) sp);
>   if (!map) {
>   pr_debug("failed to get stack map\n");
> + kfree(buf);
>   return -1;
>   }
>  
> -- 
> 1.9.2.468.g3f0c02a
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 3/3] KVM: nVMX: Advertise support for interrupt acknowledgement

[Bandan Das]

Some Type 1 hypervisors such as XEN won't enable VMX without it present

Signed-off-by: Bandan Das 
---
 arch/x86/kvm/vmx.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 5c0b74d..7bed3e3 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2283,7 +2283,7 @@ static __init void nested_vmx_setup_ctls_msrs(void)
rdmsr(MSR_IA32_VMX_EXIT_CTLS,
nested_vmx_exit_ctls_low, nested_vmx_exit_ctls_high);
nested_vmx_exit_ctls_low = VM_EXIT_ALWAYSON_WITHOUT_TRUE_MSR;
-   /* Note that guest use of VM_EXIT_ACK_INTR_ON_EXIT is not supported. */
+
nested_vmx_exit_ctls_high &=
 #ifdef CONFIG_X86_64
VM_EXIT_HOST_ADDR_SPACE_SIZE |
@@ -2291,7 +2291,8 @@ static __init void nested_vmx_setup_ctls_msrs(void)
VM_EXIT_LOAD_IA32_PAT | VM_EXIT_SAVE_IA32_PAT;
nested_vmx_exit_ctls_high |= VM_EXIT_ALWAYSON_WITHOUT_TRUE_MSR |
VM_EXIT_LOAD_IA32_EFER | VM_EXIT_SAVE_IA32_EFER |
-   VM_EXIT_SAVE_VMX_PREEMPTION_TIMER;
+   VM_EXIT_SAVE_VMX_PREEMPTION_TIMER | VM_EXIT_ACK_INTR_ON_EXIT;
+
if (vmx_mpx_supported())
nested_vmx_exit_ctls_high |= VM_EXIT_CLEAR_BNDCFGS;
 
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 2/3] KVM: nVMX: Ack and write vector info to intr_info if L1 asks us to

[Bandan Das]

This feature emulates the "Acknowledge interrupt on exit" behavior.
We can safely emulate it for L1 to run L2 even if L0 itself has it
disabled (to run L1).

Signed-off-by: Bandan Das 
---
 arch/x86/kvm/irq.c |  1 +
 arch/x86/kvm/vmx.c | 18 ++
 2 files changed, 19 insertions(+)

diff --git a/arch/x86/kvm/irq.c b/arch/x86/kvm/irq.c
index 484bc87..bd0da43 100644
--- a/arch/x86/kvm/irq.c
+++ b/arch/x86/kvm/irq.c
@@ -113,6 +113,7 @@ int kvm_cpu_get_interrupt(struct kvm_vcpu *v)
 
return kvm_get_apic_interrupt(v);   /* APIC */
 }
+EXPORT_SYMBOL_GPL(kvm_cpu_get_interrupt);
 
 void kvm_inject_pending_timer_irqs(struct kvm_vcpu *vcpu)
 {
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index ce8f6c4..5c0b74d 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -4526,6 +4526,16 @@ static bool nested_exit_on_intr(struct kvm_vcpu *vcpu)
PIN_BASED_EXT_INTR_MASK;
 }
 
+/*
+ * In nested virtualization, check if L1 has set
+ * VM_EXIT_ACK_INTR_ON_EXIT
+ */
+static bool nested_exit_intr_ack_set(struct kvm_vcpu *vcpu)
+{
+   return get_vmcs12(vcpu)->vm_exit_controls &
+   VM_EXIT_ACK_INTR_ON_EXIT;
+}
+
 static bool nested_exit_on_nmi(struct kvm_vcpu *vcpu)
 {
return get_vmcs12(vcpu)->pin_based_vm_exec_control &
@@ -8556,6 +8566,14 @@ static void nested_vmx_vmexit(struct kvm_vcpu *vcpu, u32 
exit_reason,
prepare_vmcs12(vcpu, vmcs12, exit_reason, exit_intr_info,
   exit_qualification);
 
+   if ((exit_reason == EXIT_REASON_EXTERNAL_INTERRUPT)
+   && nested_exit_intr_ack_set(vcpu)) {
+   int irq = kvm_cpu_get_interrupt(vcpu);
+   WARN_ON(irq < 0);
+   vmcs12->vm_exit_intr_info = irq |
+   INTR_INFO_VALID_MASK | INTR_TYPE_EXT_INTR;
+   }
+
trace_kvm_nested_vmexit_inject(vmcs12->vm_exit_reason,
   vmcs12->exit_qualification,
   vmcs12->idt_vectoring_info_field,
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 1/3] KVM: nVMX: Don't advertise single context invalidation for invept

[Bandan Das]

For single context invalidation, we fall through to global
invalidation in handle_invept() except for one case - when
the operand supplied by L1 is different from what we have in
vmcs12. However, typically hypervisors will only call invept
for the currently loaded eptp, so the condition will
never be true.

Signed-off-by: Bandan Das 
---
 arch/x86/kvm/vmx.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 1f68c58..ce8f6c4 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2353,12 +2353,11 @@ static __init void nested_vmx_setup_ctls_msrs(void)
 VMX_EPT_INVEPT_BIT;
nested_vmx_ept_caps &= vmx_capability.ept;
/*
-* Since invept is completely emulated we support both global
-* and context invalidation independent of what host cpu
-* supports
+* For nested guests, we don't do anything specific
+* for single context invalidation. Hence, only advertise
+* support for global context invalidation.
 */
-   nested_vmx_ept_caps |= VMX_EPT_EXTENT_GLOBAL_BIT |
-   VMX_EPT_EXTENT_CONTEXT_BIT;
+   nested_vmx_ept_caps |= VMX_EPT_EXTENT_GLOBAL_BIT;
} else
nested_vmx_ept_caps = 0;
 
@@ -6434,7 +6433,6 @@ static int handle_invept(struct kvm_vcpu *vcpu)
struct {
u64 eptp, gpa;
} operand;
-   u64 eptp_mask = ((1ull << 51) - 1) & PAGE_MASK;
 
if (!(nested_vmx_secondary_ctls_high & SECONDARY_EXEC_ENABLE_EPT) ||
!(nested_vmx_ept_caps & VMX_EPT_INVEPT_BIT)) {
@@ -6474,16 +6472,13 @@ static int handle_invept(struct kvm_vcpu *vcpu)
}
 
switch (type) {
-   case VMX_EPT_EXTENT_CONTEXT:
-   if ((operand.eptp & eptp_mask) !=
-   (nested_ept_get_cr3(vcpu) & eptp_mask))
-   break;
case VMX_EPT_EXTENT_GLOBAL:
kvm_mmu_sync_roots(vcpu);
kvm_mmu_flush_tlb(vcpu);
nested_vmx_succeed(vcpu);
break;
default:
+   /* Trap single context invalidation invept calls */
BUG_ON(1);
break;
}
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 0/3] nVMX: Fixes to run Xen as L1

[Bandan Das]

Minor changes to enable Xen as a L1 hypervisor.

Tested with a Haswell host, Xen-4.3 L1 and debian6 L2

v3:
* Add WARN_ON in nested_vmx_exit
* Rebase on top of 3.15-rc1
* Also noticed a new behavior which I think is related to 
  commit 36be0b9deb23161e KVM: x86: Add nested virtualization support for MPX
  On running L2, console gets filled up with - 
  vmwrite error: reg 2812 value 0 (err 12) ..
  I will post a separate patch to get feedback, since these three
  patches have probably addressed all of reviewers' concerns

v2: 
* Remove advertising single context invalidation for emulated invept
  Patch "KVM: nVMX: check for null vmcs12 when L1 does invept" from v1 
  is now obsolete and is removed
* Reorder patches "KVM: nVMX: Advertise support for interrupt acknowledgement"
  and "nVMX: Ack and write vector info to intr_info if L1 asks us to"
* Add commit description to 2/3 and change comment for nested_exit_intr_ack_set

Jan, I will send a separate unit-test patch

Bandan Das (3):
  KVM: nVMX: Don't advertise single context invalidation for invept
  KVM: nVMX: Ack and write vector info to intr_info if L1 asks us to
  KVM: nVMX: Advertise support for interrupt acknowledgement

 arch/x86/kvm/irq.c |  1 +
 arch/x86/kvm/vmx.c | 38 ++
 2 files changed, 27 insertions(+), 12 deletions(-)

-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mmc: mxs: fix card detection function for broken card detect

[Daniel Willmann]

Return -ENOSYS in get_cd if broken-cd is specified in the device tree.

Commit a91fe279ae75 (mmc: mxs: use standard flag for broken card
detection) sets MMC_CAP_NEEDS_POLL when broken-cd is specified. This
driver sets this flag unconditionally as it does not support a card
detect interrupt. Instead, broken-cd means that there is no card detect
signal connected.

The mmc core checks the get_cd function return value to determine if a
card is present. Only for a non-zero return value it will attempt to
initialize the card. So retuning -ENOSYS will allow the card to be
initialized.
For comparison, mmc_gpio_get_cd in slot-gpio.c also returns -ENOSYS if
the card detect GPIO is not valid.

Signed-off-by: Daniel Willmann 
---
This might be relevant for stable kernels. The patch was tested with 3.14.1 on
olinuxino nano.

 drivers/mmc/host/mxs-mmc.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/mmc/host/mxs-mmc.c b/drivers/mmc/host/mxs-mmc.c
index 073e871a0fc8..babfea03ba8a 100644
--- a/drivers/mmc/host/mxs-mmc.c
+++ b/drivers/mmc/host/mxs-mmc.c
@@ -70,6 +70,7 @@ struct mxs_mmc_host {
unsigned char   bus_width;
spinlock_t  lock;
int sdio_irq_en;
+   boolbroken_cd;
 };
 
 static int mxs_mmc_get_cd(struct mmc_host *mmc)
@@ -78,6 +79,9 @@ static int mxs_mmc_get_cd(struct mmc_host *mmc)
struct mxs_ssp *ssp = >ssp;
int present, ret;
 
+   if (host->broken_cd)
+   return -ENOSYS;
+
ret = mmc_gpio_get_cd(mmc);
if (ret >= 0)
return ret;
@@ -568,6 +572,7 @@ static int mxs_mmc_probe(struct platform_device *pdev)
 {
const struct of_device_id *of_id =
of_match_device(mxs_mmc_dt_ids, >dev);
+   struct device_node *np = pdev->dev.of_node;
struct mxs_mmc_host *host;
struct mmc_host *mmc;
struct resource *iores;
@@ -634,6 +639,8 @@ static int mxs_mmc_probe(struct platform_device *pdev)
mmc->caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED |
MMC_CAP_SDIO_IRQ | MMC_CAP_NEEDS_POLL;
 
+   host->broken_cd = of_property_read_bool(np, "broken-cd");
+
mmc->f_min = 40;
mmc->f_max = 28800;
 
-- 
1.8.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Humanitarian Project‎

[Michelle Starzynski]

I write you this email on behalf of Mrs. Margaret Crawford regards to her wish. 
She has decided to donate part of her inheritance to you for humanitarian work 
and your personal use. For more details contact her Attorney, Mark Lawson via 
email: mlaws...@rogers.com


This communication is intended for the use of the recipient to which it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recipient of this communication, and do not copy, distribute, or take action 
relying on it. Any communication received in error, or subsequent reply, should 
be deleted or destroyed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] memcg: mm_update_next_owner() should skip kthreads

[Hugh Dickins]

On Sat, 19 Apr 2014, Oleg Nesterov wrote:
> On 04/19, Pavel Machek wrote:
> >
> > > > Hmm. I seem to see a bug in this function, it can be fulled by use_mm,
> > > > but I am not sure this can explain the problem. I'll send a patch.
> > >
> > > Untested, please review. But it really looks "obviously wrong", and note
> > > that unuse_mm() doesn't do mm_update_next_owner(). (just in case, do not
> > > confuse it with unuse_mm() in mm/swapfile.c).
> >
> > Having two functions, one exported, one static with same name -- that
> > sounds quite evil, right?
> 
> Yes, agreed.

Doubly agreed; though it seems to have escaped causing confusion
for several years, so no great hurry to resolve it.

> 
> > mmu_context.c: * unuse_mm
> > mmu_context.c:void unuse_mm(struct mm_struct *mm)
> > mmu_context.c:EXPORT_SYMBOL_GPL(unuse_mm);
> > swapfile.c:static int unuse_mm(struct mm_struct *mm,
> 
> Yes, I was thinking about s/unuse_mm/unswap_mm/ change in swapfile.c,
> but then we should probaly rename other "unuse" functions there, and
> shmem_unuse/try_to_unuse are not static.

My preference is "swapoff" instead of "unuse" throughout there:
it saves having to explain that "unuse" implies "swapoff" each
time we send in a patch making a change to that code.

But I'd prefer you hold off for the moment: Kelley Nielsen is currently
preparing a patchset reworking try_to_unuse, and I suggested a few days
ago to include such renaming in that patchset.

Partly driven by s390's recent 45961722f8e3 "mm: add support for
discard of unused ptes" which adds further confusion with pte_unused().

Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] NVMe: Update namespace and controller identity structures as per 1.1a spec

[Dimitri John Ledkov]

Controller: add CNTLID, AVSCC, APSTA, NVSCC, ACWU, SGLS fields.

Namespace: add NMIC, RESCAP, EUI64 fields. EUI64 is specifically
interesting, since it can be used to construct an UEFI NVMe device
path for a boot entry.

As per NVM Express 1.1a spec:
http://www.nvmexpress.org/wp-content/uploads/NVM-Express-1_1a.pdf

Signed-off-by: Dimitri John Ledkov 
---
 include/uapi/linux/nvme.h | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/nvme.h b/include/uapi/linux/nvme.h
index 096fe1c..73cb2af 100644
--- a/include/uapi/linux/nvme.h
+++ b/include/uapi/linux/nvme.h
@@ -49,7 +49,8 @@ struct nvme_id_ctrl {
__u8ieee[3];
__u8mic;
__u8mdts;
-   __u8rsvd78[178];
+   __le16  cntlid;
+   __u8rsvd80[176];
__le16  oacs;
__u8acl;
__u8aerl;
@@ -57,7 +58,9 @@ struct nvme_id_ctrl {
__u8lpa;
__u8elpe;
__u8npss;
-   __u8rsvd264[248];
+   __u8avscc;
+   __u8apsta;
+   __u8rsvd266[246];
__u8sqes;
__u8cqes;
__u8rsvd514[2];
@@ -68,7 +71,12 @@ struct nvme_id_ctrl {
__u8vwc;
__le16  awun;
__le16  awupf;
-   __u8rsvd530[1518];
+   __u8nvscc;
+   __u8rsvd531;
+   __le16  acwu;
+   __u8rsvd534[2];
+   __le32  sgls;
+   __u8rsvd540[1508];
struct nvme_id_power_state  psd[32];
__u8vs[1024];
 };
@@ -95,7 +103,10 @@ struct nvme_id_ns {
__u8mc;
__u8dpc;
__u8dps;
-   __u8rsvd30[98];
+   __u8nmic;
+   __u8rescap;
+   __u8rsvd32[88];
+   __le64  eui64;
struct nvme_lbaflbaf[16];
__u8rsvd192[192];
__u8vs[3712];
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] NVMe: Update namespace and controller identity structures as per 1.1a spec

[Dimitri John Ledkov]

Controller: add CNTLID, AVSCC, APSTA, NVSCC, ACWU, SGLS fields.

Namespace: add NMIC, RESCAP, EUI64 fields. EUI64 is specifically
interesting, since it can be used to construct an UEFI NVMe device
path for a boot entry.

As per NVM Express 1.1a spec:
http://www.nvmexpress.org/wp-content/uploads/NVM-Express-1_1a.pdf

Signed-off-by: Dimitri John Ledkov 
---
 include/uapi/linux/nvme.h | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/nvme.h b/include/uapi/linux/nvme.h
index 096fe1c..73cb2af 100644
--- a/include/uapi/linux/nvme.h
+++ b/include/uapi/linux/nvme.h
@@ -49,7 +49,8 @@ struct nvme_id_ctrl {
__u8ieee[3];
__u8mic;
__u8mdts;
-   __u8rsvd78[178];
+   __le16  cntlid;
+   __u8rsvd80[176];
__le16  oacs;
__u8acl;
__u8aerl;
@@ -57,7 +58,9 @@ struct nvme_id_ctrl {
__u8lpa;
__u8elpe;
__u8npss;
-   __u8rsvd264[248];
+   __u8avscc;
+   __u8apsta;
+   __u8rsvd266[246];
__u8sqes;
__u8cqes;
__u8rsvd514[2];
@@ -68,7 +71,12 @@ struct nvme_id_ctrl {
__u8vwc;
__le16  awun;
__le16  awupf;
-   __u8rsvd530[1518];
+   __u8nvscc;
+   __u8rsvd531;
+   __le16  acwu;
+   __u8rsvd534[2];
+   __le32  sgls;
+   __u8rsvd540[1508];
struct nvme_id_power_state  psd[32];
__u8vs[1024];
 };
@@ -95,7 +103,10 @@ struct nvme_id_ns {
__u8mc;
__u8dpc;
__u8dps;
-   __u8rsvd30[98];
+   __u8nmic;
+   __u8rescap;
+   __u8rsvd32[88];
+   __le64  eui64;
struct nvme_lbaflbaf[16];
__u8rsvd192[192];
__u8vs[3712];
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/7] drivers: input: keyboard: st-keyscan: add keyscan driver

[Dmitry Torokhov]

On Wed, Apr 16, 2014 at 10:49:29AM +0200, Gabriel Fernandez wrote:
> On 13 April 2014 07:10, Dmitry Torokhov  wrote:
> >
> > Does the version of the patch below still work for you?
> >
> Yes it's was tested on b2000 and b2089 sti boards.
> 
> > Thanks.
> >
> > --
> > Dmitry
> >
> Thanks for yours remarks, i will prepare a v5 versions.


If the version I sent to you works then you do not need to prepare v5,
I'll just apply what I have.

Thanks!

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] MAINTAINERS: INTEL MID SOC: add maintainer

[Gross, Mark]

Signed-off-by: markgross 

--mgross
The developer experience is our product

> -Original Message-
> From: David Cohen [mailto:david.a.co...@linux.intel.com]
> Sent: Thursday, April 17, 2014 7:39 PM
> To: h...@zytor.com; mi...@redhat.com; t...@linutronix.de;
> x...@kernel.org
> Cc: linux-kernel@vger.kernel.org; gno...@lxorguk.ukuu.org.uk; David
> Cohen; Gross, Mark
> Subject: [PATCH] MAINTAINERS: INTEL MID SOC: add maintainer
> 
> This patch adds official maintainer for low power Intel MID SoC platforms.
> 
> Signed-off-by: David Cohen 
> Cc: Mark Gross 
> ---
>  MAINTAINERS | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6dc67b1fdb50..b6056f33cb4d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5447,6 +5447,14 @@ W: logfs.org
>  S:   Maintained
>  F:   fs/logfs/
> 
> +LOW-POWER INTEL MID SOC SUPPORT
> +M:   David Cohen 
> +S:   Supported
> +F:   arch/x86/platform/intel-mid/
> +F:   arch/x86/pci/intel_mid_pci.c
> +F:   arch/x86/include/asm/intel-mid.h
> +F:   arch/x86/include/asm/intel_mid*.h
> +
>  LPC32XX MACHINE SUPPORT
>  M:   Roland Stigge 
>  L:   linux-arm-ker...@lists.infradead.org (moderated for non-
> subscribers)
> --
> 1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/1] fanotify: check permissions when creating file descriptor

[Heinrich Schuchardt]

When monitoring a directory or a mount with the fanotify API
the call to fanotify_init checks,
 * the process has cap_sys_admin capability

The call to fanotify_mark checks,
 * the process has read authorization for directory or mount

A directory or mount may contain files for which the process
has no read or write authorization.
Yet when reading from the fanotify file descriptor, structures
fanotify_event_metadata are returned, which contain a file
descriptor for these files, and will allow to read or write.

The patch adds an authorization check for read and write
permission. In case of missing permission, reading from the
fanotify file descriptor returns EACCES.

Signed-off-by: Heinrich Schuchardt 
---
 fs/notify/fanotify/fanotify_user.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/fs/notify/fanotify/fanotify_user.c 
b/fs/notify/fanotify/fanotify_user.c
index 4e565c8..5d22a20 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -62,6 +62,8 @@ static int create_fd(struct fsnotify_group *group,
 {
int client_fd;
struct file *new_file;
+   int mask;
+   int ret;
 
pr_debug("%s: group=%p event=%p\n", __func__, group, event);
 
@@ -75,11 +77,19 @@ static int create_fd(struct fsnotify_group *group,
 */
/* it's possible this event was an overflow event.  in that case dentry 
and mnt
 * are NULL;  That's fine, just don't call dentry open */
-   if (event->path.dentry && event->path.mnt)
-   new_file = dentry_open(>path,
-  group->fanotify_data.f_flags | 
FMODE_NONOTIFY,
-  current_cred());
-   else
+   if (event->path.dentry && event->path.mnt) {
+   /* check permissions before granting access to file */
+   mask = MAY_READ;
+   if (group->fanotify_data.f_flags & (O_RDWR | O_WRONLY))
+   mask |= MAY_WRITE;
+   ret = inode_permission(event->path.dentry->d_inode, mask);
+   if (ret)
+   new_file = ERR_PTR(ret);
+   else
+   new_file = dentry_open(>path,
+  group->fanotify_data.f_flags | 
FMODE_NONOTIFY,
+  current_cred());
+   } else
new_file = ERR_PTR(-EOVERFLOW);
if (IS_ERR(new_file)) {
/*
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Fwd: [PATCH] octeon-usb/octeon-hcd.c

[Nicolas Del Piano]

Hello,

this is a patch that I made for the Eudyptula Challenge.

Please let me know if there are any mistakes!

I send it to the list because the maintainer does not respond.

Regards,

Nicolas
Subject: [PATCH] coding style errors fix
From: Nicolas Del Piano 

Fixed all the coding style errors.
There are some warnings that may be fixed.
Signed-off-by: Nicolas Del Piano 
---
--- linux-next/drivers/staging/octeon-usb/octeon-hcd.c.orig 2014-04-19 
02:31:31.626040005 -0300
+++ linux-next/drivers/staging/octeon-usb/octeon-hcd.c  2014-04-19 
02:18:49.282259735 -0300
@@ -159,13 +159,13 @@ enum cvmx_usb_complete {
  * status call.
  */
 struct cvmx_usb_port_status {
-   uint32_t reserved   : 25;
-   uint32_t port_enabled   : 1;
-   uint32_t port_over_current  : 1;
-   uint32_t port_powered   : 1;
-   enum cvmx_usb_speed port_speed  : 2;
-   uint32_t connected  : 1;
-   uint32_t connect_change : 1;
+   uint32_t reserved:25;
+   uint32_t port_enabled:1;
+   uint32_t port_over_current:1;
+   uint32_t port_powered:1;
+   enum cvmx_usb_speed port_speed:2;
+   uint32_t connected:1;
+   uint32_t connect_change:1;
 };
 
 /**
@@ -181,11 +181,11 @@ struct cvmx_usb_port_status {
 union cvmx_usb_control_header {
uint64_t u64;
struct {
-   uint64_t request_type   : 8;
-   uint64_t request: 8;
-   uint64_t value  : 16;
-   uint64_t index  : 16;
-   uint64_t length : 16;
+   uint64_t request_type:8;
+   uint64_t request:8;
+   uint64_t value:16;
+   uint64_t index:16;
+   uint64_t length:16;
} s;
 };
 
@@ -246,7 +246,7 @@ enum cvmx_usb_pipe_flags {
 };
 
 /* Normal prefetch that use the pref instruction. */
-#define CVMX_PREFETCH(address, offset) asm volatile ("pref %[type], 
%[off](%[rbase])" : : [rbase] "d" (address), [off] "I" (offset), [type] "n" (0))
+#define (CVMX_PREFETCH(address, offset) asm volatile ("pref %[type], 
%[off](%[rbase])" : : ([rbase] "d" (address), [off] "I" (offset), [type] "n" 
(0
 
 /* Maximum number of times to retry failed transactions */
 #define MAX_RETRIES3
@@ -437,7 +437,7 @@ struct octeon_hcd {
type c; \
while (1) { \
c.u32 = __cvmx_usb_read_csr32(usb, address);\
-   if (c.s.field op (value)) { \
+   if (c.s.field op(value)) {  \
result = 0; \
break;  \
} else if (cvmx_get_cycle() > done) {   \
@@ -465,112 +465,6 @@ struct octeon_hcd {
 #define USB_FIFO_ADDRESS(channel, usb_index) (CVMX_USBCX_GOTGCTL(usb_index) + 
((channel)+1)*0x1000)
 
 /**
- * struct octeon_temp_buffer - a bounce buffer for USB transfers
- * @temp_buffer: the newly allocated temporary buffer (including meta-data)
- * @orig_buffer: the original buffer passed by the USB stack
- * @data:   the newly allocated temporary buffer (excluding meta-data)
- *
- * Both the DMA engine and FIFO mode will always transfer full 32-bit words. If
- * the buffer is too short, we need to allocate a temporary one, and this 
struct
- * represents it.
- */
-struct octeon_temp_buffer {
-   void *temp_buffer;
-   void *orig_buffer;
-   u8 data[0];
-};
-
-/**
- * octeon_alloc_temp_buffer - allocate a temporary buffer for USB transfer
- *(if needed)
- * @urb:   URB.
- * @mem_flags: Memory allocation flags.
- *
- * This function allocates a temporary bounce buffer whenever it's needed
- * due to HW limitations.
- */
-static int octeon_alloc_temp_buffer(struct urb *urb, gfp_t mem_flags)
-{
-   struct octeon_temp_buffer *temp;
-
-   if (urb->num_sgs || urb->sg ||
-   (urb->transfer_flags & URB_NO_TRANSFER_DMA_MAP) ||
-   !(urb->transfer_buffer_length % sizeof(u32)))
-   return 0;
-
-   temp = kmalloc(ALIGN(urb->transfer_buffer_length, sizeof(u32)) +
-  sizeof(*temp), mem_flags);
-   if (!temp)
-   return -ENOMEM;
-
-   temp->temp_buffer = temp;
-   temp->orig_buffer = urb->transfer_buffer;
-   if (usb_urb_dir_out(urb))
-   memcpy(temp->data, urb->transfer_buffer,
-  urb->transfer_buffer_length);
-   urb->transfer_buffer = temp->data;
-   urb->transfer_flags |= URB_ALIGNED_TEMP_BUFFER;
-
-   return 0;
-}
-
-/**
- * octeon_free_temp_buffer - free a temporary buffer used by USB transfers.
- * @urb: URB.
- *
- * Frees a buffer allocated by 

Re: an infinite loop in ext4 in 3.14

[Mikulas Patocka]

On Thu, 17 Apr 2014, Theodore Ts'o wrote:

> On Thu, Apr 17, 2014 at 03:23:13PM -0400, Mikulas Patocka wrote:
> > 
> > I hit a bug in ext4 - jbd2 was stuck in an infinite loop when remounting 
> > the root filesystem read-only during shutdown.
> 
> Is this at all repeatable?  I suspect what happened is that we're not
> checking the error return from jbd2_log_do_checkpoint(), and if it ran
> into an error doing the jbd2_log_do_checkpoint --- for example, if it
> wasn't able to write to the journal --- say, because __wait_cp_io()
> returned -EIO, we might be spinning in the while loop in jbd2_journal_flush:
> 
> > while (!err && journal->j_checkpoint_transactions != NULL) {
> 
> 
> (as you suspected).
> 
> I can add some error checking, but it would be interesting to know if
> you can easily reproduce the problem so we can confirm if that's what
> was really going on.
> 
> Regards,
> 
>   - Ted

Hi

It turned out that the computer had bad memory, there were other stability 
issues - so you can ignore this bug report.

Mikulas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 13/14] DTS: ARM: OMAP3-N900: Add SSI support

[Pavel Machek]

On Sat 2014-03-29 01:31:49, Sebastian Reichel wrote:
> Add SSI device tree data for OMAP3 and Nokia N900.
> 
> Signed-off-by: Sebastian Reichel 

Reviewed-by: Pavel Machek 


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 14/14] DTS: ARM: OMAP3-N900: Add modem support

[Pavel Machek]

On Sat 2014-03-29 01:31:50, Sebastian Reichel wrote:
> Add modem device tree data to Nokia N900's DTS file.
> 
> Signed-off-by: Sebastian Reichel 

Reviewed-by: Pavel Machek 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 12/14] ARM: dts: omap3 clocks: simplify ssi aliases

[Pavel Machek]

On Sat 2014-03-29 01:31:48, Sebastian Reichel wrote:
> From: Sebastian Reichel 
> 
> update aliases for the ssi clocks ssi_ssr_fck, ssi_sst_fck and ssi_ick
> to make them consistent for omap34xx and omap36xx. This makes it
> possible to reference the clocks from generic omap3 dts files.
> 
> Signed-off-by: Sebastian Reichel 
> Acked-by: Tero Kristo 

Reviewed-by: Pavel Machek 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 11/14] HSI: Introduce Nokia N900 modem driver

[Pavel Machek]

On Sat 2014-03-29 01:31:47, Sebastian Reichel wrote:
> The Nokia N900's modem is connected via Synchronous Serial Interface (SSI),
> which is a legacy version of MIPI's High-speed Synchronous Serial Interface
> (HSI).
> 
> The handles the GPIOs for enabling and resetting the modem and instanciates
> ssi-protocol for data exchange. It does not yet support exchanging voice data
> with the modem.
> 
> Signed-off-by: Sebastian Reichel 

Reviewed-by: Pavel Machek 

> +static void do_nokia_modem_rst_ind_tasklet(unsigned long data)
> +{
> + struct nokia_modem_device *modem = (struct nokia_modem_device *)data;
> +
> + if (!modem)
> + return;
> +
> + dev_info(modem->device, "*** CMT rst line change detected ***\n");

Maybe slightly less stars would work?


> +static int nokia_modem_gpio_probe(struct device *dev)
> +{
> + struct device_node *np = dev->of_node;
> + struct nokia_modem_device *modem = dev_get_drvdata(dev);
> + int gpio_count, gpio_name_count, i, err;
> +
> + gpio_count = of_gpio_count(np);
> + gpio_name_count = of_property_count_strings(np, "gpio-names");
> +
> + if(gpio_count != gpio_name_count) {

"if (".

> + modem->ssi_protocol = hsi_new_client(port, );
> + if (modem->ssi_protocol == NULL) {

...if (! ...)

> + dev_err(dev, "Could not register ssi-protocol device\n");
> + goto error2;
> + }
> +
> + err = device_attach(>ssi_protocol->device);
> + if (err == 0) {

if (!...)

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.14 regression: huge latency in read/select on tun

[Ortwin Glück]

On 03.04.2014 15:50, Eric Dumazet wrote:
> On Thu, 2014-04-03 at 06:19 -0700, Eric Dumazet wrote:
> 
>> It seems TSO support is broken.

I finally found time to bisect this:

53d6471cef17262d3ad1c7ce8982a234244f68ec is the first bad commit
commit 53d6471cef17262d3ad1c7ce8982a234244f68ec
Author: Vlad Yasevich 
Date:   Thu Mar 27 17:26:18 2014 -0400

net: Account for all vlan headers in skb_mac_gso_segment

skb_network_protocol() already accounts for multiple vlan
headers that may be present in the skb.  However, skb_mac_gso_segment()
doesn't know anything about it and assumes that skb->mac_len
is set correctly to skip all mac headers.  That may not
always be the case.  If we are simply forwarding the packet (via
bridge or macvtap), all vlan headers may not be accounted for.

A simple solution is to allow skb_network_protocol to return
the vlan depth it has calculated.  This way skb_mac_gso_segment
will correctly skip all mac headers.

Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller 

:04 04 6066ee76dd70dde2f4675155579e550d29ba0216
2196ebff4f9a8b909617dd57beeaa76cbafc8525 M  include
:04 04 20fdfb5efc1ada562b7899d0d58998914b1c2ff1
c398988f31e1b1b6ee56cb20b1a7becbdf782a17 M  net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 16/28] nios2: System calls handling

[Geert Uytterhoeven]

On Fri, Apr 18, 2014 at 2:26 PM, Ley Foon Tan  wrote:
> +/* sys_cacheflush -- flush the processor cache. */
> +asmlinkage int sys_cacheflush(unsigned long addr, unsigned long len,
> +   unsigned int op)
> +{
> +   struct vm_area_struct *vma;
> +
> +   if (len == 0)
> +   return 0;
> +
> +   /* Check for overflow */
> +   if (addr + len < addr)
> +   return -EFAULT;
> +
> +   /*
> +* Verify that the specified address region actually belongs
> +* to this process.
> +*/
> +   vma = find_vma(current->mm, addr);
> +   if (vma == NULL || addr < vma->vm_start || addr + len > vma->vm_end)
> +   return -EFAULT;
> +
> +   /* Ignore the scope and cache arguments. */

This function doesn't have scope and cache arguments
(sys_cacheflush() on m68k does have them ;-)

On Sat, Apr 19, 2014 at 6:09 PM, Pavel Machek  wrote:
> Also... explanation why you need this syscall while other
> architectures live happily without it would be nice.

12 our of 28 architectures provide such a syscall...

Is flushing the cache a privileged operation on nios2?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 10/14] HSI: Introduce driver for SSI Protocol

[Pavel Machek]

Hi!

> This adds a driver for the SSI McSAAB protocol as used in
> the Nokia N900.
> 
> Signed-off-by: Carlos Chinea 
> Signed-off-by: Sebastian Reichel 

> +#define SSIP_MIN_PN_HDR  6   /* FIXME: Revisit */
> +#define SSIP_WDTOUT  2000/* FIXME: has to be 500 msecs> */

Can they be fixed now, or do they have to wait?


> +#ifdef __LITTLE_ENDIAN
> + ((u16 *)skb->data)[2] = swab16(((u16 *)skb->data)[2]);
> + dev_dbg(>dev, "RX length fixed (%04x -> %u)\n",
> + ((u16 *)skb->data)[2], ntohs(((u16 *)skb->data)[2]));
> +#endif

Uh. Can this be replaced by
((u16 *)skb->data)[2] = htons(((u16 *)skb->data)[2]);

(without the ifdef?)

> + /*
> +  * Modem sends Phonet messages over SSI with its own endianess...
> +  * Assume that modem has the same endianess as we do.
> +  */
> + if (skb_cow_head(skb, 0))
> + goto drop;
> +#ifdef __LITTLE_ENDIAN
> + ((u16 *)skb->data)[2] = swab16(((u16 *)skb->data)[2]);
> +#endif

Here, too?

But it looks like the comment does not match the code, because we
swap.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 0/2] staging: vt6655: style fixes

[Guido Martínez]

Update the third and fourth v2 patches to apply cleanly on greg's
current tree.

Guido Martínez (2):
  staging: vt6655: remove dead code
  staging: vt6655: fix checkpatch bracing issues

 drivers/staging/vt6655/IEEE11h.c |   6 -
 drivers/staging/vt6655/baseband.c| 101 -
 drivers/staging/vt6655/bssdb.c   |   6 +-
 drivers/staging/vt6655/bssdb.h   |   2 -
 drivers/staging/vt6655/card.c| 181 ++--
 drivers/staging/vt6655/card.h|   1 -
 drivers/staging/vt6655/channel.c |  80 +++
 drivers/staging/vt6655/datarate.c|  22 +-
 drivers/staging/vt6655/desc.h|  47 
 drivers/staging/vt6655/device.h  |   6 -
 drivers/staging/vt6655/device_main.c | 298 +++--
 drivers/staging/vt6655/dpc.c | 142 
 drivers/staging/vt6655/hostap.c  |  63 +-
 drivers/staging/vt6655/ioctl.c   |   1 -
 drivers/staging/vt6655/ioctl.h   |   9 -
 drivers/staging/vt6655/iowpa.h   |   7 -
 drivers/staging/vt6655/iwctl.c   | 393 +++--
 drivers/staging/vt6655/key.c |  55 ++---
 drivers/staging/vt6655/key.h |   2 -
 drivers/staging/vt6655/mac.c |  96 
 drivers/staging/vt6655/mac.h |   1 -
 drivers/staging/vt6655/mib.c |  81 ---
 drivers/staging/vt6655/mib.h |   8 -
 drivers/staging/vt6655/michael.c |  33 +--
 drivers/staging/vt6655/power.c   |  36 +--
 drivers/staging/vt6655/power.h   |   3 -
 drivers/staging/vt6655/rf.c  |  69 +++---
 drivers/staging/vt6655/rxtx.c| 329 ++--
 drivers/staging/vt6655/rxtx.h|  11 -
 drivers/staging/vt6655/tether.c  |   4 +-
 drivers/staging/vt6655/tkip.c|   7 +-
 drivers/staging/vt6655/vntwifi.c | 115 +++---
 drivers/staging/vt6655/vntwifi.h |  14 --
 drivers/staging/vt6655/wcmd.c| 126 +--
 drivers/staging/vt6655/wctl.c|   9 +-
 drivers/staging/vt6655/wmgr.c| 410 ---
 drivers/staging/vt6655/wmgr.h|  30 ---
 drivers/staging/vt6655/wpa.c |   8 +-
 drivers/staging/vt6655/wpa2.c|  41 ++--
 drivers/staging/vt6655/wpactl.c  |  65 +-
 drivers/staging/vt6655/wroute.c  |   1 -
 41 files changed, 867 insertions(+), 2052 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 3/4] staging: vt6655: remove dead code

[Guido Martínez]

On Fri, Apr 18, 2014 at 04:09:58PM -0700, Greg KH wrote:
> This patch does not apply, can you refresh it, and the 4/4 patch,
> against my latest tree and resend?
Sending them now as v3. I'm not sure a v3 is most fitting for this
situation, so please tell me if you want me to resend them in a
different way.

Thanks

-- 
Guido Martínez, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/1] fs/aio.c: Remove ctx parameter in kiocb_cancel

[Fabian Frederick]

ctx is no longer used in kiocb_cancel since

57282d8fd74407 ("aio: Kill ki_users")

Cc: Alexander Viro 
Cc: Andrew Morton 
Signed-off-by: Fabian Frederick 
---
 fs/aio.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/aio.c b/fs/aio.c
index 12a3de0e..b92fdee 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -472,7 +472,7 @@ void kiocb_set_cancel_fn(struct kiocb *req, kiocb_cancel_fn 
*cancel)
 }
 EXPORT_SYMBOL(kiocb_set_cancel_fn);
 
-static int kiocb_cancel(struct kioctx *ctx, struct kiocb *kiocb)
+static int kiocb_cancel(struct kiocb *kiocb)
 {
kiocb_cancel_fn *old, *cancel;
 
@@ -529,7 +529,7 @@ static void free_ioctx_users(struct percpu_ref *ref)
   struct kiocb, ki_list);
 
list_del_init(>ki_list);
-   kiocb_cancel(ctx, req);
+   kiocb_cancel(req);
}
 
spin_unlock_irq(>ctx_lock);
@@ -1559,7 +1559,7 @@ SYSCALL_DEFINE3(io_cancel, aio_context_t, ctx_id, struct 
iocb __user *, iocb,
 
kiocb = lookup_kiocb(ctx, iocb, key);
if (kiocb)
-   ret = kiocb_cancel(ctx, kiocb);
+   ret = kiocb_cancel(kiocb);
else
ret = -EINVAL;
 
-- 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 5/7] ARM: dma: Use dma_pfn_offset for dma address translation

[Russell King - ARM Linux]

On Sat, Apr 19, 2014 at 10:32:50AM -0400, Santosh Shilimkar wrote:
> From: Grygorii Strashko 
> 
> In most of cases DMA addresses can be performed using offset value of
>  Bus address space relatively to physical address space as following:
> 
> PFN->DMA:
>  __pfn_to_phys(pfn + [-]dma_pfn_offset)
> 
> DMA->PFN:
>  __phys_to_pfn(dma_addr) + [-]dma_pfn_offset
> 
> Cc: Greg Kroah-Hartman 
> Cc: Russell King 
> Cc: Arnd Bergmann 
> Cc: Olof Johansson 
> Cc: Grant Likely 
> Cc: Rob Herring 
> Cc: Catalin Marinas 
> Cc: Linus Walleij 
> Signed-off-by: Grygorii Strashko 
> Signed-off-by: Santosh Shilimkar 
> ---
>  arch/arm/include/asm/dma-mapping.h |   17 +
>  1 file changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/include/asm/dma-mapping.h 
> b/arch/arm/include/asm/dma-mapping.h
> index e701a4d..8c12149 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -58,22 +58,31 @@ static inline int dma_set_mask(struct device *dev, u64 
> mask)
>  #ifndef __arch_pfn_to_dma
>  static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
>  {
> - return (dma_addr_t)__pfn_to_bus(pfn);
> + if (!dev)
> + return DMA_ERROR_CODE;
> + return (dma_addr_t)__pfn_to_bus(pfn - dev->dma_pfn_offset);

How do ISA devices (iow, those which pass a NULL device) work with this?
This looks to me like it ends up breaking some drivers.

I've also seen some drivers (such as the Freescale FEC driver) which
perform DMA coherent allocations with a NULL device - technically, that's
a bug in the driver, but the above change will cause them to regress.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.14 Regression, kernel panic when suspend, looks ath9k / wireless related

[Michael Leun]

On Sat, 19 Apr 2014 03:15:54 +0200
Michael Leun  wrote:

> Hi,
> 
> since 3.14 I get an kernel panic when trying to suspend or hibernate
> (and in several other situations). Looks ath9k or wireless related,
> does not happen when I for test
> remove /lib/modules/3.14.1/kernel/net/wireless/ath* (also from
> initrd).
> 
> Did not bisect yet, but could if needed.

Did bisect now, yields:

2a901468c221e778af52603e006a53d286e81f90 is the first bad commit
commit 2a901468c221e778af52603e006a53d286e81f90
Author: Luis R. Rodriguez 
Date:   Mon Nov 11 22:15:31 2013 +0100

cfg80211: add an option to disable processing country IEs

Certain vendors may want to disable the processing of
country IEs so that they can continue using the regulatory
domain the driver or user has set.  Currently there is no
way to stop the core from processing country IEs, so add
support to the core to ignore country IE hints.

Cc: Mihir Shete 
Cc: Henri Bahini 
Cc: Tushnim Bhattacharyya 
Signed-off-by: Luis R. Rodriguez 
Signed-off-by: Johannes Berg 

:04 04 86bdd39a7e40b95bb6a0332e0b654706cfb1e1fb 
a760753abc0241b363f71f78f13e4d42e47b M  include
:04 04 e0201f43d8aa53af3c950df61a2dfd21797187cd 
c53a936c815f3489145ae8ce0a6041ef2592d4d8 M  net


Reverting this commit from v3.14.1 makes the issue go away.




[  116.006227] PM: Syncing filesystems ... done.
[  116.238271] PM: Preparing system for mem sleep
[  116.382917] Freezing user space processes ... (elapsed 0.001 seconds) done.
[  116.384816] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) 
done.
[  116.386178] PM: Entering mem sleep
[  116.386855] wlan0: deauthenticating from 90:f6:52:4e:ba:b6 by local choice 
(reason=3)
[  116.406743] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  116.406926] BUG: unable to handle kernel NULL pointer dereference at 
0038
[  116.407009] IP:[  116.407022] sd 0:0:0:0: [sda] Stopping disk

[  116.407092]  [] reg_todo+0xc1/0x4c0 [cfg80211]
[  116.407151] PGD 366ad067 PUD 366ac067 PMD 0 
[  116.407212] Oops:  [#1] SMP 
[  116.407258] Modules linked in: netconsole configfs bnep bluetooth 
6lowpan_iphc ipt_REJECT xt_LOG xt_limit xt_recent iptable_mangle iptable_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 iptable_filter nf_conntrack_ipv6 
nf_defrag_ipv6 xt_conntrack xt_tcpudp ip6table_filter ip6_tables nf_nat_ftp 
nf_nat nf_conntrack_ftp nf_conntrack ip_tables x_tables ctr ccm 
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel 
snd_hda_codec snd_hwdep snd_pcm_oss snd_pcm snd_seq iTCO_wdt acer_wmi 
sparse_keymap iTCO_vendor_support ath9k snd_seq_device snd_timer snd_mixer_oss 
snd atl1c coretemp shpchp lpc_ich pcspkr joydev i2c_i801 hid_multitouch 
serio_raw mfd_core ac wmi battery acpi_cpufreq soundcore sg sha256_ssse3 
sha256_generic cbc linear md_mod af_packet usbhid i915 uhci_hcd i2c_algo_bit 
drm_kms_helper drm ehci_pci ehci_hcd video usbcore button usb_common 
scsi_dh_rdac scsi_dh_alua scsi_dh_emc scsi_dh_hp_sw scsi_dh dm_mirror 
dm_region_hash dm_log dm_crypt dm_snap!
 shot dm_bufio dm_mod glue_helper lrw gf128mul ablk_helper cryptd aes_x86_64 
arc4 ath9k_common ath9k_hw ath mac80211 cfg80211 rfkill fan processor thermal 
[last unloaded: ath9k]
[  116.408005] CPU: 1 PID: 3405 Comm: kworker/1:3 Tainted: G  I  3.14.1 
#3
[  116.408005] Hardware name: Acer Aspire 1825PTZ/JM12-MS-CAP, BIOS V1.3127 
04/23/2010
[  116.408005] Workqueue: events reg_todo [cfg80211]
[  116.408005] task: 8801b38225d0 ti: 8800370cc000 task.ti: 
8800370cc000
[  116.408005] RIP: 0010:[]  [] 
reg_todo+0xc1/0x4c0 [cfg80211]
[  116.408005] RSP: 0018:8800370cdde8  EFLAGS: 00010297
[  116.408005] RAX: a0075360 RBX: 8801b256e530 RCX: 0003
[  116.408005] RDX:  RSI: 8801bfc92ed8 RDI: 
[  116.408005] RBP: 8800370cde20 R08: fffe801d4b00 R09: 9600
[  116.408005] R10: 00017fe2550752c0 R11:  R12: 
[  116.408005] R13: 8801b256e51c R14: 8801b256e500 R15: 0040
[  116.408005] FS:  () GS:8801bfc8() 
knlGS:
[  116.408005] CS:  0010 DS:  ES:  CR0: 8005003b
[  116.408005] CR2: 0038 CR3: 37bb9000 CR4: 000407e0
[  116.408005] Stack:
[  116.408005]  8800370cde20 a004aaff 8801b2f9f800 
8801bfc92ec0
[  116.408005]  a00752c0  0040 
8800370cde68
[  116.408005]  81071dd8 b2e45800 8801bfc96a00 
8801bfc92ed8
[  116.408005] Call Trace:
[  116.408005]  [] ? disconnect_work+0xbf/0xd0 [cfg80211]
[  116.408005]  [] process_one_work+0x178/0x420
[  116.408005]  [] worker_thread+0x119/0x3a0
[  116.408005]  [] ? rescuer_thread+0x360/0x360
[  116.408005]  [] kthread+0xcd/0xf0
[  116.408005]  [] ? kthread_create_on_node+0x180/0x180
[  116.408005]  [] 

Re: [PATCHv3 09/14] Documentation: DT: omap-ssi binding documentation

[Pavel Machek]

On Sat 2014-03-29 01:31:45, Sebastian Reichel wrote:
> Create device tree binding documentation for
> OMAP Synchronous Serial Interface (SSI) device.
> 
> Signed-off-by: Sebastian Reichel 

Reviewed-by: Pavel Machek 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 08/14] HSI: Introduce OMAP SSI driver

[Pavel Machek]

Hi!

> Add OMAP SSI driver to the HSI subsystem.
> 
> The Synchronous Serial Interface (SSI) is a legacy version
> of HSI. As in the case of HSI, it is mainly used to connect
> Application engines (APE) with cellular modem engines (CMT)
> in cellular handsets.
> 
> It provides a multichannel, full-duplex, multi-core communication
> with no reference clock. The OMAP SSI block is capable of reaching
> speeds of 110 Mbit/s.
> 
> Signed-off-by: Carlos Chinea 
> Signed-off-by: Sebastian Reichel 

> + boolwktest:1; /* FIXME: HACK to be removed */
> + boolwkin_cken:1; /* Workaround */

There is more thanone FIXME in the code. It may be better to fix after
merge...


> +DEFINE_SIMPLE_ATTRIBUTE(ssi_sst_div_fops, ssi_div_get, ssi_div_set, 
> "%llu\n");
> +
> +static int __init ssi_debug_add_port(struct omap_ssi_port *omap_port,
> + struct dentry *dir)
> +{

A little strange indentation. Is it intentional?

> + if (IS_ERR(dir))
> + return PTR_ERR(dir);
> + debugfs_create_file("divisor", S_IRUGO | S_IWUSR, dir, port,
> + _sst_div_fops);

Here, too.

> + dev_dbg(>device, "TX div %d for fck_rate %lu Khz speed %d Kb/s\n",
> + tx_fckrate / omap_ssi->max_speed, omap_ssi->fck_rate,
> + omap_ssi->max_speed);

...and here.

> + if (--omap_port->wk_refcount) {
> + spin_unlock_bh(_port->wk_lock);
> + return 0;
> + }
> + writel(SSI_WAKE(0),
> + omap_ssi->sys + SSI_CLEAR_WAKE_REG(port->num));

...and here. Should be on one line, AFAICT.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 17/28] nios2: Signal handling support

[Richard Weinberger]

On Fri, Apr 18, 2014 at 2:27 PM, Ley Foon Tan  wrote:
> This patch adds support for signal handling.
>
> Signed-off-by: Ley Foon Tan 
> ---
>  arch/nios2/include/asm/signal.h  |  22 ++
>  arch/nios2/include/asm/ucontext.h|  34 +++
>  arch/nios2/include/uapi/asm/sigcontext.h |  30 +++
>  arch/nios2/include/uapi/asm/signal.h |  23 ++
>  arch/nios2/kernel/signal.c   | 364 
> +++
>  5 files changed, 473 insertions(+)
>  create mode 100644 arch/nios2/include/asm/signal.h
>  create mode 100644 arch/nios2/include/asm/ucontext.h
>  create mode 100644 arch/nios2/include/uapi/asm/sigcontext.h
>  create mode 100644 arch/nios2/include/uapi/asm/signal.h
>  create mode 100644 arch/nios2/kernel/signal.c
>
> diff --git a/arch/nios2/include/asm/signal.h b/arch/nios2/include/asm/signal.h
> new file mode 100644
> index 000..bbcf11eecb0194b7c7b0f9352b0154d67b2dc06a
> --- /dev/null
> +++ b/arch/nios2/include/asm/signal.h
> @@ -0,0 +1,22 @@
> +/*
> + * Copyright Altera Corporation (C) 2013. All rights reserved
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + *
> + */
> +#ifndef _NIOS2_SIGNAL_H
> +#define _NIOS2_SIGNAL_H
> +
> +#include 
> +
> +#endif /* _NIOS2_SIGNAL_H */
> diff --git a/arch/nios2/include/asm/ucontext.h 
> b/arch/nios2/include/asm/ucontext.h
> new file mode 100644
> index 000..5870ef4e92fbaec9137142534ce3c5b23705d43e
> --- /dev/null
> +++ b/arch/nios2/include/asm/ucontext.h
> @@ -0,0 +1,34 @@
> +/*
> + * Copyright (C) 2010 Tobias Klauser 
> + * Copyright (C) 2004 Microtronix Datacom Ltd
> + *
> + * derived from m68knommu
> + *
> + * This file is subject to the terms and conditions of the GNU General Public
> + * License.  See the file "COPYING" in the main directory of this archive
> + * for more details.
> + */
> +
> +#ifndef _ASM_NIOS2_UCONTEXT_H
> +#define _ASM_NIOS2_UCONTEXT_H
> +
> +typedef int greg_t;
> +#define NGREG 32
> +typedef greg_t gregset_t[NGREG];
> +
> +struct mcontext {
> +   int version;
> +   gregset_t gregs;
> +};
> +
> +#define MCONTEXT_VERSION 2
> +
> +struct ucontext {
> +   unsigned long uc_flags;
> +   struct ucontext  *uc_link;
> +   stack_t   uc_stack;
> +   struct mcontext   uc_mcontext;
> +   sigset_t  uc_sigmask;   /* mask last for extensibility */
> +};
> +
> +#endif
> diff --git a/arch/nios2/include/uapi/asm/sigcontext.h 
> b/arch/nios2/include/uapi/asm/sigcontext.h
> new file mode 100644
> index 000..6bfd8807597a7d6abc0ae32f030e44cb4f77809f
> --- /dev/null
> +++ b/arch/nios2/include/uapi/asm/sigcontext.h
> @@ -0,0 +1,30 @@
> +/*
> + * Taken from the m68knommu.
> + *
> + * Copyright (C) 2004, Microtronix Datacom Ltd.
> + *
> + * All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
> + * NON INFRINGEMENT.  See the GNU General Public License for more
> + * details.
> + */
> +
> +#ifndef _ASM_NIOS2_SIGCONTEXT_H
> +#define _ASM_NIOS2_SIGCONTEXT_H
> +
> +#include 
> +
> +struct sigcontext {
> +   struct pt_regs regs;
> +   unsigned long  sc_mask; /* old sigmask */
> +};
> +
> +#endif
> diff --git a/arch/nios2/include/uapi/asm/signal.h 
> b/arch/nios2/include/uapi/asm/signal.h
> new file mode 100644
> index 000..f29ee63144817e9798965c0b8279c08844c44e6a
> --- /dev/null
> +++ b/arch/nios2/include/uapi/asm/signal.h
> @@ -0,0 +1,23 @@
> +/*
> + * Copyright Altera Corporation (C) 2013. All rights reserved
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU 

Re: [RFC 1/3] atmel: drm: added drm driver for the atmel hlcd controller

[Jean-Jacques Hiblot]

Thanks for the patch Robert.
I've just noticed that I actually worked with an old version of the
kernel (v3.14-rc3) when I thought it based on 3.15.

JJ

2014-04-18 16:31 GMT+02:00 Robert Nelson :
>
> On Fri, Apr 18, 2014 at 8:21 AM, Boris BREZILLON
>  wrote:
>> Hi JJ,
>>
>> On 18/04/2014 11:45, Jean-Jacques Hiblot wrote:
>>> +
>>> +static void update_scanout(struct drm_crtc *crtc)
>>> +{
>>> + struct atmel_hlcdc_crtc *hlcdc_crtc = to_atmel_hlcdc_crtc(crtc);
>>> + struct drm_device *dev = crtc->dev;
>>> + struct atmel_hlcdc_drm_private *priv = dev->dev_private;
>>> + struct drm_framebuffer *fb = crtc->fb;
>>> +
>>
>> I guess you meant
>>
>> struct drm_framebuffer *fb = hclcd_crtc->fb;
>>
>>
>> because otherwise you get an error when compiling (there are similar
>> issues below).
>
> This fixes this with v3.15-rc1
>
> diff --git a/drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_crtc.c
> b/drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_crtc.c
> index 649fa19..a111d69 100644
> --- a/drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_crtc.c
> +++ b/drivers/gpu/drm/atmel_hlcdc/atmel_hlcdc_crtc.c
> @@ -81,7 +81,7 @@ static void update_scanout(struct drm_crtc *crtc)
>   struct atmel_hlcdc_crtc *hlcdc_crtc = to_atmel_hlcdc_crtc(crtc);
>   struct drm_device *dev = crtc->dev;
>   struct atmel_hlcdc_drm_private *priv = dev->dev_private;
> - struct drm_framebuffer *fb = crtc->fb;
> + struct drm_framebuffer *fb = crtc->primary->fb;
>
>   struct drm_gem_cma_object *gem;
>   struct atmel_hlcd_dma_desc *desc = hlcdc_crtc->dma_descs[DMA_BASE];
> @@ -188,7 +188,7 @@ static int atmel_hlcdc_crtc_page_flip(struct drm_crtc 
> *crtc,
>   return -EBUSY;
>   }
>
> - crtc->fb = fb;
> + crtc->primary->fb = fb;
>   atmel_hlcdc_crtc->event = event;
>   update_scanout(crtc);
>   return 0;
> @@ -397,7 +397,7 @@ static int atmel_hlcdc_crtc_mode_set(struct drm_crtc 
> *crtc,
>   hlcdc_write(dev, ATMEL_LCDC_BASECFG0,
>  LCDC_BASECFG0_BLEN_AHB_INCR16 | LCDC_BASECFG0_DLBO);
>
> - drm_fb_get_bpp_depth(crtc->fb->pixel_format, , );
> + drm_fb_get_bpp_depth(crtc->primary->fb->pixel_format, , );
>   hlcdc_write(dev, ATMEL_LCDC_BASECFG1,
>  atmel_hlcdfb_get_rgbmode(dev->dev, depth, bpp));
>   hlcdc_write(dev, ATMEL_LCDC_BASECFG2, 0);
>
> Tested-by: Robert Nelson 
>
> digs out my 31/33/34, should have a patch for them in a bit...
>
> Regards,
>
> --
> Robert Nelson
> http://www.rcn-ee.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Kernel-BR] Re: [RFC] Only a.out QMAGIC format is working

[Geyslan Gregório Bem]

Valdis,

2014-04-19 15:33 GMT-03:00  :
> On Sat, 19 Apr 2014 13:37:27 -0300, Geyslan Gregório Bem said:
>
>> Maintainers, is there some chance to fix it or a.out is really doomed?
>
> Is there an actual use case for a.out on a modern kernel?

Maybe retrocompatibility.

>
> In other wods, is there any reason to really care if it's doomed, since
> it's been *years* since that worked?

Perhaps not, but why to continue patching the ia32_aout.c and
binfmt_aout.c if that format doesn't matter (and work) anymore? That's
was the reason that I asked if it is really doomed in linux.


-- 
Regards,

Geyslan G. Bem
hackingbits.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 07/14] HSI: Add common DT binding for HSI client devices

[Pavel Machek]

On Sat 2014-03-29 01:31:43, Sebastian Reichel wrote:
> Implement and document generic DT bindings for HSI clients.
> 
> Signed-off-by: Sebastian Reichel 

Reviewed-by: Pavel Machek 

> diff --git a/drivers/hsi/hsi.c b/drivers/hsi/hsi.c
> index 07e1639..5973906 100644
> --- a/drivers/hsi/hsi.c
> +++ b/drivers/hsi/hsi.c
> @@ -26,8 +26,14 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include "hsi_core.h"


> + err = hsi_of_property_parse_mode(client, "hsi-mode", );
> + if (err) {
> + err = hsi_of_property_parse_mode(client, "hsi-rx-mode",
> +  >rx_cfg.mode);
> + if (err)
> + goto err;
> +
> + err = hsi_of_property_parse_mode(client, "hsi-tx-mode",
> +  >tx_cfg.mode);
> + if (err)
> + goto err;

Will this need some #ifdef CONFIG_OF? 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 06/14] HSI: export method to (un)register clients

[Pavel Machek]

On Sat 2014-03-29 01:31:42, Sebastian Reichel wrote:
> Expose method for registering and unregistering HSI clients, so that
> client drivers can register other client drivers.
> 
> This is useful for HSI drivers, which want to use the functionality
> of other HSI drivers. For example the N900 modem driver can load HSI
> drivers for mcsaab protocol and speech protocol.
> 
> Signed-off-by: Sebastian Reichel 

Reviewed-by: Pavel Machek 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 05/14] HSI: Add channel resource support to HSI clients

[Pavel Machek]

Hi!

> Make HSI channel ids platform data, which can be provided
> by platform data.
>

>  static void hsi_client_release(struct device *dev)
>  {
> - kfree(to_hsi_client(dev));
> + struct hsi_client *cl = to_hsi_client(dev);
> +
> + if (cl->tx_cfg.channels)
> + kfree(cl->tx_cfg.channels);
> + if (cl->rx_cfg.channels && cl->rx_cfg.channels != cl->tx_cfg.channels)
> + kfree(cl->rx_cfg.channels);
> +
> + kfree(cl);

Can cl->rx_cfg.channels == cl->tx_cfg.channels happen? That seems like
quite a hack :-(.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 04/14] HSI: method to unregister clients from an hsi port

[Pavel Machek]

On Sat 2014-03-29 01:31:40, Sebastian Reichel wrote:
> This exports a method to unregister all clients from
> an hsi port.
> 
> Signed-off-by: Sebastian Reichel 

Reviewed-by: Pavel Machek 


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 03/14] HSI: hsi-char: fix driver for multiport scenarios

[Pavel Machek]

On Sat 2014-03-29 01:31:39, Sebastian Reichel wrote:
> Fix return code check of alloc_chrdev_region, which
> returns 0 on success.
> 
> Signed-off-by: Sebastian Reichel 

Reviewed-by: Pavel Machek 


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 02/14] MAINTAINERS: update HSI entry

[Pavel Machek]

On Sat 2014-03-29 01:31:38, Sebastian Reichel wrote:
> Add git tree for hsi subsystem, update Sebastian Reichel's e-mail
> address and add Documentation/hsi.txt as maintained file.
> 
> Signed-off-by: Sebastian Reichel 

Reviewed-by: Pavel Machek 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 01/14] Documentation: HSI: Add some general description for the HSI subsystem

[Pavel Machek]

On Sat 2014-03-29 01:31:37, Sebastian Reichel wrote:
> Add a document, which gives a rough introduction about what HSI
> is and how its handled by the Linux kernel.
> 
> Signed-off-by: Sebastian Reichel 

Reviewed-by: Pavel Machek 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git pull] drm fixes

[Markus Trippelsdorf]

On 2014.04.19 at 08:19 +0100, Dave Airlie wrote:
> 
> Unfortunately this contains no easter eggs, its a bit larger than I'd 
> like, but I included a patch that just moves code from one file to another 
> and I'd like to avoid merge conflicts with that later, so it makes it seem 
> worse than it is,

> Christian König (2):
>   drm/radeon: apply more strict limits for PLL params v2
>   drm/radeon: improve PLL params if we don't match exactly v2

commit f8a2645ecede4eaf90b3d785f2805c8ecb76d43e
Author: Christian König 
Date:   Wed Apr 16 11:54:21 2014 +0200

drm/radeon: improve PLL params if we don't match exactly v2

The commit above causes my monitor to just stay blank after boot.
No framebuffer, no Xorg, no nothing. I'm using a Radeon RS780.


Apr 19 20:55:45 x4 kernel: Serial: 8250/16550 driver, 4 ports, IRQ sharing 
disabled
Apr 19 20:55:45 x4 kernel: [drm] Initialized drm 1.1.0 20060810
Apr 19 20:55:45 x4 kernel: [drm] radeon kernel modesetting enabled.
Apr 19 20:55:45 x4 kernel: [drm] initializing kernel modesetting (RS780 
0x1002:0x9614 0x1043:0x834D).
Apr 19 20:55:45 x4 kernel: [drm] register mmio base: 0xFBEE
Apr 19 20:55:45 x4 kernel: [drm] register mmio size: 65536
Apr 19 20:55:45 x4 kernel: ATOM BIOS: 113
Apr 19 20:55:45 x4 kernel: radeon :01:05.0: VRAM: 128M 0xC000 - 
0xC7FF (128M used)
Apr 19 20:55:45 x4 kernel: radeon :01:05.0: GTT: 512M 0xA000 - 
0xBFFF
Apr 19 20:55:45 x4 kernel: [drm] Detected VRAM RAM=128M, BAR=128M
Apr 19 20:55:45 x4 kernel: [drm] RAM width 32bits DDR
Apr 19 20:55:45 x4 kernel: [TTM] Zone  kernel: Available graphics memory: 
4083362 kiB
Apr 19 20:55:45 x4 kernel: [TTM] Zone   dma32: Available graphics memory: 
2097152 kiB
Apr 19 20:55:45 x4 kernel: [TTM] Initializing pool allocator
Apr 19 20:55:45 x4 kernel: [TTM] Initializing DMA pool allocator
Apr 19 20:55:45 x4 kernel: [drm] radeon: 128M of VRAM memory ready
Apr 19 20:55:45 x4 kernel: [drm] radeon: 512M of GTT memory ready.
Apr 19 20:55:45 x4 kernel: [drm] Loading RS780 Microcode
Apr 19 20:55:45 x4 kernel: == power state 0 ==
Apr 19 20:55:45 x4 kernel:  ui class: none
Apr 19 20:55:45 x4 kernel:  internal class: boot
Apr 19 20:55:45 x4 kernel:  caps: video
Apr 19 20:55:45 x4 kernel:  uvdvclk: 0 dclk: 0
Apr 19 20:55:45 x4 kernel:  power level 0sclk: 5 
vddc_index: 2
Apr 19 20:55:45 x4 kernel:  power level 1sclk: 5 
vddc_index: 2
Apr 19 20:55:45 x4 kernel:  status: c r b
Apr 19 20:55:45 x4 kernel: == power state 1 ==
Apr 19 20:55:45 x4 kernel:  ui class: performance
Apr 19 20:55:45 x4 kernel:  internal class: none
Apr 19 20:55:45 x4 kernel:  caps: video
Apr 19 20:55:45 x4 kernel:  uvdvclk: 0 dclk: 0
Apr 19 20:55:45 x4 kernel:  power level 0sclk: 5 
vddc_index: 1
Apr 19 20:55:45 x4 kernel:  power level 1sclk: 7 
vddc_index: 2
Apr 19 20:55:45 x4 kernel:  status:
Apr 19 20:55:45 x4 kernel: == power state 2 ==
Apr 19 20:55:45 x4 kernel:  ui class: none
Apr 19 20:55:45 x4 kernel:  internal class: uvd
Apr 19 20:55:45 x4 kernel:  caps: video
Apr 19 20:55:45 x4 kernel:  uvdvclk: 53300 dclk: 4
Apr 19 20:55:45 x4 kernel:  power level 0sclk: 5 
vddc_index: 1
Apr 19 20:55:45 x4 kernel:  power level 1sclk: 5 
vddc_index: 1
Apr 19 20:55:45 x4 kernel:  status:
Apr 19 20:55:45 x4 kernel: [drm] radeon: dpm initialized
Apr 19 20:55:45 x4 kernel: [drm] GART: num cpu pages 131072, num gpu pages 
131072
Apr 19 20:55:45 x4 kernel: [drm] PCIE GART of 512M enabled (table at 
0xC004).
Apr 19 20:55:45 x4 kernel: radeon :01:05.0: WB enabled
Apr 19 20:55:45 x4 kernel: radeon :01:05.0: fence driver on ring 0 use gpu 
addr 0xac00 and cpu addr 0x8800db8d0c00
Apr 19 20:55:45 x4 kernel: [drm] Supports vblank timestamp caching Rev 2 
(21.10.2013).
Apr 19 20:55:45 x4 kernel: [drm] Driver supports precise vblank timestamp query.
Apr 19 20:55:45 x4 kernel: [drm] radeon: irq initialized.
Apr 19 20:55:45 x4 kernel: [drm] ring test on 0 succeeded in 1 usecs
Apr 19 20:55:45 x4 kernel: [drm] ib test on ring 0 succeeded in 0 usecs
Apr 19 20:55:45 x4 kernel: [drm] Radeon Display Connectors
Apr 19 20:55:45 x4 kernel: [drm] Connector 0:
Apr 19 20:55:45 x4 kernel: [drm]   VGA-1
Apr 19 20:55:45 x4 kernel: [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 
0x7e48 0x7e4c 0x7e4c
Apr 19 20:55:45 x4 kernel: [drm]   Encoders:
Apr 19 20:55:45 x4 kernel: [drm] CRT1: INTERNAL_KLDSCP_DAC1
Apr 19 20:55:45 x4 kernel: [drm] Connector 1:
Apr 19 20:55:45 x4 kernel: [drm]   DVI-D-1
Apr 19 20:55:45 x4 kernel: [drm]   HPD3
Apr 19 20:55:45 x4 kernel: [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 
0x7e58 0x7e5c 0x7e5c
Apr 19 20:55:45 x4 kernel: [drm]   Encoders:
Apr 19 20:55:45 x4 kernel: [drm] DFP3: INTERNAL_KLDSCP_LVTMA
Apr 19 20:55:45 x4 kernel: switching from power state:
Apr 19 

Re: [PATCH 09/15] parisc: add renameat2 syscall

[Helge Deller]

On 04/11/2014 12:25 PM, Miklos Szeredi wrote:
> From: Miklos Szeredi 

Thanks Miklos!
 
> Signed-off-by: Miklos Szeredi 
> Cc: Helge Deller 

Acked-by: Helge Deller 

Can you please push it with the other arches.

Helge

> ---
>  arch/parisc/include/uapi/asm/unistd.h | 3 ++-
>  arch/parisc/kernel/syscall_table.S| 1 +
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/parisc/include/uapi/asm/unistd.h 
> b/arch/parisc/include/uapi/asm/unistd.h
> index 265ae5190b0a..47e0e21d2272 100644
> --- a/arch/parisc/include/uapi/asm/unistd.h
> +++ b/arch/parisc/include/uapi/asm/unistd.h
> @@ -829,8 +829,9 @@
>  #define __NR_sched_setattr   (__NR_Linux + 334)
>  #define __NR_sched_getattr   (__NR_Linux + 335)
>  #define __NR_utimes  (__NR_Linux + 336)
> +#define __NR_renameat2   (__NR_Linux + 337)
>  
> -#define __NR_Linux_syscalls  (__NR_utimes + 1)
> +#define __NR_Linux_syscalls  (__NR_renameat2 + 1)
>  
>  
>  #define __IGNORE_select  /* newselect */
> diff --git a/arch/parisc/kernel/syscall_table.S 
> b/arch/parisc/kernel/syscall_table.S
> index 80e5dd248934..a595266fdb4d 100644
> --- a/arch/parisc/kernel/syscall_table.S
> +++ b/arch/parisc/kernel/syscall_table.S
> @@ -432,6 +432,7 @@
>   ENTRY_SAME(sched_setattr)
>   ENTRY_SAME(sched_getattr)   /* 335 */
>   ENTRY_COMP(utimes)
> + ENTRY_COMP(renameat2)
>  
>   /* Nothing yet */
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Kernel-BR] Re: [RFC] Only a.out QMAGIC format is working

[Valdis . Kletnieks]

On Sat, 19 Apr 2014 13:37:27 -0300, Geyslan Gregório Bem said:

> Maintainers, is there some chance to fix it or a.out is really doomed?

Is there an actual use case for a.out on a modern kernel?

In other wods, is there any reason to really care if it's doomed, since
it's been *years* since that worked?


pgpLaQ8yFNCeb.pgp
Description: PGP signature

Re: [PATCH 0/2] memcg: mm_update_next_owner() should skip kthreads

[Oleg Nesterov]

Hi,

On 04/19, Pavel Machek wrote:
>
> > > Hmm. I seem to see a bug in this function, it can be fulled by use_mm,
> > > but I am not sure this can explain the problem. I'll send a patch.
> >
> > Untested, please review. But it really looks "obviously wrong", and note
> > that unuse_mm() doesn't do mm_update_next_owner(). (just in case, do not
> > confuse it with unuse_mm() in mm/swapfile.c).
>
> Having two functions, one exported, one static with same name -- that
> sounds quite evil, right?

Yes, agreed.

> mmu_context.c: * unuse_mm
> mmu_context.c:void unuse_mm(struct mm_struct *mm)
> mmu_context.c:EXPORT_SYMBOL_GPL(unuse_mm);
> swapfile.c:static int unuse_mm(struct mm_struct *mm,

Yes, I was thinking about s/unuse_mm/unswap_mm/ change in swapfile.c,
but then we should probaly rename other "unuse" functions there, and
shmem_unuse/try_to_unuse are not static.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] coredump: fix va_list corruption

[Oleg Nesterov]

On 04/19, Eric Dumazet wrote:
>
> A va_list needs to be copied in case it needs to be used twice.

OOPS :/

> --- a/fs/coredump.c
> +++ b/fs/coredump.c
> @@ -73,10 +73,15 @@ static int expand_corename(struct core_name *cn, int size)
>  static int cn_vprintf(struct core_name *cn, const char *fmt, va_list arg)
>  {
>   int free, need;
> + va_list arg_copy;
>
>  again:
>   free = cn->size - cn->used;
> - need = vsnprintf(cn->corename + cn->used, free, fmt, arg);
> +
> + va_copy(arg_copy, arg);
> + need = vsnprintf(cn->corename + cn->used, free, fmt, arg_copy);
> + va_end(arg_copy);
> +

Thanks!

Acked-by: Oleg Nesterov 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: Pulseaudio hung at schedule in 3.15-rc1

[Bryan Quigley]

400362f1d8dcfda3562e80e88cfc2a92cffaf9bf is the first bad commit
commit 400362f1d8dcfda3562e80e88cfc2a92cffaf9bf
Author: Takashi Iwai 
Date:   Mon Jan 20 16:51:16 2014 +0100

ALSA: usb-audio: Resume mixer values properly

Implement reset_resume callback so that the mixer values are properly
restored.  Still no boot quirks are called, so it might not work well
on some devices.

Confirmed that a revert of that commit only fixes the issue.


On Sat, Apr 19, 2014 at 2:04 AM, Bryan Quigley  wrote:
> Should be able to finish a bisect this weekend...
> So far..
> # bad: [158e0d3621683ee0cdfeeba56f0e5ddd97ae984f] Merge tag
> 'driver-core-3.15-rc1' of
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
> # good: [62ff577fa2fec87edbf26f53e87210ba726d4d44] Merge tag
> 'edac_for_3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp
>
>
> On Sat, Apr 19, 2014 at 1:08 AM, Bryan Quigley  wrote:
>> Please CC me on replies
>>
>> [1.] Pulseaudio hangs, preventing sound, and login/desktop loading
>> [2.] With 3.15rc1 pulseaudio get's stuck in a hang loop
>> [3.] audio, hung
>> [4.] Linux version 3.15.0-999-generic (apw@gomeisa) (gcc version 4.6.3
>> (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201404180205 SMP Fri Apr 18 06:06:34
>> UTC 2014
>> Also tested w/ me compiling it myself..
>> [5.]
>> Apr 19 00:42:29 unstable kernel: [  239.991104] INFO: task
>> pulseaudio:1499 blocked for more than 120 seconds.
>> Apr 19 00:42:29 unstable kernel: [  239.991116]   Not tainted
>> 3.15.0-999-generic #201404180205
>>
>> Apr 19 00:42:29 unstable kernel: [  239.991121] "echo 0 >
>> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>> Apr 19 00:42:29 unstable kernel: [  239.991127] pulseaudio  D
>> 81811b60 0  1499  1 0x0004
>>
>> Apr 19 00:42:29 unstable kernel: [  239.991137]  8800cfb93478
>> 0002 88031c74e300 8800cfb93fd8
>> Apr 19 00:42:29 unstable kernel: [  239.991145]  00014500
>> 00014500 81c174a0 88031b51b280
>>
>> Apr 19 00:42:29 unstable kernel: [  239.991153]  8800cfb93488
>> 88031e13e890  88031e13e938
>> Apr 19 00:42:29 unstable kernel: [  239.991160] Call Trace:
>> Apr 19 00:42:29 unstable kernel: [  239.991176]  []
>> schedule+0x29/0x70
>>
>> Apr 19 00:42:29 unstable kernel: [  239.991187]  []
>> rpm_resume+0x175/0x630
>> Apr 19 00:42:29 unstable kernel: [  239.991197]  []
>> ? __wake_up_sync+0x20/0x20
>> Apr 19 00:42:29 unstable kernel: [  239.991204]  []
>> rpm_resume+0x2ea/0x630
>>
>> Apr 19 00:42:29 unstable kernel: [  239.991213]  []
>> ? kfree+0x134/0x170
>> Apr 19 00:42:29 unstable kernel: [  239.991221]  []
>> __pm_runtime_resume+0x5c/0x90
>> Apr 19 00:42:29 unstable kernel: [  239.991230]  []
>> usb_autopm_get_interface+0x2d/0x70
>>
>> Apr 19 00:42:29 unstable kernel: [  239.991257]  []
>> snd_usb_autoresume+0x49/0x70 [snd_usb_audio]
>> Apr 19 00:42:29 unstable kernel: [  239.991276]  []
>> snd_usb_mixer_set_ctl_value+0x61/0x240 [snd_usb_audio]
>>
>> Apr 19 00:42:29 unstable kernel: [  239.991294]  []
>> set_cur_mix_value+0x7b/0xe0 [snd_usb_audio]
>> Apr 19 00:42:29 unstable kernel: [  239.991311]  []
>> restore_mixer_value+0xa8/0xc0 [snd_usb_audio]
>>
>> Apr 19 00:42:29 unstable kernel: [  239.991328]  []
>> snd_usb_mixer_resume+0x41/0x90 [snd_usb_audio]
>> Apr 19 00:42:29 unstable kernel: [  239.991343]  []
>> __usb_audio_resume+0x71/0xe0 [snd_usb_audio]
>>
>> Apr 19 00:42:29 unstable kernel: [  239.991350]  []
>> ? usb_runtime_suspend+0x70/0x70
>> Apr 19 00:42:29 unstable kernel: [  239.991364]  []
>> usb_audio_reset_resume+0x13/0x20 [snd_usb_audio]
>>
>> Apr 19 00:42:29 unstable kernel: [  239.991373]  []
>> usb_resume_interface.isra.4.part.5+0x2e/0xe0
>> Apr 19 00:42:29 unstable kernel: [  239.991382]  []
>> usb_resume_interface.isra.4+0x60/0x90
>>
>> Apr 19 00:42:29 unstable kernel: [  239.991389]  []
>> usb_resume_both+0x74/0xd0
>> Apr 19 00:42:29 unstable kernel: [  239.991395]  []
>> usb_runtime_resume+0x1a/0x20
>> Apr 19 00:42:29 unstable kernel: [  239.991402]  []
>> __rpm_callback+0x3d/0xc0
>>
>> Apr 19 00:42:29 unstable kernel: [  239.991408]  []
>> rpm_callback+0x2f/0x90
>> Apr 19 00:42:29 unstable kernel: [  239.991415]  []
>> rpm_resume+0x4cf/0x630
>> Apr 19 00:42:29 unstable kernel: [  239.991422]  []
>> rpm_resume+0x2ea/0x630
>>
>> Apr 19 00:42:29 unstable kernel: [  239.991430]  []
>> __pm_runtime_resume+0x5c/0x90
>> Apr 19 00:42:29 unstable kernel: [  239.991438]  []
>> usb_autopm_get_interface+0x2d/0x70
>>
>> Apr 19 00:42:29 unstable kernel: [  239.991453]  []
>> snd_usb_autoresume+0x49/0x70 [snd_usb_audio]
>> Apr 19 00:42:29 unstable kernel: [  239.991471]  []
>> setup_hw_info+0x14c/0x2f0 [snd_usb_audio]
>>
>> Apr 19 00:42:29 unstable kernel: [  239.991479]  []
>> ? __get_free_pages+0xe/0x40
>> Apr 19 00:42:29 unstable kernel: [  239.991497]  []
>> snd_usb_pcm_open+0xf4/0x100 [snd_usb_audio]
>>
>> Apr 19 00:42:29 unstable kernel: [  239.991514]  

[PATCH] coredump: fix va_list corruption

[Eric Dumazet]

From: Eric Dumazet 

A va_list needs to be copied in case it needs to be used twice.

Thanks to Hugh for debugging this issue, leading to various panics.

Tested:

lpq84:~# echo "|/foobar12345 %h %h %h %h %h %h %h %h %h %h %h %h %h %h %
h %h %h %h %h %h" >/proc/sys/kernel/core_pattern

'produce_core' is simply : main() { *(int *)0 = 1;}

lpq84:~# ./produce_core
Segmentation fault (core dumped)
lpq84:~# dmesg | tail -1
[  614.352947] Core dump to |/foobar12345 lpq84 lpq84 lpq84 lpq84 lpq84
lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84 lpq84
lpq84 lpq84 (null) pipe failed

Notice the last argument was replaced by a NULL (we were lucky enough to
not crash, but do not try this on your production machine !)

After fix :

lpq83:~# echo "|/foobar12345 %h %h %h %h %h %h %h %h %h %h %h %h %h %h %
h %h %h %h %h %h" >/proc/sys/kernel/core_pattern
lpq83:~# ./produce_core
Segmentation fault
lpq83:~# dmesg | tail -1
[  740.800441] Core dump to |/foobar12345 lpq83 lpq83 lpq83 lpq83 lpq83
lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83 lpq83
lpq83 lpq83 lpq83 pipe failed

Fixes: 5fe9d8ca21cc ("coredump: cn_vprintf() has no reason to call vsnprintf() 
twice")
Signed-off-by: Eric Dumazet 
Diagnosed-by: Hugh Dickins 
Cc: Oleg Nesterov 
Cc: Neil Horman 
Cc: Andrew Morton 
Cc: sta...@vger.kernel.org # 3.11+
---

Note: This patch applies cleanly to 3.11+ but might need some
adjustments for older linux kernels...

 fs/coredump.c |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/fs/coredump.c b/fs/coredump.c
index e3ad709a4232..0b2528fb640e 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -73,10 +73,15 @@ static int expand_corename(struct core_name *cn, int size)
 static int cn_vprintf(struct core_name *cn, const char *fmt, va_list arg)
 {
int free, need;
+   va_list arg_copy;
 
 again:
free = cn->size - cn->used;
-   need = vsnprintf(cn->corename + cn->used, free, fmt, arg);
+
+   va_copy(arg_copy, arg);
+   need = vsnprintf(cn->corename + cn->used, free, fmt, arg_copy);
+   va_end(arg_copy);
+
if (need < free) {
cn->used += need;
return 0;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] tracing: Correct braces usage in if-else statement

[ivan lin]

2014-04-19 23:28 GMT+08:00 Steven Rostedt :
> On Sat, 19 Apr 2014 21:58:23 +0800
> Lin Yongting  wrote:
>
>> There are some incorrect braces usages in kernerl/trace/trace.c, including:
>> 1. Missing braces in 'if' or 'else' branch.
>> 2. Unnecessary braces in 'if' statement.
>>
>> Fix them according to kernel CodeStyle.
>
> I understand that this is part of the CodeStyle, but I'm not accepting
> this patch. It causes more pain than it is worth, as it makes it more
> difficult to see git history because of "clean up" changes that get in
> the way. I also honestly don't think this is much of a clean up.
>
> Sorry,
>
> -- Steve
>

Yes, you are right.  This clean up is pain than it is worth.

Thnaks!

-- Yongting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/5] uprobes/x86: Shift "insn_complete" from branch_setup_xol_ops() to uprobe_init_insn()

[Oleg Nesterov]

Change uprobe_init_insn() to make insn_complete() == T, this makes
other insn_get_*() calls unnecessary.

Signed-off-by: Oleg Nesterov 
---
 arch/x86/kernel/uprobes.c |   13 -
 1 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index 5876ba5..6748600 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -209,8 +209,11 @@ static int uprobe_init_insn(struct arch_uprobe *auprobe, 
struct insn *insn, bool
u32 volatile *good_insns;
 
insn_init(insn, auprobe->insn, x86_64);
+   /* has the side-effect of processing the entire instruction */
+   insn_get_length(insn);
+   if (WARN_ON_ONCE(!insn_complete(insn)))
+   return -ENOEXEC;
 
-   insn_get_opcode(insn);
if (is_prefix_bad(insn))
return -ENOTSUPP;
 
@@ -283,8 +286,6 @@ handle_riprel_insn(struct arch_uprobe *auprobe, struct insn 
*insn)
 * is the immediate operand.
 */
cursor = auprobe->insn + insn_offset_modrm(insn);
-   insn_get_length(insn);
-
/*
 * Convert from rip-relative addressing to indirect addressing
 * via a scratch register.  Change the r/m field from 0x5 (%rip)
@@ -563,11 +564,6 @@ static int branch_setup_xol_ops(struct arch_uprobe 
*auprobe, struct insn *insn)
 {
u8 opc1 = OPCODE1(insn);
 
-   /* has the side-effect of processing the entire instruction */
-   insn_get_length(insn);
-   if (WARN_ON_ONCE(!insn_complete(insn)))
-   return -ENOEXEC;
-
switch (opc1) {
case 0xeb:  /* jmp 8 */
case 0xe9:  /* jmp 32 */
@@ -643,7 +639,6 @@ int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe, 
struct mm_struct *mm,
fix_ip = false;
break;
case 0xff:
-   insn_get_modrm();
switch (MODRM_REG()) {
case 2: case 3: /* call or lcall, indirect */
fix_call = true;
-- 
1.5.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/5] uprobes/x86: Add is_64bit_mm(), kill validate_insn_bits()

[Oleg Nesterov]

1. Extract the ->ia32_compat check from 64bit validate_insn_bits()
   into the new helper, is_64bit_mm(), it will have more users.

   TODO: this checks is actually wrong if mm owner is X32 task,
   we need another fix which changes set_personality_ia32().

   TODO: even worse, the whole 64-or-32-bit logic is very broken
   and the fix is not simple, we need the nontrivial changes in
   the core uprobes code.

2. Kill validate_insn_bits() and change its single caller to use
   uprobe_init_insn(is_64bit_mm(mm).

Signed-off-by: Oleg Nesterov 
---
 arch/x86/kernel/uprobes.c |   20 +---
 1 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index 68c63ab..5876ba5 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -231,6 +231,11 @@ static int uprobe_init_insn(struct arch_uprobe *auprobe, 
struct insn *insn, bool
 }
 
 #ifdef CONFIG_X86_64
+static inline bool is_64bit_mm(struct mm_struct *mm)
+{
+   return  !config_enabled(CONFIG_IA32_EMULATION) ||
+   !mm->context.ia32_compat;
+}
 /*
  * If arch_uprobe->insn doesn't use rip-relative addressing, return
  * immediately.  Otherwise, rewrite the instruction so that it accesses
@@ -355,13 +360,11 @@ handle_riprel_post_xol(struct arch_uprobe *auprobe, 
struct pt_regs *regs, long *
*correction += 4;
}
 }
-
-static int validate_insn_bits(struct arch_uprobe *auprobe, struct mm_struct 
*mm, struct insn *insn)
+#else /* 32-bit: */
+static inline bool is_64bit_mm(struct mm_struct *mm)
 {
-   bool x86_64 = !mm->context.ia32_compat;
-   return uprobe_init_insn(auprobe, insn, x86_64);
+   return false;
 }
-#else /* 32-bit: */
 /*
  * No RIP-relative addressing on 32-bit
  */
@@ -376,11 +379,6 @@ static void handle_riprel_post_xol(struct arch_uprobe 
*auprobe, struct pt_regs *
long *correction)
 {
 }
-
-static int validate_insn_bits(struct arch_uprobe *auprobe, struct mm_struct 
*mm,  struct insn *insn)
-{
-   return uprobe_init_insn(auprobe, insn, false);
-}
 #endif /* CONFIG_X86_64 */
 
 struct uprobe_xol_ops {
@@ -614,7 +612,7 @@ int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe, 
struct mm_struct *mm,
bool fix_ip = true, fix_call = false;
int ret;
 
-   ret = validate_insn_bits(auprobe, mm, );
+   ret = uprobe_init_insn(auprobe, , is_64bit_mm(mm));
if (ret)
return ret;
 
-- 
1.5.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/5] uprobes/x86: Make good_insns_* depend on CONFIG_X86_*

[Oleg Nesterov]

Add the suitable ifdef's around good_insns_* arrays. We do not want
to add the ugly ifdef's into their only user, uprobe_init_insn(), so
the "#else" branch simply defines them as NULL. This doesn't generate
the extra code, gcc is smart enough, although the code is fine even if
it could not detect that (without CONFIG_IA32_EMULATION) is_64bit_mm()
is __builtin_constant_p().

The patch looks more complicated because it also moves good_insns_64
up close to good_insns_32.

Signed-off-by: Oleg Nesterov 
---
 arch/x86/kernel/uprobes.c |   56 +---
 1 files changed, 32 insertions(+), 24 deletions(-)

diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index 6748600..f445b00 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -64,6 +64,7 @@
  * to keep gcc from statically optimizing it out, as variable_test_bit makes
  * some versions of gcc to think only *(unsigned long*) is used.
  */
+#if defined(CONFIG_X86_32) || defined(CONFIG_IA32_EMULATION)
 static volatile u32 good_insns_32[256 / 32] = {
/*  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f */
/*  -- */
@@ -86,32 +87,12 @@ static volatile u32 good_insns_32[256 / 32] = {
/*  -- */
/*  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f */
 };
-
-/* Using this for both 64-bit and 32-bit apps */
-static volatile u32 good_2byte_insns[256 / 32] = {
-   /*  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f */
-   /*  -- */
-   W(0x00, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1) | /* 00 */
-   W(0x10, 1, 1, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1) , /* 10 */
-   W(0x20, 1, 1, 1, 1, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1) | /* 20 */
-   W(0x30, 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) , /* 30 */
-   W(0x40, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) | /* 40 */
-   W(0x50, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* 50 */
-   W(0x60, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) | /* 60 */
-   W(0x70, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 1, 1) , /* 70 */
-   W(0x80, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) | /* 80 */
-   W(0x90, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* 90 */
-   W(0xa0, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 1) | /* a0 */
-   W(0xb0, 1, 1, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1) , /* b0 */
-   W(0xc0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) | /* c0 */
-   W(0xd0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* d0 */
-   W(0xe0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) | /* e0 */
-   W(0xf0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0)   /* f0 */
-   /*  -- */
-   /*  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f */
-};
+#else
+#define good_insns_32  NULL
+#endif
 
 /* Good-instruction tables for 64-bit apps */
+#if defined(CONFIG_X86_64)
 static volatile u32 good_insns_64[256 / 32] = {
/*  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f */
/*  -- */
@@ -134,6 +115,33 @@ static volatile u32 good_insns_64[256 / 32] = {
/*  -- */
/*  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f */
 };
+#else
+#define good_insns_64  NULL
+#endif
+
+/* Using this for both 64-bit and 32-bit apps */
+static volatile u32 good_2byte_insns[256 / 32] = {
+   /*  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f */
+   /*  -- */
+   W(0x00, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1) | /* 00 */
+   W(0x10, 1, 1, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1) , /* 10 */
+   W(0x20, 1, 1, 1, 1, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1) | /* 20 */
+   W(0x30, 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) , /* 30 */
+   W(0x40, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) | /* 40 */
+   W(0x50, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* 50 */
+   W(0x60, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) | /* 60 */
+   W(0x70, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 1, 1) , /* 70 */
+   W(0x80, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) | /* 80 */
+   W(0x90, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* 90 */
+   W(0xa0, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 1) | /* a0 */
+   W(0xb0, 1, 1, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1) , /* b0 */
+   W(0xc0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) | /* c0 */
+   W(0xd0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* d0 */
+   W(0xe0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 

[PATCH 1/5] uprobes/x86: Add uprobe_init_insn(), kill validate_insn_{32,64}bits()

[Oleg Nesterov]

validate_insn_32bits() and validate_insn_64bits() are very similar,
turn them into the single uprobe_init_insn() which has the additional
"bool x86_64" argument which can be passed to insn_init() and used to
choose between good_insns_64/good_insns_32.

Also kill UPROBE_FIX_NONE, it has no users.

Note: the current code doesn't use ifdef's consistently, good_insns_64
depends on CONFIG_X86_64 but good_insns_32 is unconditional. This patch
removes ifdef around good_insns_64, we will add it back later along with
the similar one for good_insns_32.

Signed-off-by: Oleg Nesterov 
---
 arch/x86/kernel/uprobes.c |   45 +
 1 files changed, 13 insertions(+), 32 deletions(-)

diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index e1d7115..68c63ab 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -32,9 +32,6 @@
 
 /* Post-execution fixups. */
 
-/* No fixup needed */
-#define UPROBE_FIX_NONE0x0
-
 /* Adjust IP back to vicinity of actual insn */
 #define UPROBE_FIX_IP  0x1
 
@@ -114,7 +111,6 @@ static volatile u32 good_2byte_insns[256 / 32] = {
/*  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f */
 };
 
-#ifdef CONFIG_X86_64
 /* Good-instruction tables for 64-bit apps */
 static volatile u32 good_insns_64[256 / 32] = {
/*  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f */
@@ -138,7 +134,6 @@ static volatile u32 good_insns_64[256 / 32] = {
/*  -- */
/*  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f */
 };
-#endif
 #undef W
 
 /*
@@ -209,16 +204,22 @@ static bool is_prefix_bad(struct insn *insn)
return false;
 }
 
-static int validate_insn_32bits(struct arch_uprobe *auprobe, struct insn *insn)
+static int uprobe_init_insn(struct arch_uprobe *auprobe, struct insn *insn, 
bool x86_64)
 {
-   insn_init(insn, auprobe->insn, false);
+   u32 volatile *good_insns;
+
+   insn_init(insn, auprobe->insn, x86_64);
 
-   /* Skip good instruction prefixes; reject "bad" ones. */
insn_get_opcode(insn);
if (is_prefix_bad(insn))
return -ENOTSUPP;
 
-   if (test_bit(OPCODE1(insn), (unsigned long *)good_insns_32))
+   if (x86_64)
+   good_insns = good_insns_64;
+   else
+   good_insns = good_insns_32;
+
+   if (test_bit(OPCODE1(insn), (unsigned long *)good_insns))
return 0;
 
if (insn->opcode.nbytes == 2) {
@@ -355,30 +356,10 @@ handle_riprel_post_xol(struct arch_uprobe *auprobe, 
struct pt_regs *regs, long *
}
 }
 
-static int validate_insn_64bits(struct arch_uprobe *auprobe, struct insn *insn)
-{
-   insn_init(insn, auprobe->insn, true);
-
-   /* Skip good instruction prefixes; reject "bad" ones. */
-   insn_get_opcode(insn);
-   if (is_prefix_bad(insn))
-   return -ENOTSUPP;
-
-   if (test_bit(OPCODE1(insn), (unsigned long *)good_insns_64))
-   return 0;
-
-   if (insn->opcode.nbytes == 2) {
-   if (test_bit(OPCODE2(insn), (unsigned long *)good_2byte_insns))
-   return 0;
-   }
-   return -ENOTSUPP;
-}
-
 static int validate_insn_bits(struct arch_uprobe *auprobe, struct mm_struct 
*mm, struct insn *insn)
 {
-   if (mm->context.ia32_compat)
-   return validate_insn_32bits(auprobe, insn);
-   return validate_insn_64bits(auprobe, insn);
+   bool x86_64 = !mm->context.ia32_compat;
+   return uprobe_init_insn(auprobe, insn, x86_64);
 }
 #else /* 32-bit: */
 /*
@@ -398,7 +379,7 @@ static void handle_riprel_post_xol(struct arch_uprobe 
*auprobe, struct pt_regs *
 
 static int validate_insn_bits(struct arch_uprobe *auprobe, struct mm_struct 
*mm,  struct insn *insn)
 {
-   return validate_insn_32bits(auprobe, insn);
+   return uprobe_init_insn(auprobe, insn, false);
 }
 #endif /* CONFIG_X86_64 */
 
-- 
1.5.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/5] uprobes/x86: Fix is_64bit_mm() with CONFIG_X86_X32

[Oleg Nesterov]

is_64bit_mm() assumes that mm->context.ia32_compat means the 32-bit
instruction set, this is not true if the task is TIF_X32.

Change set_personality_ia32() to initialize mm->context.ia32_compat
by TIF_X32 or TIF_IA32 instead of 1. This allows to fix is_64bit_mm()
without affecting other users, they all treat ia32_compat as "bool".

TIF_ in ->ia32_compat looks a bit strange, but this is grep-friendly
and avoids the new define's.

Signed-off-by: Oleg Nesterov 
---
 arch/x86/kernel/process_64.c |7 ---
 arch/x86/kernel/uprobes.c|2 +-
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 9c0280f..9b53940 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -413,12 +413,11 @@ void set_personality_ia32(bool x32)
set_thread_flag(TIF_ADDR32);
 
/* Mark the associated mm as containing 32-bit tasks. */
-   if (current->mm)
-   current->mm->context.ia32_compat = 1;
-
if (x32) {
clear_thread_flag(TIF_IA32);
set_thread_flag(TIF_X32);
+   if (current->mm)
+   current->mm->context.ia32_compat = TIF_X32;
current->personality &= ~READ_IMPLIES_EXEC;
/* is_compat_task() uses the presence of the x32
   syscall bit flag to determine compat status */
@@ -426,6 +425,8 @@ void set_personality_ia32(bool x32)
} else {
set_thread_flag(TIF_IA32);
clear_thread_flag(TIF_X32);
+   if (current->mm)
+   current->mm->context.ia32_compat = TIF_IA32;
current->personality |= force_personality32;
/* Prepare the first "return" to user space */
current_thread_info()->status |= TS_COMPAT;
diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index f445b00..4bbeb60 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -245,7 +245,7 @@ static int uprobe_init_insn(struct arch_uprobe *auprobe, 
struct insn *insn, bool
 static inline bool is_64bit_mm(struct mm_struct *mm)
 {
return  !config_enabled(CONFIG_IA32_EMULATION) ||
-   !mm->context.ia32_compat;
+   !(mm->context.ia32_compat == TIF_IA32);
 }
 /*
  * If arch_uprobe->insn doesn't use rip-relative addressing, return
-- 
1.5.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/5] uprobes/x86: cleanup validate_insn_* paths, fix X86_X32 case

[Oleg Nesterov]

Peter, feel free to ignore 1-4, but could you look at 5/5? It lacks the
test-case because I do not have a x32-ready testing machine.

On 04/17, Oleg Nesterov wrote:
>
> This series only fixes the problem. I'll send more changes to address
> some of TODO's mentioned in the changelogs later. In particular, we
> need to do something with "callw", see "Note: in 13/15.

So, what do you all think we should do with "callw"? Jim votes for
declining to probe callw, and I fully agree.

Any objection?

Until then, lets cleanup the validate_insn_* paths and fix another bug.
This cleanup can also simplify the next "reject callw" change.

Oleg.

 arch/x86/kernel/process_64.c |7 +-
 arch/x86/kernel/uprobes.c|  126 ++
 2 files changed, 58 insertions(+), 75 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: current->sched_class->yield_task is NULL, any hint?

[Lin Ming]

On Sat, Apr 19, 2014 at 9:21 AM, Paul Gortmaker
 wrote:
> On Wed, Apr 9, 2014 at 5:39 PM, Lin Ming  wrote:
>> On Wed, Apr 9, 2014 at 1:08 PM, Peter Zijlstra  wrote:
>
> [...]
>

 Look at that, its calling yield() from a non-preemptible context as
 well.

 That code is full of fail.
>>>
>>> *phew* none of that br_igmp_* muck lives in any kernel tree near me so I
>>> can stop worrying :-)
>>
>> It's our internal code.
>
> In the future, please don't simply call it 3.4-rt when there are a bunch of
> vendor/project/SDK patches also applied, as that can be very misleading
> to the people you are asking for help from.  If it is a hybrid franken-kernel
> then please at least indicate that right at the very beginning.

Sorry for the misleading.
I'll make it clear next time.

Thanks.

>
> Paul.
> --
>
>>
>>>
>>> In any case, it wrongly passes a GFP_WAIT along to netlink_broadcast.
>>
>> I'll fix it.
>> Thanks very much.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Kernel-BR] Re: [RFC] Only a.out QMAGIC format is working

[Geyslan Gregório Bem]

Pavel,

Thank you.

Maintainers, is there some chance to fix it or a.out is really doomed?


2014-04-19 13:15 GMT-03:00 Pavel Machek :
> Hi!
>
>> I was researching about old binary formats and did some tests.
>> Meantime, I was able to run sucessfully only the QMAGIC format.
>> Nonetheless, the OMAGIC, NMAGIC and ZMAGIC didn't work anymore.
>
> Some time ago, I ran into similar problem, and turning off userspace
> randomization was neccessary... Jiri Kosina might remember details.
>
> Pavel
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>
> --
> Você está recebendo esta mensagem porque se inscreveu no grupo "Kernel 
> Brasil" dos Grupos do Google.
> Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um 
> e-mail para kernel-br+unsubscr...@googlegroups.com.
> Para postar neste grupo, envie um e-mail para kernel...@googlegroups.com.
> Para ver esta discussão na web, acesse 
> https://groups.google.com/d/msgid/kernel-br/20140419161552.GB27776%40amd.pavel.ucw.cz.
> Para obter mais opções, acesse https://groups.google.com/d/optout.



-- 
Regards,

Geyslan G. Bem
hackingbits.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/7] of: setup dma parameters using dma-ranges and dma-coherent

[Thomas Petazzoni]

Dear Santosh Shilimkar,

On Sat, 19 Apr 2014 10:32:45 -0400, Santosh Shilimkar wrote:
> Here is an updated version of [2] based on discussion. Series introduces
> support for setting up dma parameters based on device tree properties
> like 'dma-ranges' and 'dma-coherent' and also update to ARM 32 bit port.
> Earlier version of the same series is here [1].
> 
> The 'dma-ranges' helps to take care of few DMAable system memory restrictions
> by use of dma_pfn_offset which we maintain now per device. Arch code then
> uses it for dma address translations for such cases. We update the
> dma_pfn_offset accordingly during DT the device creation process.The
> 'dma-coherent' property is used to setup arch's coherent dma_ops.
> 
> After some off-list discussion with RMK and Arnd, I have now dropped the
> controversial dma_mask setup code from the series which actually isn't 
> blocking
> me as such. Considering rest of the parts of the series are already aligned,
> am hoping to get this version merged for 3.16 merge window.
> 
> We agreed in last discussion that drivers have the ultimate
> responsibility to setup the correct dma mask but then we need to have some
> means to see if bus can support what driver has requested for a case where
> driver request for bigger mask than what bus supports. I can follow up on
> the mask topic if we have broken drivers.

I am not sure whether there is an intersection or not, but I wanted to
mention that the mvebu platform (in mach-mvebu) supports hardware I/O
coherency, which makes it a coherent DMA platform. However, we are not
able to use arm_coherent_dma_ops for this platform, because when a
transfer is being made DMA_FROM_DEVICE, at the end of the transfer, we
need to perform an I/O barrier to wait for the snooping unit to
complete its coherency work. So we're coherent, but not with
arm_coherent_dma_ops: we have our own dma operation implementation (see
arch/arm/mach-mvebu/coherency.c).

However, it seems that your patch series, at least in PATCH 6/7 makes
the assumption that for all DMA coherent platforms,
arm_coherent_dma_ops is going to be OK.

Also, I haven't followed all the discussions, but what is the intended
usage of of_dma_is_coherent() and set_arch_dma_coherent_ops() (device
drivers? platform code?).

In mach-mvebu, what we do is that we register a bus notifier on the
platform bus, so that we can set our custom DMA operations for all
platform devices in the system. Should this be done in a different way
after your series?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: current->sched_class->yield_task is NULL, any hint?

[Paul Gortmaker]

On Wed, Apr 9, 2014 at 5:39 PM, Lin Ming  wrote:
> On Wed, Apr 9, 2014 at 1:08 PM, Peter Zijlstra  wrote:

[...]

>>>
>>> Look at that, its calling yield() from a non-preemptible context as
>>> well.
>>>
>>> That code is full of fail.
>>
>> *phew* none of that br_igmp_* muck lives in any kernel tree near me so I
>> can stop worrying :-)
>
> It's our internal code.

In the future, please don't simply call it 3.4-rt when there are a bunch of
vendor/project/SDK patches also applied, as that can be very misleading
to the people you are asking for help from.  If it is a hybrid franken-kernel
then please at least indicate that right at the very beginning.

Paul.
--

>
>>
>> In any case, it wrongly passes a GFP_WAIT along to netlink_broadcast.
>
> I'll fix it.
> Thanks very much.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Only a.out QMAGIC format is working

[Pavel Machek]

Hi!

> I was researching about old binary formats and did some tests.
> Meantime, I was able to run sucessfully only the QMAGIC format.
> Nonetheless, the OMAGIC, NMAGIC and ZMAGIC didn't work anymore.

Some time ago, I ran into similar problem, and turning off userspace
randomization was neccessary... Jiri Kosina might remember details.

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 16/28] nios2: System calls handling

[Pavel Machek]

On Fri 2014-04-18 20:26:59, Ley Foon Tan wrote:
> This patch adds support for system calls from userspaces. It uses the
> asm-generic/unistd.h definitions with architecture spcific syscall. The 
> sys_call_table
> is just an array defined in a C file and it contains pointers to the syscall 
> functions.
> 
> Signed-off-by: Ley Foon Tan 


> +/* Additional Nios II specific syscalls. */
> +#define __NR_cacheflush (__NR_arch_specific_syscall)
> +__SYSCALL(__NR_cacheflush, sys_cacheflush)

I guess you should Cc: Michael Kerrisk on this one.

Also... explanation why you need this syscall while other
architectures live happily without it would be nice.

> +/* sys_cacheflush -- flush the processor cache. */
> +asmlinkage int sys_cacheflush(unsigned long addr, unsigned long len,
> + unsigned int op)
> +{
> + struct vm_area_struct *vma;
> +
> + if (len == 0)
> + return 0;

op is being ignored? You should remove it... or if (op) return -EINVAL
if you want future extensions.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 09/28] nios2: Page table management

[Pavel Machek]

Hi!

> This patch adds support for page table management.
> 
> Signed-off-by: Ley Foon Tan 

> +/*
> + * Initialize a new pgd / pmd table with invalid pointers.
> + */
> +static void pgd_init(pgd_t *pgd)
> +{
> + unsigned long *p = (unsigned long *) pgd;
> + int i;
> +
> + for (i = 0; i < USER_PTRS_PER_PGD; i += 8) {
> + p[i + 0] = (unsigned long) invalid_pte_table;
> + p[i + 1] = (unsigned long) invalid_pte_table;
> + p[i + 2] = (unsigned long) invalid_pte_table;
> + p[i + 3] = (unsigned long) invalid_pte_table;
> + p[i + 4] = (unsigned long) invalid_pte_table;
> + p[i + 5] = (unsigned long) invalid_pte_table;
> + p[i + 6] = (unsigned long) invalid_pte_table;
> + p[i + 7] = (unsigned long) invalid_pte_table;
> + }

Umm. Manual loop unrolling. Does it really improve performance? Is the
code hot enough to warrant the uglyness?

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/4] mm: zpool: zbud_alloc() minor param change

[Dan Streetman]

Change zbud to store gfp_t flags passed at pool creation to use for
each alloc; this allows the api to be closer to the existing zsmalloc
interface, and the only current zbud user (zswap) uses the same gfp
flags for all allocs.  Update zswap to use changed interface.

Signed-off-by: Dan Streetman 

---
 include/linux/zbud.h |  3 +--
 mm/zbud.c| 28 +++-
 mm/zswap.c   |  6 +++---
 3 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/include/linux/zbud.h b/include/linux/zbud.h
index 2571a5c..50563b6 100644
--- a/include/linux/zbud.h
+++ b/include/linux/zbud.h
@@ -11,8 +11,7 @@ struct zbud_ops {
 
 struct zbud_pool *zbud_create_pool(gfp_t gfp, struct zbud_ops *ops);
 void zbud_destroy_pool(struct zbud_pool *pool);
-int zbud_alloc(struct zbud_pool *pool, int size, gfp_t gfp,
-   unsigned long *handle);
+int zbud_alloc(struct zbud_pool *pool, int size, unsigned long *handle);
 void zbud_free(struct zbud_pool *pool, unsigned long handle);
 int zbud_reclaim_page(struct zbud_pool *pool, unsigned int retries);
 void *zbud_map(struct zbud_pool *pool, unsigned long handle);
diff --git a/mm/zbud.c b/mm/zbud.c
index 9451361..e02f53f 100644
--- a/mm/zbud.c
+++ b/mm/zbud.c
@@ -94,6 +94,7 @@ struct zbud_pool {
struct list_head lru;
u64 pages_nr;
struct zbud_ops *ops;
+   gfp_t gfp;
 };
 
 /*
@@ -193,9 +194,12 @@ static int num_free_chunks(struct zbud_header *zhdr)
 */
 /**
  * zbud_create_pool() - create a new zbud pool
- * @gfp:   gfp flags when allocating the zbud pool structure
+ * @gfp:   gfp flags when growing the pool
  * @ops:   user-defined operations for the zbud pool
  *
+ * gfp should not set __GFP_HIGHMEM as highmem pages cannot be used
+ * as zbud pool pages.
+ *
  * Return: pointer to the new zbud pool or NULL if the metadata allocation
  * failed.
  */
@@ -204,7 +208,9 @@ struct zbud_pool *zbud_create_pool(gfp_t gfp, struct 
zbud_ops *ops)
struct zbud_pool *pool;
int i;
 
-   pool = kmalloc(sizeof(struct zbud_pool), gfp);
+   if (gfp & __GFP_HIGHMEM)
+   return NULL;
+   pool = kmalloc(sizeof(struct zbud_pool), GFP_KERNEL);
if (!pool)
return NULL;
spin_lock_init(>lock);
@@ -214,6 +220,7 @@ struct zbud_pool *zbud_create_pool(gfp_t gfp, struct 
zbud_ops *ops)
INIT_LIST_HEAD(>lru);
pool->pages_nr = 0;
pool->ops = ops;
+   pool->gfp = gfp;
return pool;
 }
 
@@ -232,7 +239,6 @@ void zbud_destroy_pool(struct zbud_pool *pool)
  * zbud_alloc() - allocates a region of a given size
  * @pool:  zbud pool from which to allocate
  * @size:  size in bytes of the desired allocation
- * @gfp:   gfp flags used if the pool needs to grow
  * @handle:handle of the new allocation
  *
  * This function will attempt to find a free region in the pool large enough to
@@ -240,22 +246,18 @@ void zbud_destroy_pool(struct zbud_pool *pool)
  * performed first. If no suitable free region is found, then a new page is
  * allocated and added to the pool to satisfy the request.
  *
- * gfp should not set __GFP_HIGHMEM as highmem pages cannot be used
- * as zbud pool pages.
- *
- * Return: 0 if success and handle is set, otherwise -EINVAL if the size or
- * gfp arguments are invalid or -ENOMEM if the pool was unable to allocate
- * a new page.
+ * Return: 0 if success and @handle is set, -ENOSPC if the @size is too large,
+ * -EINVAL if the @size is 0 or less, or -ENOMEM if the pool was unable to
+ * allocate a new page.
  */
-int zbud_alloc(struct zbud_pool *pool, int size, gfp_t gfp,
-   unsigned long *handle)
+int zbud_alloc(struct zbud_pool *pool, int size, unsigned long *handle)
 {
int chunks, i, freechunks;
struct zbud_header *zhdr = NULL;
enum buddy bud;
struct page *page;
 
-   if (size <= 0 || gfp & __GFP_HIGHMEM)
+   if (size <= 0)
return -EINVAL;
if (size > PAGE_SIZE - ZHDR_SIZE_ALIGNED - CHUNK_SIZE)
return -ENOSPC;
@@ -279,7 +281,7 @@ int zbud_alloc(struct zbud_pool *pool, int size, gfp_t gfp,
 
/* Couldn't find unbuddied zbud page, create new one */
spin_unlock(>lock);
-   page = alloc_page(gfp);
+   page = alloc_page(pool->gfp);
if (!page)
return -ENOMEM;
spin_lock(>lock);
diff --git a/mm/zswap.c b/mm/zswap.c
index aeaef0f..1cc6770 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -679,8 +679,7 @@ static int zswap_frontswap_store(unsigned type, pgoff_t 
offset,
 
/* store */
len = dlen + sizeof(struct zswap_header);
-   ret = zbud_alloc(zswap_pool, len, __GFP_NORETRY | __GFP_NOWARN,
-   );
+   ret = zbud_alloc(zswap_pool, len, );
if (ret == -ENOSPC) {
zswap_reject_compress_poor++;
goto freepage;
@@ -900,7 +899,8 @@ static int __init init_zswap(void)
 

[PATCH 2/4] mm: zpool: implement zsmalloc shrinking

[Dan Streetman]

Add zs_shrink() and helper functions to zsmalloc.  Update zsmalloc
zs_create_pool() creation function to include ops param that provides
an evict() function for use during shrinking.  Update helper function
fix_fullness_group() to always reinsert changed zspages even if the
fullness group did not change, so they are updated in the fullness
group lru.  Also update zram to use the new zsmalloc pool creation
function but pass NULL as the ops param, since zram does not use
pool shrinking.

Signed-off-by: Dan Streetman 

---

To find all the used objects inside a zspage, I had to do a full scan
of the zspage->freelist for each object, since there's no list of used
objects, and no way to keep a list of used objects without allocating
more memory for each zspage (that I could see).  Of course, by taking
a byte (or really only a bit) out of each object's memory area to use
as a flag, we could just check that instead of scanning ->freelist
for each zspage object, but that would (slightly) reduce the available
size of each zspage object.


 drivers/block/zram/zram_drv.c |   2 +-
 include/linux/zsmalloc.h  |   7 +-
 mm/zsmalloc.c | 168 ++
 3 files changed, 160 insertions(+), 17 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 9849b52..dacf343 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -249,7 +249,7 @@ static struct zram_meta *zram_meta_alloc(u64 disksize)
goto free_meta;
}
 
-   meta->mem_pool = zs_create_pool(GFP_NOIO | __GFP_HIGHMEM);
+   meta->mem_pool = zs_create_pool(GFP_NOIO | __GFP_HIGHMEM, NULL);
if (!meta->mem_pool) {
pr_err("Error creating memory pool\n");
goto free_table;
diff --git a/include/linux/zsmalloc.h b/include/linux/zsmalloc.h
index e44d634..a75ab6e 100644
--- a/include/linux/zsmalloc.h
+++ b/include/linux/zsmalloc.h
@@ -36,11 +36,16 @@ enum zs_mapmode {
 
 struct zs_pool;
 
-struct zs_pool *zs_create_pool(gfp_t flags);
+struct zs_ops {
+   int (*evict)(struct zs_pool *pool, unsigned long handle);
+};
+
+struct zs_pool *zs_create_pool(gfp_t flags, struct zs_ops *ops);
 void zs_destroy_pool(struct zs_pool *pool);
 
 unsigned long zs_malloc(struct zs_pool *pool, size_t size);
 void zs_free(struct zs_pool *pool, unsigned long obj);
+int zs_shrink(struct zs_pool *pool, size_t size);
 
 void *zs_map_object(struct zs_pool *pool, unsigned long handle,
enum zs_mapmode mm);
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 36b4591..b99bec0 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -219,6 +219,8 @@ struct zs_pool {
struct size_class size_class[ZS_SIZE_CLASSES];
 
gfp_t flags;/* allocation flags used when growing pool */
+
+   struct zs_ops *ops;
 };
 
 /*
@@ -389,16 +391,14 @@ static enum fullness_group fix_fullness_group(struct 
zs_pool *pool,
BUG_ON(!is_first_page(page));
 
get_zspage_mapping(page, _idx, );
-   newfg = get_fullness_group(page);
-   if (newfg == currfg)
-   goto out;
-
class = >size_class[class_idx];
+   newfg = get_fullness_group(page);
+   /* Need to do this even if currfg == newfg, to update lru */
remove_zspage(page, class, currfg);
insert_zspage(page, class, newfg);
-   set_zspage_mapping(page, class_idx, newfg);
+   if (currfg != newfg)
+   set_zspage_mapping(page, class_idx, newfg);
 
-out:
return newfg;
 }
 
@@ -438,6 +438,36 @@ static int get_pages_per_zspage(int class_size)
 }
 
 /*
+ * To determine which class to use when shrinking, we find the
+ * first zspage class that is greater than the requested shrink
+ * size, and has at least one zspage.  This returns the class
+ * with the class lock held, or NULL.
+ */
+static struct size_class *get_class_to_shrink(struct zs_pool *pool,
+   size_t size)
+{
+   struct size_class *class;
+   int i;
+   bool in_use, large_enough;
+
+   for (i = 0; i <= ZS_SIZE_CLASSES; i++) {
+   class = >size_class[i];
+
+   spin_lock(>lock);
+
+   in_use = class->pages_allocated > 0;
+   large_enough = class->pages_per_zspage * PAGE_SIZE >= size;
+
+   if (in_use && large_enough)
+   return class;
+
+   spin_unlock(>lock);
+   }
+
+   return NULL;
+}
+
+/*
  * A single 'zspage' is composed of many system pages which are
  * linked together using fields in struct page. This function finds
  * the first/head page, given any component page of a zspage.
@@ -508,6 +538,48 @@ static unsigned long obj_idx_to_offset(struct page *page,
return off + obj_idx * class_size;
 }
 
+static bool obj_handle_is_free(struct page *first_page,
+   struct size_class *class, unsigned long handle)
+{
+   unsigned long obj, idx, offset;
+   

[PATCH 3/4] mm: zpool: implement common zpool api to zbud/zsmalloc

[Dan Streetman]

Add zpool api.

zpool provides an interface for memory storage, typically of compressed
memory.  Users can select what backend to use; currently the only
implementations are zbud, a low density implementation with exactly
two compressed pages per storage page, and zsmalloc, a higher density
implementation with multiple compressed pages per storage page.

Signed-off-by: Dan Streetman 
---
 include/linux/zpool.h | 166 ++
 mm/Kconfig|  43 +++---
 mm/Makefile   |   1 +
 mm/zpool.c| 380 ++
 4 files changed, 572 insertions(+), 18 deletions(-)
 create mode 100644 include/linux/zpool.h
 create mode 100644 mm/zpool.c

diff --git a/include/linux/zpool.h b/include/linux/zpool.h
new file mode 100644
index 000..82d81c6
--- /dev/null
+++ b/include/linux/zpool.h
@@ -0,0 +1,166 @@
+/*
+ * zpool memory storage api
+ *
+ * Copyright (C) 2014 Dan Streetman
+ *
+ * This is a common frontend for the zbud and zsmalloc memory
+ * storage pool implementations.  Typically, this is used to
+ * store compressed memory.
+ */
+
+#ifndef _ZPOOL_H_
+#define _ZPOOL_H_
+
+struct zpool;
+
+struct zpool_ops {
+   int (*evict)(struct zpool *pool, unsigned long handle);
+};
+
+#define ZPOOL_TYPE_ZSMALLOC "zsmalloc"
+#define ZPOOL_TYPE_ZBUD "zbud"
+
+/*
+ * Control how a handle is mapped.  It will be ignored if the
+ * implementation does not support it.  Its use is optional.
+ * Note that this does not refer to memory protection, it
+ * refers to how the memory will be copied in/out if copying
+ * is necessary during mapping; read-write is the safest as
+ * it copies the existing memory in on map, and copies the
+ * changed memory back out on unmap.  Write-only does not copy
+ * in the memory and should only be used for initialization.
+ * If in doubt, use ZPOOL_MM_DEFAULT which is read-write.
+ */
+enum zpool_mapmode {
+   ZPOOL_MM_RW, /* normal read-write mapping */
+   ZPOOL_MM_RO, /* read-only (no copy-out at unmap time) */
+   ZPOOL_MM_WO, /* write-only (no copy-in at map time) */
+
+   ZPOOL_MM_DEFAULT = ZPOOL_MM_RW
+};
+
+/**
+ * zpool_create_pool() - Create a new zpool
+ * @type   The type of the zpool to create (e.g. zbud, zsmalloc)
+ * @flags  What GFP flags should be used when the zpool allocates memory.
+ * @opsThe optional ops callback.
+ * @fallback   If other implementations should be used
+ *
+ * This creates a new zpool of the specified type.  The zpool will use the
+ * given flags when allocating any memory.  If the ops param is NULL, then
+ * the created zpool will not be shrinkable.
+ *
+ * If creation of the implementation @type fails, and @fallback is true,
+ * then other implementation(s) are tried.  If @fallback is false or no
+ * implementations could be created, then NULL is returned.
+ *
+ * Returns: New zpool on success, NULL on failure.
+ */
+struct zpool *zpool_create_pool(char *type, gfp_t flags,
+   struct zpool_ops *ops, bool fallback);
+
+/**
+ * zpool_get_type() - Get the type of the zpool
+ * @pool   The zpool to check
+ *
+ * This returns the type of the pool, which will match one of the
+ * ZPOOL_TYPE_* defined values.  This can be useful after calling
+ * zpool_create_pool() with @fallback set to true.
+ *
+ * Returns: The type of zpool.
+ */
+char *zpool_get_type(struct zpool *pool);
+
+/**
+ * zpool_destroy_pool() - Destroy a zpool
+ * @pool   The zpool to destroy.
+ *
+ * This destroys an existing zpool.  The zpool should not be in use.
+ */
+void zpool_destroy_pool(struct zpool *pool);
+
+/**
+ * zpool_malloc() - Allocate memory
+ * @pool   The zpool to allocate from.
+ * @size   The amount of memory to allocate.
+ * @handle Pointer to the handle to set
+ *
+ * This allocates the requested amount of memory from the pool.
+ * The provided @handle will be set to the allocated object handle.
+ *
+ * Returns: 0 on success, negative value on error.
+ */
+int zpool_malloc(struct zpool *pool, size_t size, unsigned long *handle);
+
+/**
+ * zpool_free() - Free previously allocated memory
+ * @pool   The zpool that allocated the memory.
+ * @handle The handle to the memory to free.
+ *
+ * This frees previously allocated memory.  This does not guarantee
+ * that the pool will actually free memory, only that the memory
+ * in the pool will become available for use by the pool.
+ */
+void zpool_free(struct zpool *pool, unsigned long handle);
+
+/**
+ * zpool_shrink() - Shrink the pool size
+ * @pool   The zpool to shrink.
+ * @size   The minimum amount to shrink the pool.
+ *
+ * This attempts to shrink the actual memory size of the pool
+ * by evicting currently used handle(s).  If the pool was
+ * created with no zpool_ops, or the evict call fails for any
+ * of the handles, this will fail.
+ *
+ * Returns: 0 on success, negative value on error/failure.
+ */
+int zpool_shrink(struct zpool *pool, size_t