Re: [PATCH 01/14] MAINTAINERS: remove 3c505

[David Miller]

From: Cesar Eduardo Barros 
Date: Sat,  2 Mar 2013 22:53:39 -0300

> This driver was removed by commit 0e245db (drivers/net: delete the 3Com
> 3c505/3c507 intel i825xx support).
> 
> Cc: Paul Gortmaker 
> Cc: Philip Blundell 
> Cc: net...@vger.kernel.org
> Signed-off-by: Cesar Eduardo Barros 

Applied.
--
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 05/14] MAINTAINERS: remove drivers/net/wan/cycx*

[David Miller]

From: Cesar Eduardo Barros 
Date: Sat,  2 Mar 2013 22:53:43 -0300

> This driver was removed by commit 6fcdf4f (wanrouter: delete now
> orphaned header content, files/drivers).
> 
> Cc: Paul Gortmaker 
> Cc: Arnaldo Carvalho de Melo 
> Cc: net...@vger.kernel.org
> Signed-off-by: Cesar Eduardo Barros 

Applied.
--
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] caif_dev: fix sparse warnings for caif_flow_cb

[David Miller]

From: Silviu-Mihai Popescu 
Date: Sat,  2 Mar 2013 21:45:19 +0200

> This fixed the following sparse warning:
> net/caif/caif_dev.c:121:6: warning: symbol 'caif_flow_cb' was not
> declared. Should it be static?
> 
> Signed-off-by: Silviu-Mihai Popescu 

Applied.
--
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 07/14] MAINTAINERS: remove eexpress

[David Miller]

From: Cesar Eduardo Barros 
Date: Sat,  2 Mar 2013 22:53:45 -0300

> This driver was removed by commit f84932d (drivers/net: delete ISA intel
> eexpress and eepro i825xx drivers).
> 
> Cc: Paul Gortmaker 
> Cc: Philip Blundell 
> Cc: net...@vger.kernel.org
> Signed-off-by: Cesar Eduardo Barros 

Applied.
--
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 resubmit] ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver

[David Miller]

From: Freddy Xin 
Date: Sat,  2 Mar 2013 18:41:11 +0800

> From: Freddy Xin 
> 
> This is a resubmission.
> Added kfree() in ax88179_get_eeprom to prevent memory leakage.
> Modified "__le16 rxctl" to "u16 rxctl" in "struct ax88179_data" and removed 
> pointless casts.
> Removed asix_init and asix_exit functions and added 
> "module_usb_driver(ax88179_178a_driver)".
> Fixed endianness issue on big endian systems and verified this driver on 
> iBook G4.
> Removed steps that change net->features in ax88179_set_features function.
> Added "const" to ethtool_ops structure and fixed the coding style of 
> AX88179_BULKIN_SIZE array.
> Fixed the issue that the default MTU is not 1500.
> Added ax88179_change_mtu function and enabled the hardware jumbo frame 
> function to support an
> MTU higher than 1500.
> Fixed indentation and empty line coding style errors.
> The _nopm version usb functions were added to access register in suspend and 
> resume functions.
> Serveral variables allocted dynamically were removed and replaced by stack 
> variables.
> ax88179_get_eeprom were modified from asix_get_eeprom in asix_common.
> 
> This patch adds a driver for ASIX's AX88179 family of USB 3.0/2.0
> to gigabit ethernet adapters. It's based on the AX88xxx driver but
> the usb commands used to access registers for AX88179 are completely 
> different.
> This driver had been verified on x86 system with AX88179/AX88178A and
> Sitcomm LN-032 USB dongles.
> 
> Signed-off-by: Freddy Xin 

Applied.
--
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 30/31] driver/base: implement subsys_virtual_register()

[Kay Sievers]

On Sat, Mar 2, 2013 at 7:17 PM, Greg Kroah-Hartman
 wrote:
> On Fri, Mar 01, 2013 at 07:24:21PM -0800, Tejun Heo wrote:
>> Kay tells me the most appropriate place to expose workqueues to
>> userland would be /sys/devices/virtual/workqueues/WQ_NAME which is
>> symlinked to /sys/bus/workqueue/devices/WQ_NAME and that we're lacking
>> a way to do that outside of driver core as virtual_device_parent()
>> isn't exported and there's no inteface to conveniently create a
>> virtual subsystem.
>
> I'm almost afraid to ask what you want to export to userspace for a
> workqueue that userspace would care about...
>
> If you create a subsystem, the devices will show up under the virtual
> "bus" if you don't give them a parent, so this patch shouldn't be
> needed, unless you are abusing the driver model.  What am I missing
> here?

Unfortunately, the parent == NULL --> /sys/devices/virtual//
we have only implemented for classes, and not for buses. We should fix
that.

Kay
--
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: [trace:tip/perf/core 5/15] kernel/trace/trace_functions.c:79:16: sparse: incorrect type in initializer (different address spaces)

[Fengguang Wu]

On Sat, Mar 02, 2013 at 10:12:40PM -0800, Christopher Li wrote:
> On Sat, Mar 2, 2013 at 5:23 AM, Fengguang Wu  wrote:
> > That's it!  Verified with
> >
> > make C=1 kernel/trace/trace_functions.o
> 
> You can use C=2 to run sparse without recompile the obj file.

Got it, thanks!

Fengguang
--
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: [trace:tip/perf/core 5/15] kernel/trace/trace_functions.c:79:16: sparse: incorrect type in initializer (different address spaces)

[Christopher Li]

On Sat, Mar 2, 2013 at 5:23 AM, Fengguang Wu  wrote:
> That's it!  Verified with
>
> make C=1 kernel/trace/trace_functions.o

You can use C=2 to run sparse without recompile the obj file.

Chris
--
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 PATCH 1/2] ipc: introduce obtaining a lockless ipc object

[Linus Torvalds]

On Sat, Mar 2, 2013 at 9:32 PM, Davidlohr Bueso  wrote:
>
> After updating the callers, [msgctl, semctl, shmctl]_down, to acquire
> the lock for IPC_RMID and IPC_SET commands, I'm no longer seeing these
> issues - so far on my regular laptop and two big boxes running my Oracle
> benchmarks for a few hours. Something like below (yes, I will address
> the open coded spin_lock calls):

Actually, please do me a favor, and do *not* change the semantics of
these helper calls without changing the name of the helper.

So I'd ask that instead of changing the callers, do this:

 - make the version that does *not* lock be called ipcctl_pre_down_nolock()

 - then, keep the old name, and just make it do the
ipcctl_pre_down_nolock() followed by the spin_lock() (or rather, the
non-open-coded one).

Then, you can make each caller individually use the "nolock" version
instead, and move the locking into the caller. But don't do the same
mistake as the original patch, which was to change the locking
semantics while keeping the same name of the function.

In other words, it's much better to make these changes in small
gradual pieces, and make each piece very obviously not change any
semantics. So the first piece is the introduce the helper functions
with new semantics (and new names), while keeping the old helpers with
the old semantics and old names. Make it really clear that no
semantics change. And the second piece is then to start using the
split-up helpers that have different locking semantics and new names,
and do it on a call-by-call basis.

Ok?

  Linus
--
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] sp5100_tco: Fix the AcpiMmioSel bitmask value

[Takahisa Tanaka]

The AcpiMmioSel bit is the bit1 in AcpiMmioEn register, but, current
sp5100_tco driver was using bit2.

The sp5100_tco driver expects zero as a value of AcpiMmioSel (bit1).
fortunately, The problem didn't occur by this typo, because the default
value of misused bit2 is zero. However, the sp5100_tco driver should use
the correct bitmask value.

Signed-off-by: Takahisa Tanaka 
---
 drivers/watchdog/sp5100_tco.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/sp5100_tco.h b/drivers/watchdog/sp5100_tco.h
index 71594a0..2b28c00 100644
--- a/drivers/watchdog/sp5100_tco.h
+++ b/drivers/watchdog/sp5100_tco.h
@@ -57,7 +57,7 @@
 #define SB800_PM_WATCHDOG_DISABLE  (1 << 2)
 #define SB800_PM_WATCHDOG_SECOND_RES   (3 << 0)
 #define SB800_ACPI_MMIO_DECODE_EN  (1 << 0)
-#define SB800_ACPI_MMIO_SEL(1 << 2)
+#define SB800_ACPI_MMIO_SEL(1 << 1)
 
 
 #define SB800_PM_WDT_MMIO_OFFSET   0xB00
-- 
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 PATCH 1/2] ipc: introduce obtaining a lockless ipc object

[Mike Galbraith]

On Sat, 2013-03-02 at 21:18 -0500, Rik van Riel wrote: 
> On 03/01/2013 11:32 PM, Michel Lespinasse wrote:
> 
> > I think it may be nicer to take the rcu read lock at the call site
> > rather than in ipc_obtain_object(), to make the rcu read lock/unlock
> > sites pair up more nicely. Either that or make an inline
> > ipc_release_object function that pairs up with ipc_obtain_object() and
> > just does an rcu_read_unlock().
> 
> I started on a patch series to untangle the IPC locking, so
> it will be a little more readable, and easier to maintain.
> 
> It is a slower approach than Davidlohr's, as in, it will take
> a little longer to put a patch series together, but I hope it
> will be easier to debug...
> 
> I hope to post a first iteration of the series by the middle
> of next week.

Goody, I'll be watching out for it.  I have a big box rt user who uses
semaphores in their very tight constraint application.  While they're
using them carefully, I saw a trace where contention cost vs jitter
budget was a bit too high for comfort, and semctl/semop collision.

-Mike

--
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] sp5100_tco: Remove code that may cause a boot failure

[Takahisa Tanaka]

The critical problem which can't boot OS until the power is completely
cut off found on PC with SB700 chipset. This patch fix the problem, but,
this patch prevents the sp5100_tco driver from using watchdog timer
function of chipset on PC with SP5100 or SB7x0 chipset.

Re-programming the MMIO address registers for the watchdog timer must
have generated the problem. However, I don't know root cause so far.
So, I decided to remove the concerned codes.

Note that this patch is dependent on the commit adbdcc03 and a6e26b13.

Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1116835
Link: https://lkml.org/lkml/2013/2/14/271

Signed-off-by: Takahisa Tanaka 
---
v1 -> v2
 -The patch was split into the bug fix and the typo fix.
---
 drivers/watchdog/sp5100_tco.c | 126 ++
 1 file changed, 6 insertions(+), 120 deletions(-)

diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
index e3b8f75..0e9d8c4 100644
--- a/drivers/watchdog/sp5100_tco.c
+++ b/drivers/watchdog/sp5100_tco.c
@@ -40,13 +40,12 @@
 #include "sp5100_tco.h"
 
 /* Module and version information */
-#define TCO_VERSION "0.03"
+#define TCO_VERSION "0.05"
 #define TCO_MODULE_NAME "SP5100 TCO timer"
 #define TCO_DRIVER_NAME   TCO_MODULE_NAME ", v" TCO_VERSION
 
 /* internal variables */
 static u32 tcobase_phys;
-static u32 resbase_phys;
 static u32 tco_wdt_fired;
 static void __iomem *tcobase;
 static unsigned int pm_iobase;
@@ -54,10 +53,6 @@ static DEFINE_SPINLOCK(tco_lock);/* Guards the hardware 
*/
 static unsigned long timer_alive;
 static char tco_expect_close;
 static struct pci_dev *sp5100_tco_pci;
-static struct resource wdt_res = {
-   .name = "Watchdog Timer",
-   .flags = IORESOURCE_MEM,
-};
 
 /* the watchdog platform device */
 static struct platform_device *sp5100_tco_platform_device;
@@ -75,12 +70,6 @@ module_param(nowayout, bool, 0);
 MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started."
" (default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
 
-static unsigned int force_addr;
-module_param(force_addr, uint, 0);
-MODULE_PARM_DESC(force_addr, "Force the use of specified MMIO address."
-   " ONLY USE THIS PARAMETER IF YOU REALLY KNOW"
-   " WHAT YOU ARE DOING (default=none)");
-
 /*
  * Some TCO specific functions
  */
@@ -176,39 +165,6 @@ static void tco_timer_enable(void)
}
 }
 
-static void tco_timer_disable(void)
-{
-   int val;
-
-   if (sp5100_tco_pci->revision >= 0x40) {
-   /* For SB800 or later */
-   /* Enable watchdog decode bit and Disable watchdog timer */
-   outb(SB800_PM_WATCHDOG_CONTROL, SB800_IO_PM_INDEX_REG);
-   val = inb(SB800_IO_PM_DATA_REG);
-   val |= SB800_PCI_WATCHDOG_DECODE_EN;
-   val |= SB800_PM_WATCHDOG_DISABLE;
-   outb(val, SB800_IO_PM_DATA_REG);
-   } else {
-   /* For SP5100 or SB7x0 */
-   /* Enable watchdog decode bit */
-   pci_read_config_dword(sp5100_tco_pci,
- SP5100_PCI_WATCHDOG_MISC_REG,
- );
-
-   val |= SP5100_PCI_WATCHDOG_DECODE_EN;
-
-   pci_write_config_dword(sp5100_tco_pci,
-  SP5100_PCI_WATCHDOG_MISC_REG,
-  val);
-
-   /* Disable Watchdog timer */
-   outb(SP5100_PM_WATCHDOG_CONTROL, SP5100_IO_PM_INDEX_REG);
-   val = inb(SP5100_IO_PM_DATA_REG);
-   val |= SP5100_PM_WATCHDOG_DISABLE;
-   outb(val, SP5100_IO_PM_DATA_REG);
-   }
-}
-
 /*
  * /dev/watchdog handling
  */
@@ -361,7 +317,7 @@ static unsigned char sp5100_tco_setupdevice(void)
 {
struct pci_dev *dev = NULL;
const char *dev_name = NULL;
-   u32 val, tmp_val;
+   u32 val;
u32 index_reg, data_reg, base_addr;
 
/* Match the PCI device */
@@ -459,63 +415,8 @@ static unsigned char sp5100_tco_setupdevice(void)
} else
pr_debug("SBResource_MMIO is disabled(0x%04x)\n", val);
 
-   /*
-* Lastly re-programming the watchdog timer MMIO address,
-* This method is a last resort...
-*
-* Before re-programming, to ensure that the watchdog timer
-* is disabled, disable the watchdog timer.
-*/
-   tco_timer_disable();
-
-   if (force_addr) {
-   /*
-* Force the use of watchdog timer MMIO address, and aligned to
-* 8byte boundary.
-*/
-   force_addr &= ~0x7;
-   val = force_addr;
-
-   pr_info("Force the use of 0x%04x as MMIO address\n", val);
-   } else {
-   /*
-* Get empty slot into the resource tree for watchdog timer.
-*/
-   if (allocate_resource(_resource,
-  

Re: [PATCH 14/14] MAINTAINERS: use same pattern for firewire in uapi

[Joe Perches]

On Sat, 2013-03-02 at 22:53 -0300, Cesar Eduardo Barros wrote:
> This avoids a false positive in the checkmaintainers.py script.

You should fix the script instead of making
deliberate errors in MAINTAINERS.

> diff --git a/MAINTAINERS b/MAINTAINERS
[]
> @@ -3236,7 +3236,7 @@ W:  http://ieee1394.wiki.kernel.org/
>  T:   git git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git
>  S:   Maintained
>  F:   drivers/firewire/
> -F:   include/linux/firewire.h
> +F:   include/linux/firewire*.h




--
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 PATCH 1/2] ipc: introduce obtaining a lockless ipc object

[Davidlohr Bueso]

On Sat, 2013-03-02 at 13:24 -0800, Linus Torvalds wrote:
> On Fri, Mar 1, 2013 at 4:16 PM, Davidlohr Bueso  
> wrote:
> > @@ -784,7 +806,7 @@ struct kern_ipc_perm *ipcctl_pre_down(struct 
> > ipc_namespace *ns,
> > int err;
> >
> > down_write(>rw_mutex);
> > -   ipcp = ipc_lock_check(ids, id);
> > +   ipcp = ipc_obtain_object_check(ids, id);
> > if (IS_ERR(ipcp)) {
> > err = PTR_ERR(ipcp);
> > goto out_up;
> > @@ -801,7 +823,7 @@ struct kern_ipc_perm *ipcctl_pre_down(struct 
> > ipc_namespace *ns,
> > return ipcp;
> >
> > err = -EPERM;
> > -   ipc_unlock(ipcp);
> > +   rcu_read_unlock();
> >  out_up:
> > up_write(>rw_mutex);
> > return ERR_PTR(err);
> 
> Uhhuh. This is very buggy, and I think it's the reason for the later
> bugs that Emmanuel reported.

Yes, quite buggy. I was able to mess up three different machines with
this, and since semaphores aren't the only users of ipcctl_pre_down(),
it could explain the sys_shmctl() call in the trace Emmanuel reported. 

> 
> In particular, the *non-error* case is buggy, where it in the middle
> of the function does
> 
> return ipcp;
> 
> for a successful lookup.
> 
> It used to return a locked ipcp, now it no longer does. And you didn't
> change any of the callers, which still do the "ipc_unlock()" at the
> end.  So all the locking gets completely confused.
> 

After updating the callers, [msgctl, semctl, shmctl]_down, to acquire
the lock for IPC_RMID and IPC_SET commands, I'm no longer seeing these
issues - so far on my regular laptop and two big boxes running my Oracle
benchmarks for a few hours. Something like below (yes, I will address
the open coded spin_lock calls):

@@ -1101,16 +1138,20 @@ static int semctl_down(struct ipc_namespace *ns, int 
semid,
 
switch(cmd){
case IPC_RMID:
+   spin_lock(>sem_perm.lock);
freeary(ns, ipcp);
goto out_up;
case IPC_SET:
+   spin_lock(>sem_perm.lock);
err = ipc_update_perm(_perm, ipcp);
if (err)
goto out_unlock;
sma->sem_ctime = get_seconds();
break;
default:
+   rcu_read_unlock();
err = -EINVAL;
+   goto out_up;
}

--
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/5] f2fs: align f2fs maximum name length to linux based filesystem

[Jaegeuk Kim]

We should not change the on-disk layout.
Instead, simply we can deal with it by changing original condition check
like below.

---
From ccc2546eded1efd2d6ed98f8aee7d7ce247cb4a2 Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim 
Date: Sun, 3 Mar 2013 13:58:05 +0900
Subject: [PATCH] f2fs: align f2fs maximum name length to linux based
 filesystem
Cc: linux-fsde...@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-f2fs-de...@lists.sourceforge.net

The maximum filename length supported in linux is 255 characters.
So let's follow that.

Signed-off-by: Namjae Jeon 
Signed-off-by: Amit Sahrawat 
Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/dir.c   |  3 +++
 fs/f2fs/namei.c |  2 +-
 fs/f2fs/super.c |  2 +-
 include/linux/f2fs_fs.h | 14 --
 4 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index c395c50..4ac8a7b 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -189,6 +189,9 @@ struct f2fs_dir_entry *f2fs_find_entry(struct inode
*dir,
unsigned int max_depth;
unsigned int level;
 
+   if (namelen > F2FS_NAME_LEN)
+   return NULL;
+
if (npages == 0)
return NULL;
 
diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
index 1a49b88..d4a171b 100644
--- a/fs/f2fs/namei.c
+++ b/fs/f2fs/namei.c
@@ -197,7 +197,7 @@ static struct dentry *f2fs_lookup(struct inode *dir,
struct dentry *dentry,
struct f2fs_dir_entry *de;
struct page *page;
 
-   if (dentry->d_name.len > F2FS_MAX_NAME_LEN)
+   if (dentry->d_name.len > F2FS_NAME_LEN)
return ERR_PTR(-ENAMETOOLONG);
 
de = f2fs_find_entry(dir, >d_name, );
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 8c11764..1c7f595 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -180,7 +180,7 @@ static int f2fs_statfs(struct dentry *dentry, struct
kstatfs *buf)
buf->f_files = sbi->total_node_count;
buf->f_ffree = sbi->total_node_count - valid_inode_count(sbi);
 
-   buf->f_namelen = F2FS_MAX_NAME_LEN;
+   buf->f_namelen = F2FS_NAME_LEN;
buf->f_fsid.val[0] = (u32)id;
buf->f_fsid.val[1] = (u32)(id >> 32);
 
diff --git a/include/linux/f2fs_fs.h b/include/linux/f2fs_fs.h
index f9a12f6..7b50991 100644
--- a/include/linux/f2fs_fs.h
+++ b/include/linux/f2fs_fs.h
@@ -139,6 +139,8 @@ struct f2fs_extent {
__le32 len; /* lengh of the extent */
 } __packed;
 
+/* We can store F2FS_MAX_NAME_LEN, but lets follow linux convention. */
+#define F2FS_NAME_LEN  255
 #define F2FS_MAX_NAME_LEN  256
 #define ADDRS_PER_INODE 923/* Address Pointers in an Inode */
 #define ADDRS_PER_BLOCK 1018   /* Address Pointers in a Direct
Block */
@@ -362,10 +364,10 @@ struct f2fs_summary_block {
 typedef __le32 f2fs_hash_t;
 
 /* One directory entry slot covers 8bytes-long file name */
-#define F2FS_NAME_LEN  8
-#define F2FS_NAME_LEN_BITS 3
+#define F2FS_SLOT_LEN  8
+#define F2FS_SLOT_LEN_BITS 3
 
-#define GET_DENTRY_SLOTS(x)((x + F2FS_NAME_LEN - 1) >>
F2FS_NAME_LEN_BITS)
+#define GET_DENTRY_SLOTS(x)((x + F2FS_SLOT_LEN - 1) >>
F2FS_SLOT_LEN_BITS)
 
 /* the number of dentry in a block */
 #define NR_DENTRY_IN_BLOCK 214
@@ -377,10 +379,10 @@ typedef __le32f2fs_hash_t;
 #define SIZE_OF_DENTRY_BITMAP  ((NR_DENTRY_IN_BLOCK + BITS_PER_BYTE -
1) / \
BITS_PER_BYTE)
 #define SIZE_OF_RESERVED   (PAGE_SIZE - ((SIZE_OF_DIR_ENTRY + \
-   F2FS_NAME_LEN) * \
+   F2FS_SLOT_LEN) * \
NR_DENTRY_IN_BLOCK + SIZE_OF_DENTRY_BITMAP))
 
-/* One directory entry slot representing F2FS_NAME_LEN-sized file name
*/
+/* One directory entry slot representing F2FS_SLOT_LEN-sized file name
*/
 struct f2fs_dir_entry {
__le32 hash_code;   /* hash code of file name */
__le32 ino; /* inode number */
@@ -394,7 +396,7 @@ struct f2fs_dentry_block {
__u8 dentry_bitmap[SIZE_OF_DENTRY_BITMAP];
__u8 reserved[SIZE_OF_RESERVED];
struct f2fs_dir_entry dentry[NR_DENTRY_IN_BLOCK];
-   __u8 filename[NR_DENTRY_IN_BLOCK][F2FS_NAME_LEN];
+   __u8 filename[NR_DENTRY_IN_BLOCK][F2FS_SLOT_LEN];
 } __packed;
 
 /* file types used in inode_info->flags */
-- 
1.8.1.3.566.gaa39828




-- 
Jaegeuk Kim
Samsung


signature.asc
Description: This is a digitally signed message part

Re: [PATCH 3/5] f2fs: move f2fs_balance_fs to correct place in unlink

[Jaegeuk Kim]

2013-03-02 (토), 12:41 +0900, Namjae Jeon:
> From: Namjae Jeon 
> 
> Actual dirty of pages will occur in f2fs_delete_entry so move the
> f2fs_balance_fs just before deletion.
> 
> Signed-off-by: Namjae Jeon 
> Signed-off-by: Amit Sahrawat 
> ---
>  fs/f2fs/namei.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
> index 1a49b88..eaa86f5 100644
> --- a/fs/f2fs/namei.c
> +++ b/fs/f2fs/namei.c
> @@ -223,8 +223,6 @@ static int f2fs_unlink(struct inode *dir, struct dentry 
> *dentry)
>   struct page *page;
>   int err = -ENOENT;
>  
> - f2fs_balance_fs(sbi);
> -
>   de = f2fs_find_entry(dir, >d_name, );
>   if (!de)
>   goto fail;
> @@ -236,6 +234,8 @@ static int f2fs_unlink(struct inode *dir, struct dentry 
> *dentry)
>   goto fail;
>   }
>  
> + f2fs_balance_fs(sbi);
> +

I think we don't need to do this because of no issues on performance and
reliability.
In addition, it would be better to call f2fs_balance_fs without any
dentry page.

>   f2fs_delete_entry(de, page, inode);
>  
>   /* In order to evict this inode,  we set it dirty */

-- 
Jaegeuk Kim
Samsung


signature.asc
Description: This is a digitally signed message part

Re: [git pull] another embarrassing braino fix in signal.git

[David Miller]

From: Al Viro 
Date: Sun, 3 Mar 2013 03:10:56 +

>   generic compat_sys_rt_sigprocmask() had a very dumb braino; I'd
> spent quite a while staring at the offending commit before finally managing
> to spot the idiocy ;-/  Dave, could you verify that it fixes all the problems
> you've seen on sparc?  FWIW, the symptoms I'd been seeing got fixed by that
> and AFAICS your reproducer is also taken care of.  The fix is definitely
> needed; the only question is if there's something else going on.  Linus,
> please, pull from
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal for-linus

Yep, it fixed my problems, thanks Al.
--
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 1/5] f2fs: change victim segmap test condition in get_victim_by_default

[Jaegeuk Kim]

2013-03-02 (토), 12:40 +0900, Namjae Jeon:
> From: Namjae Jeon 
> 
> Instead of checking for victim_segmap(FG_GC) OR
> (gc_type == BG_GC) && victim_segmap(BG_GC);
> to continue for the victim selection. The 2 conditions
> can simply be merged and decision can directly be made using 'gc_type'.
> 
> Signed-off-by: Namjae Jeon 
> Signed-off-by: Amit Sahrawat 
> ---
>  fs/f2fs/gc.c |5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> index 94b8a0c..16b4148 100644
> --- a/fs/f2fs/gc.c
> +++ b/fs/f2fs/gc.c
> @@ -266,10 +266,7 @@ static int get_victim_by_default(struct f2fs_sb_info 
> *sbi,
>   }
>   p.offset = ((segno / p.ofs_unit) * p.ofs_unit) + p.ofs_unit;
>  
> - if (test_bit(segno, dirty_i->victim_segmap[FG_GC]))
> - continue;
> - if (gc_type == BG_GC &&
> - test_bit(segno, dirty_i->victim_segmap[BG_GC]))
> + if (test_bit(segno, dirty_i->victim_segmap[gc_type]))

Negative.
We should check FG_GC all the time.
Thanks,

>   continue;
>   if (IS_CURSEC(sbi, GET_SECNO(sbi, segno)))
>   continue;

-- 
Jaegeuk Kim
Samsung


signature.asc
Description: This is a digitally signed message part

Re: user ns: arbitrary module loading

[Eric W. Biederman]

"Serge E. Hallyn"  writes:

> Quoting Kees Cook (keesc...@google.com):
>> The rearranging done for user ns has resulted in allowing arbitrary
>> kernel module loading[1] (i.e. re-introducing a form of CVE-2011-1019)
>> by what is assumed to be an unprivileged process.
>> 
>> At present, it does look to require at least CAP_SETUID along the way
>> to set up the uidmap (but things like the setuid helper newuidmap
>> might soon start providing such a thing by default).

CAP_SETUID is not needed.

>> It might be worth examining GRKERNSEC_MODHARDEN in grsecurity, which
>> examines module symbols to verify that request_module() for a
>> filesystem only loads a module that defines "register_filesystem"
>> (among other things).
>> 
>> -Kees
>> 
>> [1] https://twitter.com/grsecurity/status/307473816672665600
>
> So the concern is root in a child user namespace doing
>
>   mount -t randomfs <...>
>
> in which case do_new_mount() checks ns_capable(), not capable(),
> before trying to load a module for randomfs.
>
> As well as (secondly) the fact that there is no enforcement on
> the format of the module names (i.e. fs-*).
>
> Kees, from what I've seen the GRKERNSEC_MODHARDEN won't be acceptable.
> At least Eric Paris is strongly against it.

What is wrong with GRKERNSEC_MODHARDEN?  It took a quick look and the
code is far from clean.  But that would not be a fundamental objection
from keeping code like that out of the kernel.

It is also entertaining to read security code that won't even build with
CONFIG_UIDGID_STRICT_TYPE_CHECKS enabled.

> But how about if we
> add a check for 'current_user_ns() == _user_ns' at that place
> instead?
>
> Eric Biederman, do you have any objections to that?

The obvious solution here is to test for CAP_SYS_ADMIN rather than
current_user_ns == _user_ns before we request the module here.  As
that is what was previously required on this path.

Reading the comments the concerns are.
- Non-root users are allowed to load obscure and possibly kernel
  modules.
- get_fs_type can trigger the load of any kernel module.

At a practical level I don't see adding a capalbe(CAP_SYS_ADMIN) check
as having much effect for the functionality currently present in user
namespaces today as the filesystems that an legal to mount in a user
namespace (ramfs, tmpfs, mqueuefs, sysfs, proc, devpts) are so common
most of them can not even be built as modules and even if they are
modules the modules will already be loaded.  So I will see about adding
a capable(CAP_SYS_ADMIN) check to shore things up for the short term.

In the longer term I very much would like to get loopback devices
and mounts of filesystems on those loopback devices working, and being
able to mount filesystems from usb sticks that people commonly plug in,
and remove the need for privileged daemons to do that work.  At that
point manually having to do something that was automatic before will
either mean a regression in functionality or bugs as people manually
load things.


So I am wondering what I a good policy should be.  Should we trust
kernel modules to not be buggy (especially if they were signed as part
of the build process)?  Do we add some defense in depth and add
filesystem registration magic?  Thinking...

We can limit the request_module in get_fs_type to just filesystems
fairly easily.

In include/linux/fs.h:

#define MODULE_ALIAS_FS(type) MODULE_ALIAS("fs-" __stringify(type))

In fs/filesystems.c:

if (request_moudle("fs-%.*s", len, name) == 0)

Then just add the appropriate MODULE_ALIAS_FS lines in all of the
filesystems.  This also allows user space to say set the module loading
policy for filesystems using the blacklist and the alias keywords
in /etc/modprobe.d/*.conf.

That seems a whole lot simpler, more powerful and more maintainable than
what little I saw in GRKERNSEC_MODHARDEN to prevent loading of
non-filesystem modules from get_fs_type.

Eric

p.s.  This is the patch I am looking at pushing to Linus in the near
future.

diff --git a/fs/filesystems.c b/fs/filesystems.c
index da165f6..5b0644d 100644
--- a/fs/filesystems.c
+++ b/fs/filesystems.c
@@ -273,7 +273,8 @@ struct file_system_type *get_fs_type(const char *name)
int len = dot ? dot - name : strlen(name);
 
fs = __get_fs_type(name, len);
-   if (!fs && (request_module("%.*s", len, name) == 0))
+   if (!fs && capable(CAP_SYS_ADMIN) &&
+   (request_module("%.*s", len, name) == 0))
fs = __get_fs_type(name, len);
 
if (dot && fs && !(fs->fs_flags & FS_HAS_SUBTYPE)) {



--
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: user ns: arbitrary module loading

[Serge E. Hallyn]

Quoting Kees Cook (keesc...@google.com):
> On Sat, Mar 2, 2013 at 4:57 PM, Serge E. Hallyn  wrote:
> > Quoting Kees Cook (keesc...@google.com):
> >> The rearranging done for user ns has resulted in allowing arbitrary
> >> kernel module loading[1] (i.e. re-introducing a form of CVE-2011-1019)
> >> by what is assumed to be an unprivileged process.
> >>
> >> At present, it does look to require at least CAP_SETUID along the way
> >> to set up the uidmap (but things like the setuid helper newuidmap
> >> might soon start providing such a thing by default).
> >>
> >> It might be worth examining GRKERNSEC_MODHARDEN in grsecurity, which
> >> examines module symbols to verify that request_module() for a
> >> filesystem only loads a module that defines "register_filesystem"
> >> (among other things).
> >>
> >> -Kees
> >>
> >> [1] https://twitter.com/grsecurity/status/307473816672665600
> >
> > So the concern is root in a child user namespace doing
> >
> > mount -t randomfs <...>
> >
> > in which case do_new_mount() checks ns_capable(), not capable(),
> > before trying to load a module for randomfs.
> 
> Well, not just randomfs. Any module that modprobe in the init ns can find.

right

> > As well as (secondly) the fact that there is no enforcement on
> > the format of the module names (i.e. fs-*).
> >
> > Kees, from what I've seen the GRKERNSEC_MODHARDEN won't be acceptable.
> > At least Eric Paris is strongly against it.
> 
> I'd be curious to hear the objections. It seems pretty nice to me to

Wait, sorry, I mis-spoke.  The objection would have been to requiring
CAP_SYS_MODULE, which is different.  Sorry!

> add a new argument to every request_module() that specifies the
> "subsystem" it expects a module to load from. Maybe pass
> "request_module=filesystem" or "...=netdev" to the modprobe call. And

That would be useful for adding to the separation of privileges,
i.e. helping contain the leaking of posix caps.  It sounds good to
me.

> then in init_module(), check the userargs for which subsystem was
> requested and look up in a table for the entry point module symbol for
> that subsystem to require. e.g. for "request_module=filesystem",
> require that the module contains the "register_filesystem" symbol,
> etc.
> 
> > But how about if we
> > add a check for 'current_user_ns() == _user_ns' at that place
> > instead?
> 
> Well, we'd need to mostly revert
> 57eccb830f1cc93d4b506ba306d8dfa685e0c88f ("mount: consolidate
> permission checks") since get_fs_type() is being called before
> may_mount() right now. (And then, as you suggest, we should strengthen
> the test.) I think this will require either more plumbing into
> get_fs_type (something like "bool load_module_if_missing") or the
> subsystem verification stuff in request_module. I think the latter is
> MUCH nicer as it covers this problem in all places, not just this
> "mount" case.

My first instinct was to say I'd like to have the kernel 100% belonging
to the init_user_ns, with child user namespaces having zero ability to
induce loading of any kernel modules, period.  So a check for current
being in init_user_ns at request_module itself.

However (thinking more) that seems maybe wrong.  You don't need privs to
induce the loading of a new binfmt module right?  The host's
/lib/modules and module blacklists should be set up right by the admin
(or distro)...  If we require that the host admin manually modprobe
every module which a task in a child user namespace might need, that
goes counter to the goal of kernel modules.

> > Eric Biederman, do you have any objections to that?

-serge
--
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: sendfile and EAGAIN

[H. Peter Anvin]

On 02/25/2013 09:22 AM, Ulrich Drepper wrote:
> When using sendfile with a non-blocking output file descriptor for a
> socket the operation can cause a partial write because of capacity
> issues.  This is nothing critical and the operation could resume after
> the output queue is cleared.  The problem is: there is no way to
> determine where to resume.
> 
> The system call just returns -EAGAIN without any further indication.
> The caller doesn't know what to resend.

This is IMO just a bug.  EAGAIN should only be used in the zero-byte
case and in other cases it should return the number of bytes
transferred, just like all the read/write system calls.

This was clearly also the intent.

-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
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: [ 019/150] serial_core: Fix type definition for PORT_BRCM_TRUMANAGE.

[Ben Hutchings]

I've queued up the following for 3.2.y.  Let me know if you see any
issue with this or want to ack it.

Ben.

---
From: Ben Hutchings 
Subject: 8250: use correct value for PORT_BRCM_TRUMANAGE
Date: Sun, 03 Mar 2013 03:24:34 +

When backporting commit ebebd49a8eab ('8250/16?50: Add support for
Broadcom TruManage redirected serial port') I took the next
available port type number for PORT_BRCM_TRUMANAGE (22).

However, the 8250 port type numbers are exposed to userland through
the TIOC{G,S}SERIAL ioctls and so must remain stable.  Redefine
PORT_BRCM_TRUMANAGE as 25, matching mainline as of commit
85f024401bf807.

This leaves port types 22-24 within the valid range for 8250 but not
implemented there.  Change serial8250_verify_port() to specifically
reject these and change serial8250_type() to return "unknown" for them
(though I'm not sure why it would ever see them).

Signed-off-by: Ben Hutchings 
---
--- a/drivers/tty/serial/8250.c
+++ b/drivers/tty/serial/8250.c
@@ -2695,7 +2695,7 @@ serial8250_verify_port(struct uart_port
if (ser->irq >= nr_irqs || ser->irq < 0 ||
ser->baud_base < 9600 || ser->type < PORT_UNKNOWN ||
ser->type >= ARRAY_SIZE(uart_config) || ser->type == PORT_CIRRUS ||
-   ser->type == PORT_STARTECH)
+   ser->type == PORT_STARTECH || uart_config[ser->type].name == NULL)
return -EINVAL;
return 0;
 }
@@ -2705,7 +2705,7 @@ serial8250_type(struct uart_port *port)
 {
int type = port->type;
 
-   if (type >= ARRAY_SIZE(uart_config))
+   if (type >= ARRAY_SIZE(uart_config) || uart_config[type].name == NULL)
type = 0;
return uart_config[type].name;
 }
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -47,8 +47,8 @@
 #define PORT_U6_16550A 19  /* ST-Ericsson U6xxx internal UART */
 #define PORT_TEGRA 20  /* NVIDIA Tegra internal UART */
 #define PORT_XR17D15X  21  /* Exar XR17D15x UART */
-#define PORT_BRCM_TRUMANAGE22
-#define PORT_MAX_8250  22  /* max port ID */
+#define PORT_BRCM_TRUMANAGE25
+#define PORT_MAX_8250  25  /* max port ID */
 
 /*
  * ARM specific type numbers.  These are not currently guaranteed

-- 
Ben Hutchings
Time is nature's way of making sure that everything doesn't happen at once.


signature.asc
Description: This is a digitally signed message part

[GIT PULL] ext4 bug fixes for 3.9

[Theodore Ts'o]

The following changes since commit 8e919d13048cd5acaadb2b15b48acbfb8832d3c2:

  ext4: fix extent status tree regression for file systems > 512GB (2013-02-27 
14:54:37 -0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git 
tags/ext4_for_linus

for you to fetch changes up to 9b2ff35753c0512bc8c6adae9e9c87cbeee86f82:

  ext4: enable quotas before orphan cleanup (2013-03-02 18:22:38 -0500)


Various bug fixes for ext4.  The most important is a fix for the new
extent cache's slab shrinker which can cause significant, user-visible
pauses when the system is under memory pressure.


Dmitry Monakhov (1):
  jbd2: fix ERR_PTR dereference in jbd2__journal_start

Jan Kara (2):
  ext4: don't allow quota mount options when quota feature enabled
  ext4: enable quotas before orphan cleanup

Lukas Czerner (1):
  ext4: convert number of blocks to clusters properly

Theodore Ts'o (2):
  ext4: optimize ext4_es_shrink()
  ext4: use percpu counter for extent cache count

Wei Yongjun (1):
  ext4: fix possible memory leak in ext4_remount()

Zheng Liu (1):
  ext4: fix a warning from sparse check for ext4_dir_llseek

 fs/ext4/balloc.c|  2 +-
 fs/ext4/dir.c   |  2 +-
 fs/ext4/ext4.h  |  1 +
 fs/ext4/extents_status.c| 39 +--
 fs/ext4/mballoc.c   |  8 
 fs/ext4/resize.c|  6 +++---
 fs/ext4/super.c | 61 
+++--
 fs/jbd2/transaction.c   |  2 +-
 include/trace/events/ext4.h | 40 
 9 files changed, 79 insertions(+), 82 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: sendfile and EAGAIN

[Ulrich Drepper]

On Sat, Mar 2, 2013 at 10:09 PM, Eric Dumazet  wrote:
>
> Using non blocking IO means the sender (and the receiver) must be able
> to perform several operations, as long as the whole transfert is not
> finished.

Certainly, and this is implemented.  But the receiver never gets the
rest of the data while the sender (most of the time) gets notified
that everything is sent.

I don't have a reduced test case yet.  Hopefully I'll get to it
sometime soon.  For now I worked around it by not using sendfile.
--
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/

[git pull] another embarrassing braino fix in signal.git

[Al Viro]

generic compat_sys_rt_sigprocmask() had a very dumb braino; I'd
spent quite a while staring at the offending commit before finally managing
to spot the idiocy ;-/  Dave, could you verify that it fixes all the problems
you've seen on sparc?  FWIW, the symptoms I'd been seeing got fixed by that
and AFAICS your reproducer is also taken care of.  The fix is definitely
needed; the only question is if there's something else going on.  Linus,
please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal for-linus

Shortlog:
Al Viro (1):
  fix compat_sys_rt_sigprocmask()

Diffstat:
 kernel/signal.c |2 +-
 1 files changed, 1 insertions(+), 1 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: sendfile and EAGAIN

[Eric Dumazet]

On Sat, 2013-03-02 at 20:41 -0500, Ulrich Drepper wrote:
> On Mon, Feb 25, 2013 at 2:22 PM, Eric Dumazet  wrote:
> > I don't understand the issue.
> >
> > sendfile() returns -EAGAIN only if no bytes were copied to the socket.
> 
> There is something wrong/unexpected/...
> 
> I have a program which can use either sendfile or send.  When using
> sendfile to transmit a large block (I've seen it with 900k) the
> sendfile call does not transmit everything.  There receiver gets only
> about 600k.  This is the situation when I think I've seen EAGAIN
> errors from sendmail but I cannot just now reproduce it.  This is with
> sockets of AF_UNIX type.

There is no real sendfile() support for AF_UNIX.

It does a copy.

( sock_no_sendpage() fallback )

> 
> Are there any limits to take into account?


This is totally expected that sendfile() doesn't queue the whole file,
if the transport is slower than the producer.

You cant ask for non blocking operation and expect sendfile() storing
Gigabytes of data in the kernel, even if its only meta data.

Using non blocking IO means the sender (and the receiver) must be able
to perform several operations, as long as the whole transfert is not
finished.



--
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: [ 019/150] serial_core: Fix type definition for PORT_BRCM_TRUMANAGE.

[Ben Hutchings]

On Wed, 2013-02-27 at 16:39 -0800, Greg Kroah-Hartman wrote:
> On Thu, Feb 28, 2013 at 12:05:59AM +, Ben Hutchings wrote:
> > On Tue, 2013-02-26 at 15:54 -0800, Greg Kroah-Hartman wrote:
[...]
> > > --- a/include/uapi/linux/serial_core.h
> > > +++ b/include/uapi/linux/serial_core.h
> > > @@ -50,7 +50,7 @@
> > >  #define PORT_LPC3220 22  /* NXP LPC32xx SoC "Standard" UART */
> > >  #define PORT_8250_CIR23  /* CIR infrared port, has its own 
> > > driver */
> > >  #define PORT_XR17V35X24  /* Exar XR17V35x UARTs */
> > > -#define PORT_BRCM_TRUMANAGE  24
> > > +#define PORT_BRCM_TRUMANAGE  25
> > >  #define PORT_MAX_825025  /* max port ID */
> > >  
> > >  /*
> > 
> > Hang on, this is a uapi header - are these numbers actually used by
> > userland or are they really internal to the 8250 drivers?
> 
> Interesting, I think they are internal to the 8250 drivers, as I don't
> see how the number can be exported to userspace.  So they should
> probably be moved into 8250.c somewhere.
> 
> But I could be wrong, this code is so old it's scary, hopefully no one
> really is using this number in userspace.
> 
> Only one way to find out, care to make up a patch for me to apply and
> queue up for 3.10?

It looks like they appear in serial_struct::type when the
TIOC{G,S}SERIAL ioctls are used.  Some of the values are also defined in
, which is fine as long as the definitions are
token-wise identical.

For backported versions I had better not renumber them... oops, I'll go
and fix that now.  (Only reason I did so was because it looked like 8250
wouldn't cope with discontiguous numbering.)

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that everything doesn't happen at once.


signature.asc
Description: This is a digitally signed message part

Re: [RFC PATCH 1/2] ipc: introduce obtaining a lockless ipc object

[Rik van Riel]

On 03/01/2013 11:32 PM, Michel Lespinasse wrote:


I think it may be nicer to take the rcu read lock at the call site
rather than in ipc_obtain_object(), to make the rcu read lock/unlock
sites pair up more nicely. Either that or make an inline
ipc_release_object function that pairs up with ipc_obtain_object() and
just does an rcu_read_unlock().


I started on a patch series to untangle the IPC locking, so
it will be a little more readable, and easier to maintain.

It is a slower approach than Davidlohr's, as in, it will take
a little longer to put a patch series together, but I hope it
will be easier to debug...

I hope to post a first iteration of the series by the middle
of next week.

--
All rights reversed
--
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] late arch/metag fixes for v3.9-rc1

[Stephen Rothwell]

Hi James,

On Sat, 2 Mar 2013 16:22:15 + James Hogan  wrote:
>
> On 2 March 2013 15:48, Stephen Rothwell  wrote:
> > On Sat, 2 Mar 2013 10:22:40 + James Hogan  
> > wrote:
> >>
> >> Okay, I've rebased the arch/metag tree onto mainline to make all the
> >> back-merges unnecessary and applied those simple fixes into "Build
> >> infrastructure" and "Various other headers" commits (additionally
> >> trivially removing ARCH_NO_VIRT_TO_BUS which is also now unnecessary).
> >
> > Pleas make sure that what you are submitting to Linus is the same as what
> > you have in linux-next (i.e. reset your for-next branch as well).
> 
> Yes, for-next now moved to the rebased version.

Thanks.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpbE8QfBo7Gp.pgp
Description: PGP signature

[PATCH 06/14] MAINTAINERS: fix drivers/edac/ghes-edac.c

[Cesar Eduardo Barros]

Cc: Mauro Carvalho Chehab 
Cc: linux-e...@vger.kernel.org
Signed-off-by: Cesar Eduardo Barros 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index e909cd3..2e1443c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2899,7 +2899,7 @@ M:Mauro Carvalho Chehab 
 L: linux-e...@vger.kernel.org
 W: bluesmoke.sourceforge.net
 S: Maintained
-F: drivers/edac/ghes-edac.c
+F: drivers/edac/ghes_edac.c
 
 EDAC-I82443BXGX
 M: Tim Small 
-- 
1.7.11.7

--
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 07/14] MAINTAINERS: remove eexpress

[Cesar Eduardo Barros]

This driver was removed by commit f84932d (drivers/net: delete ISA intel
eexpress and eepro i825xx drivers).

Cc: Paul Gortmaker 
Cc: Philip Blundell 
Cc: net...@vger.kernel.org
Signed-off-by: Cesar Eduardo Barros 
---
 MAINTAINERS | 6 --
 1 file changed, 6 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2e1443c..92718d8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3057,12 +3057,6 @@ T:   git 
git://git.kernel.org/pub/scm/linux/kernel/git/kristoffer/linux-hpc.git
 F: drivers/video/s1d13xxxfb.c
 F: include/video/s1d13xxxfb.h
 
-ETHEREXPRESS-16 NETWORK DRIVER
-M: Philip Blundell 
-L: net...@vger.kernel.org
-S: Maintained
-F: drivers/net/ethernet/i825xx/eexpress.*
-
 ETHERNET BRIDGE
 M: Stephen Hemminger 
 L: bri...@lists.linux-foundation.org
-- 
1.7.11.7

--
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 05/14] MAINTAINERS: remove drivers/net/wan/cycx*

[Cesar Eduardo Barros]

This driver was removed by commit 6fcdf4f (wanrouter: delete now
orphaned header content, files/drivers).

Cc: Paul Gortmaker 
Cc: Arnaldo Carvalho de Melo 
Cc: net...@vger.kernel.org
Signed-off-by: Cesar Eduardo Barros 
---
 MAINTAINERS | 6 --
 1 file changed, 6 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 261b245..e909cd3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2357,12 +2357,6 @@ W:   http://www.arm.linux.org.uk/
 S: Maintained
 F: drivers/video/cyber2000fb.*
 
-CYCLADES 2X SYNC CARD DRIVER
-M: Arnaldo Carvalho de Melo 
-W: http://oops.ghostprotocols.net:81/blog
-S: Maintained
-F: drivers/net/wan/cycx*
-
 CYCLADES ASYNC MUX DRIVER
 W: http://www.cyclades.com/
 S: Orphan
-- 
1.7.11.7

--
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 04/14] MAINTAINERS: fix drivers/media/i2c/cx2341x.c

[Cesar Eduardo Barros]

This file was moved to drivers/media/common/ by commit 6259582 ([media]
cx2341x: move from media/i2c to media/common).

Cc: Hans Verkuil 
Cc: linux-me...@vger.kernel.org
Signed-off-by: Cesar Eduardo Barros 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5af82f9..261b245 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2286,7 +2286,7 @@ L:linux-me...@vger.kernel.org
 T: git git://linuxtv.org/media_tree.git
 W: http://linuxtv.org
 S: Maintained
-F: drivers/media/i2c/cx2341x*
+F: drivers/media/common/cx2341x*
 F: include/media/cx2341x*
 
 CX88 VIDEO4LINUX DRIVER
-- 
1.7.11.7

--
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 08/14] MAINTAINERS: fix mach-omap2 clockdomain/powerdomain

[Cesar Eduardo Barros]

The code in these files was moved to cm*.[ch] and prm*.[ch] in the same
directory by commits 4981539 (ARM: OMAP2+: powerdomain/PRM: move the
low-level powerdomain functions into PRM) and 4bd5259 (ARM: OMAP2/3:
clockdomain/PRM/CM: move the low-level clockdomain functions into
PRM/CM).

I am not sure if this fix is correct, since there are other things in
these files. Please NAK this patch (and propose a better one) if it is
wrong.

Cc: Paul Walmsley 
Cc: Rajendra Nayak 
Cc: Russ Dill 
Cc: Santosh Shilimkar 
Cc: linux-o...@vger.kernel.org
Signed-off-by: Cesar Eduardo Barros 
---
 MAINTAINERS | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 92718d8..46c1288 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5651,10 +5651,8 @@ M:   Rajendra Nayak 
 M: Paul Walmsley 
 L: linux-o...@vger.kernel.org
 S: Maintained
-F: arch/arm/mach-omap2/powerdomain2xxx_3xxx.c
-F: arch/arm/mach-omap2/powerdomain44xx.c
-F: arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
-F: arch/arm/mach-omap2/clockdomain44xx.c
+F: arch/arm/mach-omap2/cm*.[ch]
+F: arch/arm/mach-omap2/prm*.[ch]
 
 OMAP AUDIO SUPPORT
 M: Peter Ujfalusi 
-- 
1.7.11.7

--
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 09/14] MAINTAINERS: fix Documentation/video4linux/saa7134/

[Cesar Eduardo Barros]

That directory never existed. The intention was probably to match
CARDLIST.saa7134 and README.saa7134.

Cc: Mauro Carvalho Chehab 
Cc: linux-me...@vger.kernel.org
Signed-off-by: Cesar Eduardo Barros 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 46c1288..44b9f69 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6741,7 +6741,7 @@ L:linux-me...@vger.kernel.org
 W: http://linuxtv.org
 T: git git://linuxtv.org/media_tree.git
 S: Odd fixes
-F: Documentation/video4linux/saa7134/
+F: Documentation/video4linux/*.saa7134
 F: drivers/media/pci/saa7134/
 
 SAA7146 VIDEO4LINUX-2 DRIVER
-- 
1.7.11.7

--
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 10/14] MAINTAINERS: remove include/media/sh_veu.h

[Cesar Eduardo Barros]

Apparently a copy-paste mistake; the similar sh_vou.h exists, and both
were added to MAINTAINERS by commit b618b69 ([media] MAINTAINERS: add
entries for sh_veu and sh_vou V4L2 drivers).

Cc: Guennadi Liakhovetski 
Cc: Mauro Carvalho Chehab 
Cc: linux-me...@vger.kernel.org
Signed-off-by: Cesar Eduardo Barros 
---
 MAINTAINERS | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 44b9f69..5cb888a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7088,7 +7088,6 @@ M:Guennadi Liakhovetski 
 L: linux-me...@vger.kernel.org
 S: Maintained
 F: drivers/media/platform/sh_veu.c
-F: include/media/sh_veu.h
 
 SH_VOU V4L2 OUTPUT DRIVER
 M: Guennadi Liakhovetski 
-- 
1.7.11.7

--
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 01/14] MAINTAINERS: remove 3c505

[Cesar Eduardo Barros]

This driver was removed by commit 0e245db (drivers/net: delete the 3Com
3c505/3c507 intel i825xx support).

Cc: Paul Gortmaker 
Cc: Philip Blundell 
Cc: net...@vger.kernel.org
Signed-off-by: Cesar Eduardo Barros 
---
 MAINTAINERS | 6 --
 1 file changed, 6 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index aea0adf..5b64aa5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -114,12 +114,6 @@ Maintainers List (try to look for most precise areas first)
 
---
 
-3C505 NETWORK DRIVER
-M: Philip Blundell 
-L: net...@vger.kernel.org
-S: Maintained
-F: drivers/net/ethernet/i825xx/3c505*
-
 3C59X NETWORK DRIVER
 M: Steffen Klassert 
 L: net...@vger.kernel.org
-- 
1.7.11.7

--
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 13/14] scripts: add checkmaintainers.py

[Cesar Eduardo Barros]

This small script checks the file patterns in the MAINTAINERS file.

For every file pattern, it checks if the pattern matches any file or
directory in the kernel tree, printing the patterns which do not have a
match.

It also checks for any file pattern pointing to any of the include
directories which does not have a corresponding UAPI file pattern, but
only if the UAPI file pattern would have a match. It also does the same
in the opposite direction.

The script is written in Python; I found its glob function more
well-behaved than Perl's. It should work on both Python 2 and Python 3
without any changes (not even 2to3 is needed); tested on 2.7, 3.2, and
3.3.

I do not think such a short script should have a copyright. But to avoid
any problems, I arbitrarily used the "GNU All-Permissive License" (found
in FSF's GPL-compatible list). If needed, feel free to relicense it as
GPLv2+, 3-clause BSD, or even WTFPLv2 or CC0.

Cc: David Howells 
Cc: Joe Perches 
Signed-off-by: Cesar Eduardo Barros 
---
 scripts/checkmaintainers.py | 35 +++
 1 file changed, 35 insertions(+)
 create mode 100755 scripts/checkmaintainers.py

diff --git a/scripts/checkmaintainers.py b/scripts/checkmaintainers.py
new file mode 100755
index 000..99740e3
--- /dev/null
+++ b/scripts/checkmaintainers.py
@@ -0,0 +1,35 @@
+#!/usr/bin/python
+# Quick check for missing file patterns in the MAINTAINERS file.
+#
+# Copyright (C) 2012 Cesar Eduardo Barros 
+#
+# Copying and distribution of this file, with or without modification,
+# are permitted in any medium without royalty provided the copyright
+# notice and this notice are preserved.  This file is offered as-is,
+# without any warranty.
+
+from __future__ import print_function, unicode_literals, with_statement
+from glob import glob
+
+seen = set()
+
+with open('MAINTAINERS', 'rb') as f:
+for line in f:
+line = line.decode('utf-8')
+if line.startswith('F:'):
+pattern = line.partition(':')[2].strip()
+seen.add(pattern)
+
+if not glob(pattern):
+print('No match for F: {0}'.format(pattern))
+
+# Check for missing uapi/ pattern
+for pattern in seen:
+if 'include/' in pattern:
+if 'include/uapi/' in pattern:
+other = pattern.replace('include/uapi/', 'include/')
+else:
+other = pattern.replace('include/', 'include/uapi/')
+
+if other not in seen and glob(other):
+print('Missing {0} for {1}'.format(other, pattern))
-- 
1.7.11.7

--
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 11/14] MAINTAINERS: fix BAST

[Cesar Eduardo Barros]

These files were renamed by commit 85fd6d6 (ARM: S3C2410: move
mach-s3c2410/* into mach-s3c24xx/).

Cc: Ben Dooks 
Cc: Vincent Sanders 
Cc: Simtec Linux Team 
Cc: Paul Bolle 
Signed-off-by: Cesar Eduardo Barros 
---
 MAINTAINERS | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5cb888a..b73c00d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7119,9 +7119,9 @@ P:Vincent Sanders 
 M: Simtec Linux Team 
 W: http://www.simtec.co.uk/products/EB2410ITX/
 S: Supported
-F: arch/arm/mach-s3c2410/mach-bast.c
-F: arch/arm/mach-s3c2410/bast-ide.c
-F: arch/arm/mach-s3c2410/bast-irq.c
+F: arch/arm/mach-s3c24xx/mach-bast.c
+F: arch/arm/mach-s3c24xx/bast-ide.c
+F: arch/arm/mach-s3c24xx/bast-irq.c
 
 TI DAVINCI MACHINE SUPPORT
 M: Sekhar Nori 
-- 
1.7.11.7

--
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 14/14] MAINTAINERS: use same pattern for firewire in uapi

[Cesar Eduardo Barros]

This avoids a false positive in the checkmaintainers.py script.

Cc: Stefan Richter 
Cc: linux1394-de...@lists.sourceforge.net
Signed-off-by: Cesar Eduardo Barros 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 772da4f..022317b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3236,7 +3236,7 @@ W:http://ieee1394.wiki.kernel.org/
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git
 S: Maintained
 F: drivers/firewire/
-F: include/linux/firewire.h
+F: include/linux/firewire*.h
 F: include/uapi/linux/firewire*.h
 F: tools/firewire/
 
-- 
1.7.11.7

--
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 12/14] MAINTAINERS: adjust for UAPI (part 2)

[Cesar Eduardo Barros]

More headers were moved or split to uapi/ since the last patch was
created.

Cc: David Howells 
Signed-off-by: Cesar Eduardo Barros 
---
 MAINTAINERS | 24 
 1 file changed, 24 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b73c00d..772da4f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -474,6 +474,7 @@ L:  linux-...@kvack.org
 S: Supported
 F: fs/aio.c
 F: include/linux/*aio*.h
+F: include/uapi/linux/*aio*.h
 
 ALCATEL SPEEDTOUCH USB DRIVER
 M: Duncan Sands 
@@ -2178,6 +2179,7 @@ L:cgro...@vger.kernel.org
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git
 S: Maintained
 F: include/linux/cgroup*
+F: include/uapi/linux/cgroup*
 F: kernel/cgroup*
 F: mm/*cgroup*
 
@@ -2493,6 +2495,7 @@ F:drivers/md/dm*
 F: drivers/md/persistent-data/
 F: include/linux/device-mapper.h
 F: include/linux/dm-*.h
+F: include/uapi/linux/dm-*.h
 
 DIOLAN U2C-12 I2C DRIVER
 M: Guenter Roeck 
@@ -3064,6 +3067,7 @@ L:net...@vger.kernel.org
 W: http://www.linuxfoundation.org/en/Net:Bridge
 S: Maintained
 F: include/linux/netfilter_bridge/
+F: include/uapi/linux/netfilter_bridge/
 F: net/bridge/
 
 EXT2 FILE SYSTEM
@@ -4557,6 +4561,7 @@ S:Supported
 F: Documentation/*/kvm.txt
 F: arch/*/kvm/
 F: arch/*/include/asm/kvm*
+F: arch/*/include/uapi/asm/kvm*
 F: include/linux/kvm*
 F: include/uapi/linux/kvm*
 F: virt/kvm/
@@ -4567,6 +4572,7 @@ L:k...@vger.kernel.org
 W: http://kvm.qumranet.com
 S: Maintained
 F: arch/x86/include/asm/svm.h
+F: arch/x86/include/uapi/asm/svm.h
 F: arch/x86/kvm/svm.c
 
 KERNEL VIRTUAL MACHINE (KVM) FOR POWERPC
@@ -4576,6 +4582,7 @@ W:http://kvm.qumranet.com
 T: git git://github.com/agraf/linux-2.6.git
 S: Supported
 F: arch/powerpc/include/asm/kvm*
+F: arch/powerpc/include/uapi/asm/kvm*
 F: arch/powerpc/kvm/
 
 KERNEL VIRTUAL MACHINE For Itanium (KVM/IA64)
@@ -4585,6 +4592,7 @@ W:http://kvm.qumranet.com
 S: Supported
 F: Documentation/ia64/kvm.txt
 F: arch/ia64/include/asm/kvm*
+F: arch/ia64/include/uapi/asm/kvm*
 F: arch/ia64/kvm/
 
 KERNEL VIRTUAL MACHINE for s390 (KVM/s390)
@@ -4596,6 +4604,7 @@ W:
http://www.ibm.com/developerworks/linux/linux390/
 S: Supported
 F: Documentation/s390/kvm.txt
 F: arch/s390/include/asm/kvm*
+F: arch/s390/include/uapi/asm/kvm*
 F: arch/s390/kvm/
 F: drivers/s390/kvm/
 
@@ -5122,6 +5131,7 @@ F:Documentation/DocBook/media/
 F: drivers/media/
 F: drivers/staging/media/
 F: include/media/
+F: include/linux/videodev2.h
 F: include/uapi/linux/dvb/
 F: include/uapi/linux/videodev2.h
 F: include/uapi/linux/media.h
@@ -5223,6 +5233,7 @@ MODULE SUPPORT
 M: Rusty Russell 
 S: Maintained
 F: include/linux/module.h
+F: include/uapi/linux/module.h
 F: kernel/module.c
 
 MOTION EYE VAIO PICTUREBOOK CAMERA DRIVER
@@ -5907,6 +5918,7 @@ L:linux-parp...@lists.infradead.org 
(subscribers-only)
 S: Orphan
 F: drivers/parport/
 F: include/linux/parport*.h
+F: include/uapi/linux/parport*.h
 F: drivers/char/ppdev.c
 F: include/uapi/linux/ppdev.h
 
@@ -5992,6 +6004,7 @@ S:Supported
 F: Documentation/PCI/
 F: drivers/pci/
 F: include/linux/pci*
+F: include/uapi/linux/pci*
 
 PCMCIA SUBSYSTEM
 P: Linux PCMCIA Team
@@ -6208,6 +6221,7 @@ S:Maintained
 F: Documentation/pps/
 F: drivers/pps/
 F: include/linux/pps*.h
+F: include/uapi/linux/pps*.h
 
 PPTP DRIVER
 M: Dmitry Kozlov 
@@ -6252,6 +6266,7 @@ S:Maintained
 F: arch/powerpc/boot/ps3*
 F: arch/powerpc/include/asm/lv1call.h
 F: arch/powerpc/include/asm/ps3*.h
+F: arch/powerpc/include/uapi/asm/ps3*.h
 F: arch/powerpc/platforms/ps3/
 F: drivers/*/ps3*
 F: drivers/ps3/
@@ -6287,6 +6302,7 @@ F:drivers/net/ethernet/freescale/gianfar_ptp.c
 F: drivers/net/phy/dp83640*
 F: drivers/ptp/*
 F: include/linux/ptp_cl*
+F: include/uapi/linux/ptp_cl*
 
 PTRACE SUPPORT
 M: Roland McGrath 
@@ -6894,6 +6910,7 @@ T:git 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-pending-2.6.git
 S: Maintained
 F: drivers/scsi/
 F: include/scsi/
+F: include/uapi/scsi/
 
 SCSI TAPE DRIVER
 M: Kai Mäkisara 
@@ -6990,6 +7007,7 @@ W:http://selinuxproject.org
 T: git git://git.infradead.org/users/eparis/selinux.git
 S: Supported
 F: include/linux/selinux*
+F: include/uapi/linux/selinux*
 F: security/selinux/
 F: scripts/selinux/
 
@@ -7693,6 +7711,7 @@ M:Balbir Singh 
 S: Maintained
 F: Documentation/accounting/taskstats*
 F: include/linux/taskstats*
+F: include/uapi/linux/taskstats*
 F: kernel/taskstats.c
 
 TC CLASSIFIER
@@ -8258,6 +8277,7 @@ T:git 

[PATCH 02/14] MAINTAINERS: remove arch/arm/plat-nomadik/

[Cesar Eduardo Barros]

The files within that directory were moved to other places over the
course of several commits. I only added the ones moved in the patch
series which finally removed the directory; untangling the rest will
take more work, since some seem to be shared with ux500.

In fact, the ARM/Ux500 ARM ARCHITECTURE block has patterns for files
named "nomadik" too. The patterns in this pair of MAINTAINER blocks
really need a review from the respective maintainters.

Cc: Alessandro Rubini 
Cc: Srinidhi Kasagar 
Cc: Linus Walleij 
Cc: STEricsson 
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Cesar Eduardo Barros 
---
 MAINTAINERS | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5b64aa5..3c074d5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1009,8 +1009,11 @@ M:   STEricsson 

 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
 F: arch/arm/mach-nomadik/
-F: arch/arm/plat-nomadik/
+F: drivers/clocksource/nomadik-mtu.c
 F: drivers/i2c/busses/i2c-nomadik.c
+F: include/linux/platform_data/clocksource-nomadik-mtu.h
+F: include/linux/platform_data/dma-ste-dma40.h
+F: include/linux/platform_data/pinctrl-nomadik.h
 T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git
 
 ARM/OPENMOKO NEO FREERUNNER (GTA02) MACHINE SUPPORT
-- 
1.7.11.7

--
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 00/14] MAINTAINERS: fix file patterns (part 2)

[Cesar Eduardo Barros]

This patch series attempts to fix the remaining F: patterns on the
MAINTAINERS file which point to non-existing files or directories.

Several more problems with the F: patterns appeared since the previous
patch series was sent. This patch series fixes all of them, except for
the removal of drivers/rtc/rtc-sec.c (which was NAKed). It also has a
copy of the single patch from the previous series which was not applied
(fix BAST).

Patch 12 also attempts to add matching uapi/ patterns to all include
directory patterns where this was not yet done, if applicable.

The last two patches in this series are optional. They add the small
script which I used to find the broken patterns, and change one pattern
to avoid a false positive from the script.

Cesar Eduardo Barros (14):
  MAINTAINERS: remove 3c505
  MAINTAINERS: remove arch/arm/plat-nomadik/
  MAINTAINERS: remove arch/arm/plat-s3c24xx/
  MAINTAINERS: fix drivers/media/i2c/cx2341x.c
  MAINTAINERS: remove drivers/net/wan/cycx*
  MAINTAINERS: fix drivers/edac/ghes-edac.c
  MAINTAINERS: remove eexpress
  MAINTAINERS: fix mach-omap2 clockdomain/powerdomain
  MAINTAINERS: fix Documentation/video4linux/saa7134/
  MAINTAINERS: remove include/media/sh_veu.h
  MAINTAINERS: fix BAST
  MAINTAINERS: adjust for UAPI (part 2)
  scripts: add checkmaintainers.py
  MAINTAINERS: use same pattern for firewire in uapi

 MAINTAINERS | 69 -
 scripts/checkmaintainers.py | 35 +++
 2 files changed, 72 insertions(+), 32 deletions(-)
 create mode 100755 scripts/checkmaintainers.py

-- 
1.7.11.7

--
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 03/14] MAINTAINERS: remove arch/arm/plat-s3c24xx/

[Cesar Eduardo Barros]

This directory was removed by commit 09ec1d7 (ARM: S3C24XX: Remove
plat-s3c24xx directory in arch/arm/).

Cc: Kukjin Kim 
Cc: Ben Dooks 
Cc: Russell King 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Signed-off-by: Cesar Eduardo Barros 
---
 MAINTAINERS | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3c074d5..5af82f9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1119,7 +1119,6 @@ L:linux-samsung-...@vger.kernel.org (moderated 
for non-subscribers)
 W: http://www.fluff.org/ben/linux/
 S: Maintained
 F: arch/arm/plat-samsung/
-F: arch/arm/plat-s3c24xx/
 F: arch/arm/mach-s3c24*/
 F: arch/arm/mach-s3c64xx/
 F: drivers/*/*s3c2410*
-- 
1.7.11.7

--
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: sendfile and EAGAIN

[Ulrich Drepper]

On Mon, Feb 25, 2013 at 2:22 PM, Eric Dumazet  wrote:
> I don't understand the issue.
>
> sendfile() returns -EAGAIN only if no bytes were copied to the socket.

There is something wrong/unexpected/...

I have a program which can use either sendfile or send.  When using
sendfile to transmit a large block (I've seen it with 900k) the
sendfile call does not transmit everything.  There receiver gets only
about 600k.  This is the situation when I think I've seen EAGAIN
errors from sendmail but I cannot just now reproduce it.  This is with
sockets of AF_UNIX type.

Are there any limits to take into account?
--
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: user ns: arbitrary module loading

[Kees Cook]

On Sat, Mar 2, 2013 at 4:57 PM, Serge E. Hallyn  wrote:
> Quoting Kees Cook (keesc...@google.com):
>> The rearranging done for user ns has resulted in allowing arbitrary
>> kernel module loading[1] (i.e. re-introducing a form of CVE-2011-1019)
>> by what is assumed to be an unprivileged process.
>>
>> At present, it does look to require at least CAP_SETUID along the way
>> to set up the uidmap (but things like the setuid helper newuidmap
>> might soon start providing such a thing by default).
>>
>> It might be worth examining GRKERNSEC_MODHARDEN in grsecurity, which
>> examines module symbols to verify that request_module() for a
>> filesystem only loads a module that defines "register_filesystem"
>> (among other things).
>>
>> -Kees
>>
>> [1] https://twitter.com/grsecurity/status/307473816672665600
>
> So the concern is root in a child user namespace doing
>
> mount -t randomfs <...>
>
> in which case do_new_mount() checks ns_capable(), not capable(),
> before trying to load a module for randomfs.

Well, not just randomfs. Any module that modprobe in the init ns can find.

> As well as (secondly) the fact that there is no enforcement on
> the format of the module names (i.e. fs-*).
>
> Kees, from what I've seen the GRKERNSEC_MODHARDEN won't be acceptable.
> At least Eric Paris is strongly against it.

I'd be curious to hear the objections. It seems pretty nice to me to
add a new argument to every request_module() that specifies the
"subsystem" it expects a module to load from. Maybe pass
"request_module=filesystem" or "...=netdev" to the modprobe call. And
then in init_module(), check the userargs for which subsystem was
requested and look up in a table for the entry point module symbol for
that subsystem to require. e.g. for "request_module=filesystem",
require that the module contains the "register_filesystem" symbol,
etc.

> But how about if we
> add a check for 'current_user_ns() == _user_ns' at that place
> instead?

Well, we'd need to mostly revert
57eccb830f1cc93d4b506ba306d8dfa685e0c88f ("mount: consolidate
permission checks") since get_fs_type() is being called before
may_mount() right now. (And then, as you suggest, we should strengthen
the test.) I think this will require either more plumbing into
get_fs_type (something like "bool load_module_if_missing") or the
subsystem verification stuff in request_module. I think the latter is
MUCH nicer as it covers this problem in all places, not just this
"mount" case.

> Eric Biederman, do you have any objections to that?
>
> thanks,
> -serge

-Kees

--
Kees Cook
Chrome OS Security
--
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] Btrfs

[Chris Mason]

On Sat, Mar 02, 2013 at 05:45:41PM -0700, Linus Torvalds wrote:
> On Sat, Mar 2, 2013 at 7:15 AM, Chris Mason  wrote:
> >
> > Our set of btrfs features, fixes and cleanups are in my for-linus
> > branch:
> 
> I *really* wish that big pull requests like this would come in earlier
> in the merge window. I hate seeing them the day before I close the
> window - really.  A number of the latter commits are done in the last
> few days, which also smells bad.

Definitely, I wanted to send this earlier in the merge window.  But I
was out last week and also didn't want to send the big stuff (raid 5/6
and the fsync work) to you right before I left on vacation.

So instead I sent things off to linux-next, and everyone on the btrfs
list collected fixes while I was gone.

-chris
--
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: user ns: arbitrary module loading

[Serge E. Hallyn]

Quoting Kees Cook (keesc...@google.com):
> The rearranging done for user ns has resulted in allowing arbitrary
> kernel module loading[1] (i.e. re-introducing a form of CVE-2011-1019)
> by what is assumed to be an unprivileged process.
> 
> At present, it does look to require at least CAP_SETUID along the way
> to set up the uidmap (but things like the setuid helper newuidmap
> might soon start providing such a thing by default).
> 
> It might be worth examining GRKERNSEC_MODHARDEN in grsecurity, which
> examines module symbols to verify that request_module() for a
> filesystem only loads a module that defines "register_filesystem"
> (among other things).
> 
> -Kees
> 
> [1] https://twitter.com/grsecurity/status/307473816672665600

So the concern is root in a child user namespace doing

mount -t randomfs <...>

in which case do_new_mount() checks ns_capable(), not capable(),
before trying to load a module for randomfs.

As well as (secondly) the fact that there is no enforcement on
the format of the module names (i.e. fs-*).

Kees, from what I've seen the GRKERNSEC_MODHARDEN won't be acceptable.
At least Eric Paris is strongly against it.  But how about if we
add a check for 'current_user_ns() == _user_ns' at that place
instead?

Eric Biederman, do you have any objections to that?

thanks,
-serge
--
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] Btrfs

[Linus Torvalds]

On Sat, Mar 2, 2013 at 7:15 AM, Chris Mason  wrote:
>
> Our set of btrfs features, fixes and cleanups are in my for-linus
> branch:

I *really* wish that big pull requests like this would come in earlier
in the merge window. I hate seeing them the day before I close the
window - really.  A number of the latter commits are done in the last
few days, which also smells bad.

   Linus
--
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] efi: be more paranoid about available space when creating variables

[Matthew Garrett]

UEFI variables are typically stored in flash. For various reasons, avaiable
space is typically not reclaimed immediately upon the deletion of a
variable - instead, the system will garbage collect during initialisation
after a reboot.

Some systems appear to handle this garbage collection extremely poorly,
failing if more than 50% of the system flash is in use. This can result in
the machine refusing to boot. The safest thing to do for the moment is to
forbid writes if they'd end up using more than half of the storage space.
We can make this more finegrained later if we come up with a method for
identifying the broken machines.

Signed-off-by: Matthew Garrett 
---
 drivers/firmware/efivars.c | 106 +
 1 file changed, 79 insertions(+), 27 deletions(-)

diff --git a/drivers/firmware/efivars.c b/drivers/firmware/efivars.c
index 7320bf8..0d50497 100644
--- a/drivers/firmware/efivars.c
+++ b/drivers/firmware/efivars.c
@@ -426,6 +426,44 @@ get_var_data(struct efivars *efivars, struct efi_variable 
*var)
return status;
 }
 
+static efi_status_t
+check_var_size_locked(struct efivars *efivars, u32 attributes,
+   unsigned long size)
+{
+   u64 storage_size, remaining_size, max_size;
+   efi_status_t status;
+   const struct efivar_operations *fops = efivars->ops;
+
+   if (!efivars->ops->query_variable_info)
+   return EFI_UNSUPPORTED;
+
+   status = fops->query_variable_info(attributes, _size,
+  _size, _size);
+
+   if (status != EFI_SUCCESS)
+   return status;
+
+   if (!storage_size || size > remaining_size || size > max_size ||
+   (remaining_size - size) < (storage_size / 2))
+   return EFI_OUT_OF_RESOURCES;
+
+   return status;
+}
+
+
+static efi_status_t
+check_var_size(struct efivars *efivars, u32 attributes, unsigned long size)
+{
+   efi_status_t status;
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
+   status = check_var_size_locked(efivars, attributes, size);
+   spin_unlock_irqrestore(>lock, flags);
+
+   return status;
+}
+
 static ssize_t
 efivar_guid_read(struct efivar_entry *entry, char *buf)
 {
@@ -547,11 +585,16 @@ efivar_store_raw(struct efivar_entry *entry, const char 
*buf, size_t count)
}
 
spin_lock_irq(>lock);
-   status = efivars->ops->set_variable(new_var->VariableName,
-   _var->VendorGuid,
-   new_var->Attributes,
-   new_var->DataSize,
-   new_var->Data);
+
+   status = check_var_size_locked(efivars, new_var->Attributes,
+  new_var->DataSize + utf16_strsize(new_var->VariableName, 1024));
+
+   if (status == EFI_SUCCESS || status == EFI_UNSUPPORTED)
+   status = efivars->ops->set_variable(new_var->VariableName,
+   _var->VendorGuid,
+   new_var->Attributes,
+   new_var->DataSize,
+   new_var->Data);
 
spin_unlock_irq(>lock);
 
@@ -702,8 +745,7 @@ static ssize_t efivarfs_file_write(struct file *file,
u32 attributes;
struct inode *inode = file->f_mapping->host;
unsigned long datasize = count - sizeof(attributes);
-   unsigned long newdatasize;
-   u64 storage_size, remaining_size, max_size;
+   unsigned long newdatasize, varsize;
ssize_t bytes = 0;
 
if (count < sizeof(attributes))
@@ -722,28 +764,18 @@ static ssize_t efivarfs_file_write(struct file *file,
 * amounts of memory. Pick a default size of 64K if
 * QueryVariableInfo() isn't supported by the firmware.
 */
-   spin_lock_irq(>lock);
 
-   if (!efivars->ops->query_variable_info)
-   status = EFI_UNSUPPORTED;
-   else {
-   const struct efivar_operations *fops = efivars->ops;
-   status = fops->query_variable_info(attributes, _size,
-  _size, _size);
-   }
-
-   spin_unlock_irq(>lock);
+   varsize = datasize + utf16_strsize(var->var.VariableName, 1024);
+   status = check_var_size(efivars, attributes, varsize);
 
if (status != EFI_SUCCESS) {
if (status != EFI_UNSUPPORTED)
return efi_status_to_err(status);
 
-   remaining_size = 65536;
+   if (datasize > 65536)
+   return -ENOSPC;
}
 
-   if (datasize > remaining_size)
-   return -ENOSPC;
-
data = kmalloc(datasize, GFP_KERNEL);
if (!data)
return -ENOMEM;
@@ -765,6 +797,19 @@ static ssize_t efivarfs_file_write(struct file 

Re: nfsd changes for 3.9

[J. Bruce Fields]

On Thu, Feb 28, 2013 at 01:45:21PM -0500, bfields wrote:
> Please pull nfsd changes for 3.9 from the for-3.9 branch at:
> 
>   git://linux-nfs.org/~bfields/linux.git for-3.9

And thanks for handling the merge problems!  The results look right.

--b.

> 
> Miscellaneous bugfixes, plus:
> 
>   - An overhaul of the DRC cache by Jeff Layton.  The main effect
> is just to make it larger.  This decreases the chances of
> intermittent errors especially in the UDP case.  But we'll
> need to watch for any reports of performance regressions.
> 
>   - Containerized nfsd: with some limitations, we now support
> per-container nfs-service, thanks to extensive work from
> Stanislav Kinsbursky over the last year.
> 
> --b.
> 
> 
> Andriy Skulysh (1):
>   sunrpc: Fix lockd sleeping until timeout
> 
> Fengguang Wu (1):
>   nfsd4: free_stid can be static
> 
> J. Bruce Fields (7):
>   nfsd4: simplify nfsd4_encode_fattr interface slightly
>   svcrpc: silence "unused variable" warning in !RPC_DEBUG case
>   nfsd4: require version 4 when enabling or disabling minorversion
>   nfsd4: simplify idr allocation
>   svcrpc: make svc_age_temp_xprts enqueue under sv_lock
>   svcrpc: fix rpc server shutdown races
>   SUNRPC: make AF_LOCAL connect synchronous
> 
> Jeff Layton (23):
>   nfsd: fix IPv6 address handling in the DRC
>   nfsd: remove unneeded spinlock in nfsd_cache_update
>   nfsd: get rid of RC_INTR
>   nfsd: create a dedicated slabcache for DRC entries
>   nfsd: add alloc and free functions for DRC entries
>   nfsd: remove redundant test from nfsd_reply_cache_free
>   nfsd: clean up and clarify the cache expiration code
>   nfsd: break out hashtable search into separate function
>   nfsd: initialize the exp->ex_uuid field in svc_export_init
>   nfsd: always move DRC entries to the end of LRU list when updating 
> timestamp
>   nfsd: track the number of DRC entries in the cache
>   nfsd: dynamically allocate DRC entries
>   nfsd: remove the cache_disabled flag
>   nfsd: when updating an entry with RC_NOCACHE, just free it
>   nfsd: add recurring workqueue job to clean the cache
>   nfsd: register a shrinker for DRC cache entries
>   sunrpc: copy scope ID in __rpc_copy_addr6
>   sunrpc: move address copy/cmp/convert routines and prototypes from 
> clnt.h to addr.h
>   sunrpc: fix comment in struct xdr_buf definition
>   sunrpc: trim off trailing checksum before returning decrypted or 
> integrity authenticated buffer
>   nfsd: keep a checksum of the first 256 bytes of request
>   nfsd: fix comments on nfsd_cache_lookup
>   nfsd: fix compiler warning about ambiguous types in nfsd_cache_csum
> 
> Stanislav Kinsbursky (11):
>   nfsd: fix unused "nn" variable warning in free_client()
>   NFS: use SUNRPC cache creation and destruction helper for DNS cache
>   NFS: simplify and clean cache library
>   SUNRPC: introduce cache_detail->cache_request callback
>   SUNRPC: rework cache upcall logic
>   SUNRPC: remove "cache_request" argument in sunrpc_cache_pipe_upcall() 
> function
>   SUNRPC: move cache_detail->cache_request callback call to cache_read()
>   nfsd: containerize NFSd filesystem
>   nfsd: use proper net while reading "exports" file
>   nfsd: disable usermode helper client tracker in container
>   nfsd: enable NFSv4 state in containers
> 
> Tim Gardner (1):
>   lockd: nlmclnt_reclaim(): avoid stack overflow
> 
> Yanchuan Nian (3):
>   nfsd: Pass correct slot number to nfsd4_put_drc_mem()
>   nfsd: Don't unlock the state while it's not locked
>   nfsd: Remove write permission from file content
> 
> majianpeng (2):
>   nfsd: Fix memleak in svc_export_put
>   nfsd: Fix memleak
> 
>  fs/lockd/clntlock.c |  14 +-
>  fs/lockd/clntproc.c |   6 +-
>  fs/lockd/host.c |   1 +
>  fs/lockd/mon.c  |   1 +
>  fs/lockd/svcsubs.c  |   2 +-
>  fs/nfs/cache_lib.c  |  12 +-
>  fs/nfs/cache_lib.h  |   2 -
>  fs/nfs/dns_resolve.c|  67 +++
>  fs/nfs/nfs4client.c |   1 +
>  fs/nfs/nfs4filelayoutdev.c  |   1 +
>  fs/nfs/nfs4namespace.c  |   1 +
>  fs/nfs/super.c  |   1 +
>  fs/nfsd/cache.h |  17 +-
>  fs/nfsd/export.c|  16 +-
>  fs/nfsd/fault_inject.c  |   2 +-
>  fs/nfsd/nfs4idmap.c |  16 +-
>  fs/nfsd/nfs4proc.c  |   7 +-
>  fs/nfsd/nfs4recover.c   |   6 +
>  fs/nfsd/nfs4state.c | 102 ++-
>  fs/nfsd/nfs4xdr.c   |  21 +--
>  fs/nfsd/nfscache.c  | 354 
> 
>  

Re: regression in linux 3.7 - fan speed at 100% after suspend/resume at 100%

[Ville Syrjala]

Roberto Oppedisano  gmail.com> writes:

> 
> Hello,
>  with recent kernels after a suspend/resume cycle on my laptop (HP 
> 6730b) the fans stays at full speed.

I too have been hit by this regression w/ a HP Compaq NC6000 laptop.

>From what I can tell 3.7.x gets confused about trip points after resume. Based
on the information in sysfs, it seems to always think that the CPU temp > 65C,
when in fact it's usually 40C or so. Loading the CPU enough to rise the
temperature past the trip point where the kernel thinks we're at seems to
re-synchronize the kernel's reality with the firmware's reality. On a few
occasions however the fan did stop, but the trip points were still confused the
same way. So what happened is that the fan didn't come back to life until I hit
the next higher trip point at 80C. Under normal conditions I've never reached
the 80C trip point on this laptop.

I also tried this tree:
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next
$ git describe
v3.8-rc2-72-gf5b6d45

Sadly I must report that it's even worse than 3.7. Even without any
suspend/resume cycles, the system gets confused. When I heat up the CPU the fan
comes on correctly and speeds up as the temperature rises. Unfortunately when
the temperature drops the fan doesn't slow down at all. So once I hit a high
trip point the fan stays at that speed forever.


--
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: fasync race in fs/fcntl.c

[Russ Dill]

On Sat, Mar 2, 2013 at 11:49 AM, Al Viro  wrote:
> On Sat, Mar 02, 2013 at 03:00:28AM -0800, Russ Dill wrote:
>> I'm seeing a race in fs/fcntl.c. I'm not sure exactly how the race is
>> occurring, but the following is my best guess. A kernel log is
>> attached.
>
> [snip the analysis - it's a different lock anyway]
>
> The traces below are essentially sys_execve() getting to get_random_bytes(),
> to kill_fasync(), to send_sigio(), which spins on tasklist_lock.
>
> Could you rebuild it with lockdep enabled and try to reproduce that?
> I very much doubt that this execve() is a part of deadlock - it's
> getting caught on one, but it shouldn't be holding any locks that
> nest inside tasklist_lock at that point, so even it hadn't been there,
> the process holding tasklist_lock probably wouldn't have progressed any
> further...

ok, I did screw up the analysis quite badly, luckily, lockdep got it right away.


[  199.411236]
[  199.411261] ==
[  199.411268] [ INFO: possible circular locking dependency detected ]
[  199.411277] 3.8.0-9-generic #18 Not tainted
[  199.411283] ---
[  199.411290] slirp-wrapper.s/5574 is trying to acquire lock:
[  199.411296]  (&(>fa_lock)->rlock){-.-...}, at:
[] kill_fasync+0x69/0xe0
[  199.411332]
[  199.411332] but task is already holding lock:
[  199.411338]  (_pool.lock){..}, at:
[] account+0x39/0x1d0
[  199.411364]
[  199.411364] which lock already depends on the new lock.
[  199.411364]
[  199.411371]
[  199.411371] the existing dependency chain (in reverse order) is:
[  199.411379]
[  199.411379] -> #2 (_pool.lock){..}:
[  199.411400][] lock_acquire+0x98/0x120
[  199.411416][] _raw_spin_lock_irqsave+0x4e/0x70
[  199.411430][] mix_pool_bytes.constprop.20+0x43/0xb0
[  199.411442][] add_device_randomness+0x64/0x90
[  199.411454][] posix_cpu_timers_exit+0x1e/0x50
[  199.411469][] release_task+0xe2/0x470
[  199.411484][] do_exit+0x5d7/0x9c0
[  199.411495][] __module_put_and_exit+0x1a/0x20
[  199.411509][] cryptomgr_test+0x25/0x30
[  199.411526][] kthread+0xea/0xf0
[  199.411537][] ret_from_fork+0x7c/0xb0
[  199.411550]
[  199.411550] -> #1 (&(>siglock)->rlock){-.-...}:
[  199.411689][] lock_acquire+0x98/0x120
[  199.411702][] _raw_spin_lock_irqsave+0x4e/0x70
[  199.411713][] vblank_disable_fn+0x60/0xd0 [drm]
[  199.411768][] call_timer_fn+0x7a/0x180
[  199.411781][] run_timer_softirq+0x1fc/0x2a0
[  199.411794][] __do_softirq+0xe0/0x220
[  199.411807][] call_softirq+0x1c/0x30
[  199.411819][] do_softirq+0xa5/0xe0
[  199.411833][] irq_exit+0xb5/0xc0
[  199.411846][] smp_apic_timer_interrupt+0x6e/0x99
[  199.411859][] apic_timer_interrupt+0x72/0x80
[  199.411871][] cpuidle_enter_tk+0x10/0x20
[  199.411885][] cpuidle_idle_call+0xa5/0x270
[  199.411897][] cpu_idle+0xb5/0x120
[  199.411910][] rest_init+0xb4/0xc0
[  199.411924][] start_kernel+0x3ea/0x3f6
[  199.411939][] x86_64_start_reservations+0x130/0x133
[  199.411952][] x86_64_start_kernel+0x100/0x10f
[  199.411966]
[  199.411966] -> #0 (&(>fa_lock)->rlock){-.-...}:
[  199.411984][] __lock_acquire+0x1279/0x1aa0
[  199.411997][] lock_acquire+0x98/0x120
[  199.412103][] _raw_spin_lock_irqsave+0x4e/0x70
[  199.412115][] kill_fasync+0x69/0xe0
[  199.412127][] account+0x113/0x1d0
[  199.412138][] extract_entropy+0x65/0x140
[  199.412149][] get_random_bytes+0x20/0x30
[  199.412159][] create_elf_tables+0xaa/0x615
[  199.412172][] load_elf_binary+0xae4/0xe00
[  199.412185][] search_binary_handler+0x171/0x390
[  199.412197][] load_script+0x265/0x2b0
[  199.412208][] search_binary_handler+0x171/0x390
[  199.412219][] do_execve_common.isra.23+0x405/0x4c0
[  199.412230][] do_execve+0x18/0x20
[  199.412240][] sys_execve+0x3d/0x60
[  199.412251][] stub_execve+0x69/0xc0
[  199.412263]
[  199.412263] other info that might help us debug this:
[  199.412263]
[  199.412271] Chain exists of:
[  199.412271]   &(>fa_lock)->rlock -->
&(>siglock)->rlock --> _pool.lock
[  199.412271]
[  199.412298]  Possible unsafe locking scenario:
[  199.412298]
[  199.412305]CPU0CPU1
[  199.412310]
[  199.412316]   lock(_pool.lock);
[  199.412328]lock(&(>siglock)->rlock);
[  199.412339]lock(_pool.lock);
[  199.412452]   lock(&(>fa_lock)->rlock);
[  199.412464]
[  199.412464]  *** DEADLOCK ***
[  199.412464]
[  199.412473] 2 locks held by slirp-wrapper.s/5574:
[  199.412478]  #0:  (_pool.lock){..}, at:
[] account+0x39/0x1d0
[  199.412504]  #1:  (rcu_read_lock){.+.+..}, at: []

[GIT PULL] Please pull NFS client bugfixes

[Myklebust, Trond]

Hi Linus,

We've just concluded another Connectathon interoperability testing week,
and so here are the fixes for the bugs that were discovered.

Cheers,
  Trond

The following changes since commit 666b3d803a511fbc9bc5e5ea8ce66010cf03ea13:

  NLM: Ensure that we resend all pending blocking locks after a reclaim 
(2013-02-19 12:18:27 -0500)

are available in the git repository at:

  git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-3.9-2

for you to fetch changes up to 512e4b291c0e97af24619a91f3e8963697da00d8:

  SUNRPC: One line comment fix (2013-03-02 15:54:11 -0800)


NFS client bugfixes for Linux 3.9

- Don't allow NFS silly-renamed files to be deleted
- Don't start the retransmission timer when out of socket space
- Fix a couple of pnfs-related Oopses.
- Fix one more NFSv4 state recovery deadlock
- Don't loop forever when LAYOUTGET returns NFS4ERR_LAYOUTTRYLATER


Benny Halevy (1):
  pnfs: fix resend_to_mds for directio

Jeff Layton (1):
  nfs: don't allow nfs_find_actor to match inodes of the wrong type

Trond Myklebust (4):
  NFS: Don't allow NFS silly-renamed files to be deleted, no signal
  SUNRPC: Don't start the retransmission timer when out of socket space
  NFSv4: Fix another open/open_recovery deadlock
  SUNRPC: One line comment fix

Weston Andros Adamson (4):
  NFSv4.1: Hold reference to layout hdr in layoutget
  PNFS: set the default DS timeout to 60 seconds
  SUNRPC: add call to get configured timeout
  NFSv4.1: LAYOUTGET EDELAY loops timeout to the MDS

 fs/nfs/inode.c  |  2 ++
 fs/nfs/nfs4filelayout.c |  6 --
 fs/nfs/nfs4filelayout.h |  2 +-
 fs/nfs/nfs4proc.c   | 21 ++---
 fs/nfs/pnfs.c   | 21 +
 fs/nfs/pnfs.h   |  6 --
 fs/nfs/unlink.c | 20 +---
 include/linux/nfs_xdr.h |  1 +
 include/linux/sunrpc/clnt.h |  1 +
 net/sunrpc/clnt.c   | 15 +++
 net/sunrpc/xprt.c   |  6 +-
 11 files changed, 77 insertions(+), 24 deletions(-)

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
trond.mykleb...@netapp.com
www.netapp.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 4/4] power: tps65090: Add support for tps65090-charger

[Anton Vorontsov]

Hello Rhyland,

Thanks for the driver! A few comments down below...

On Wed, Feb 27, 2013 at 06:07:30PM -0500, Rhyland Klein wrote:
> This patch adds support for the tps65090 charger driver.

Would be nice to get a few more words about the hardware and the driver.
Why it is cool, main features, what is missing (if any), what is planned.

> Based on work by:
> Syed Rafiuddin 
> Laxman Dewangan 
> 
> Signed-off-by: Rhyland Klein 
> ---
>  drivers/power/Kconfig|7 +
>  drivers/power/Makefile   |1 +
>  drivers/power/tps65090-charger.c |  310 
> ++
>  include/linux/mfd/tps65090.h |5 +
>  4 files changed, 323 insertions(+)
>  create mode 100644 drivers/power/tps65090-charger.c
> 
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index 9f45e2f..6dcc3bd 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -340,6 +340,13 @@ config CHARGER_SMB347
> Say Y to include support for Summit Microelectronics SMB347
> Battery Charger.
>  
> +config CHARGER_TPS65090
> + tristate "TPS65090 battery charger driver"
> + depends on MFD_TPS65090
> + help
> +  Say Y here to enable support for battery charging with TPS65090
> +  PMIC chips.
> +
>  config AB8500_BM
>   bool "AB8500 Battery Management Driver"
>   depends on AB8500_CORE && AB8500_GPADC
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index 22c8913..9523f81 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -51,4 +51,5 @@ obj-$(CONFIG_CHARGER_MAX8998)   += max8998_charger.o
>  obj-$(CONFIG_CHARGER_BQ2415X)+= bq2415x_charger.o
>  obj-$(CONFIG_POWER_AVS)  += avs/
>  obj-$(CONFIG_CHARGER_SMB347) += smb347-charger.o
> +obj-$(CONFIG_CHARGER_TPS65090)   += tps65090-charger.o
>  obj-$(CONFIG_POWER_RESET)+= reset/
> diff --git a/drivers/power/tps65090-charger.c 
> b/drivers/power/tps65090-charger.c
> new file mode 100644
> index 000..1234b81
> --- /dev/null
> +++ b/drivers/power/tps65090-charger.c
> @@ -0,0 +1,310 @@
> +/*
> + * Battery charger driver for TI's tps65090
> + *
> + * Copyright (c) 2013, NVIDIA CORPORATION.  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 .
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define TPS65090_REG_INTR_STS0x00
> +#define TPS65090_REG_CG_CTRL00x04
> +#define TPS65090_REG_CG_CTRL10x05
> +#define TPS65090_REG_CG_CTRL20x06
> +#define TPS65090_REG_CG_CTRL30x07
> +#define TPS65090_REG_CG_CTRL40x08
> +#define TPS65090_REG_CG_CTRL50x09
> +#define TPS65090_REG_CG_STATUS1  0x0a
> +#define TPS65090_REG_CG_STATUS2  0x0b
> +
> +#define TPS65090_CHARGER_ENABLE  BIT(0)
> +#define TPS65090_VACGBIT(1)
> +#define TPS65090_NOITERM BIT(5)
> +
> +struct tps65090_charger {
> + struct  device  *dev;
> + int ac_online;
> + int prev_ac_online;
> + struct power_supply ac;
> + struct tps65090_platform_data *pdata;
> +};
> +
> +static enum power_supply_property tps65090_ac_props[] = {
> + POWER_SUPPLY_PROP_ONLINE,
> +};
> +
> +static int tps65090_low_chrg_current(struct tps65090_charger *charger)
> +{
> + int ret;
> +
> + ret = tps65090_write(charger->dev->parent, TPS65090_REG_CG_CTRL5,
> + TPS65090_NOITERM);
> + if (ret < 0) {
> + dev_err(charger->dev, "%s(): error reading in register 0x%x\n",
> + __func__, TPS65090_REG_CG_CTRL5);
> + return ret;
> + }
> + return 0;
> +}
> +
> +static int tps65090_enable_charging(struct tps65090_charger *charger,
> + uint8_t enable)
> +{
> + int ret;
> + uint8_t retval = 0;

maybe 'ctrl0' instead of retval?

> +
> + ret = tps65090_read(charger->dev->parent, TPS65090_REG_CG_CTRL0,
> + );
> + if (ret < 0) {
> + dev_err(charger->dev, "%s(): error reading in register 0x%x\n",
> + __func__, TPS65090_REG_CG_CTRL0);
> + return ret;
> + }
> +
> + ret = tps65090_write(charger->dev->parent, TPS65090_REG_CG_CTRL0,
> + (retval | TPS65090_CHARGER_ENABLE));
> + if (ret < 0) {
> + 

Re: [PATCH] x86: fix 32-bit *_cpu_data initializers

[Borislav Petkov]

On Sun, Mar 03, 2013 at 12:14:42AM +0100, Krzysztof Mazur wrote:
> The commit 27be457000211a6903968dfce06d5f73f051a217
> (x86 idle: remove 32-bit-only "no-hlt" parameter, hlt_works_ok flag)
> removed the hlt_works_ok flag from struct cpuinfo_x86, but
> boot_cpu_data and new_cpu_data initializers were not changed causing
> setting f00f_bug flag, instead of fdiv_bug. If CONFIG_X86_F00F_BUG
> is not set the f00f_bug flag is never cleared.
> 
> To avoid such problems in future C99-style initialization is now used.
> 
> Signed-off-by: Krzysztof Mazur 

Good catch.

Acked-by: Borislav Petkov 

> ---
> $ cat < /proc/cpuinfo
> processor : 0
> vendor_id : GenuineIntel
> cpu family: 6
> model : 13
> model name: Intel(R) Pentium(R) M processor 1.73GHz
> stepping  : 8
> microcode : 0x20
> cpu MHz   : 800.000
> cache size: 2048 KB
> fdiv_bug  : no
> f00f_bug  : yes
> ...
>
> By the way now in struct cpuinfo_x86 for 32-bit systems pad0
> should be extended to 2 bytes or removed, because now 32-bit
> specific bugs area have now 6 bytes + pad0.

It's good that you bring this up - I have a patchset which removes all
those *_bug fields in cpuinfo_x86 which means the padding goes away too.

-- 
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 V2] MAINTAINERS: Update SIMTEC file patterns, remove Vincent Sanders

[Cesar Eduardo Barros]

Em 01-03-2013 17:37, Joe Perches escreveu:

On Fri, 2013-03-01 at 21:20 +0100, Paul Bolle wrote:

On Fri, 2013-03-01 at 12:02 -0800, Joe Perches wrote:

commit 85fd6d6 ("ARM: S3C2410: move mach-s3c2410/* into mach-s3c24xx/")
moved the files, update the F: patterns.


The BAST MAINTAINER entry has come up a few times already. I commented
on the last time that happened in https://lkml.org/lkml/2012/11/24/96 .
Nothing has changed. I suggest to remove this entry entirely.


Seems sensible to me.  Ben?

I'm a bit surprised that all of Cesar Eduardo Barros' patches
to MAINTAINERS weren't applied.  I thought they were.  It
seems that only some of them are in.

https://lkml.org/lkml/2012/11/23/439

Cesar?  Can you please resend whatever scraps weren't applied
and make sure you cc Andrew Morton?


I just checked on my local tree, and it is only the BAST one. For some 
reason, Andrew Morton did not add that one to his tree (probably because 
there was discussion about removing the whole block instead of fixing 
it, so he prefered to take the uncontroversial ones only).


The ones which were not in Andrew's tree all went in via other trees.

It might be best for me to make a new series instead. My 
checkmaintainers.py already gives me 15 lines of output, and that is on 
top of what I have pending (BAST and part 2 of the uapi mess) rebased 
over the Linus tree. On the Linus tree, it gives me 42 lines of output.


--
Cesar Eduardo Barros
ces...@cesarb.net
cesar.bar...@gmail.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 00/40] Power: AB8500: Internal development push

[Anton Vorontsov]

Hello Lee,

On Fri, Feb 15, 2013 at 12:44:30PM +, Lee Jones wrote:
> This is the 3rd and final instalment of the push to synchronise
> the ABx500 Battery Management series of internal development patches
> due for Mainline.
> 
> This patch-set submission is for reviewing purposes only. Please
> don't apply patches directly from this patch-set, as there are some
> interdependencies with another patch-set due for the MFD tree. We
> can chat about how to over-come this at a later date.

It looks so much better than the initial series! Frankly, I couldn't find
anything utterly wrong with it. :-)  (I did notice a couple of cosmetic
issues, but considering the amount of work and patches needed rebasing, it
would be insane of me to ask fixing these. :-)

So, I can easily merge it, as long as MFD part is either Acked or handled
somehow else. But I do want to merge the drivers/power/ part via battery
tree -- the part is quite large and thus prone to conflicts if someone
asks me to merge a patch that would touch the same lines.

Thanks so much!

Anton
--
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 06/10] usb: xhci: Enable runtime pm in xhci-plat

[Felipe Balbi]

Hi,

On Sun, Mar 03, 2013 at 01:21:32AM +0200, Felipe Balbi wrote:
> > I don't know much about clock handling.  In general, the
> > pm_runtime_set_active() and pm_runtime_enable() parts should be done by
> > the subsystem, not the driver, whenever possible.
> 
> good to know :-) Though I disagree with calling pm_runtime_enable() at
> the subsystem level.
> 
> This means we can add pm_runtime_set_active() 

ignore this last line, forgot to delete it.

-- 
balbi


signature.asc
Description: Digital signature

[PATCH] x86: fix 32-bit *_cpu_data initializers

[Krzysztof Mazur]

The commit 27be457000211a6903968dfce06d5f73f051a217
(x86 idle: remove 32-bit-only "no-hlt" parameter, hlt_works_ok flag)
removed the hlt_works_ok flag from struct cpuinfo_x86, but
boot_cpu_data and new_cpu_data initializers were not changed causing
setting f00f_bug flag, instead of fdiv_bug. If CONFIG_X86_F00F_BUG
is not set the f00f_bug flag is never cleared.

To avoid such problems in future C99-style initialization is now used.

Signed-off-by: Krzysztof Mazur 
---
$ cat < /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 13
model name  : Intel(R) Pentium(R) M processor 1.73GHz
stepping: 8
microcode   : 0x20
cpu MHz : 800.000
cache size  : 2048 KB
fdiv_bug: no
f00f_bug: yes
...

By the way now in struct cpuinfo_x86 for 32-bit systems pad0
should be extended to 2 bytes or removed, because now 32-bit
specific bugs area have now 6 bytes + pad0.

 arch/x86/kernel/setup.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 84d3285..90d8cc9 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -171,9 +171,15 @@ static struct resource bss_resource = {
 
 #ifdef CONFIG_X86_32
 /* cpu data as detected by the assembly code in head.S */
-struct cpuinfo_x86 new_cpu_data __cpuinitdata = {0, 0, 0, 0, -1, 1, 0, 0, -1};
+struct cpuinfo_x86 new_cpu_data __cpuinitdata = {
+   .wp_works_ok = -1,
+   .fdiv_bug = -1,
+};
 /* common cpu data for all cpus */
-struct cpuinfo_x86 boot_cpu_data __read_mostly = {0, 0, 0, 0, -1, 1, 0, 0, -1};
+struct cpuinfo_x86 boot_cpu_data __read_mostly = {
+   .wp_works_ok = -1,
+   .fdiv_bug = -1,
+};
 EXPORT_SYMBOL(boot_cpu_data);
 
 unsigned int def_to_bigsmp;
-- 
1.8.2.rc1.362.gc8d5142

--
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 06/10] usb: xhci: Enable runtime pm in xhci-plat

[Felipe Balbi]

Hi,

On Sat, Mar 02, 2013 at 05:02:13PM -0500, Alan Stern wrote:
> On Sat, 2 Mar 2013, Felipe Balbi wrote:
> 
> > > > @@ -174,6 +177,10 @@ static int xhci_plat_remove(struct platform_device 
> > > > *dev)
> > > > struct usb_hcd  *hcd = platform_get_drvdata(dev);
> > > > struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> > > >  
> > > > +   if (!pm_runtime_suspended(>dev))
> > > > +   pm_runtime_put(>dev);
> > > > +   pm_runtime_disable(>dev);
> > > > +
> > > > usb_remove_hcd(xhci->shared_hcd);
> > > > usb_put_hcd(xhci->shared_hcd);
> > > 
> > > This is very strange.  Why have a pm_runtime_put with no balancing 
> > > pm_runtime_get?
> > 
> > this is good point and, in fact, a doubt I have myself. How are we
> > supposed to check if device is suspended ? In case it _is_ suspended we
> > might not be able to read device's registers due to clocks possibly
> > being gated.
> 
> That's really a separate question.  It has a simple answer, though: If 
> you want to access a device's registers, call pm_runtime_get_sync() 
> beforehand and pm_runtime_put() (or _put_sync()) afterward.  Then it 
> won't matter if the device was suspended originally.

that's alright, but how do you want me to check if my device is enabled
or not before pm_runtime_enable() ?

> If you actually do want to tell whether or not a device is suspended
> and nothing more, call pm_runtime_status_suspended().  Of course, this
> is racy -- the power state might change right after you make the call.

right.

> > Also, considering that some drivers are used in multiple platforms and
> > those might behave differently when it comes to clock handling, how do
> > we do that ? Should we require drivers to explicitly clk_get();
> > clk_prepare_enable(); pm_runtime_set_active(); pm_runtime_enable() ?
> 
> I don't know much about clock handling.  In general, the
> pm_runtime_set_active() and pm_runtime_enable() parts should be done by
> the subsystem, not the driver, whenever possible.

good to know :-) Though I disagree with calling pm_runtime_enable() at
the subsystem level.

This means we can add pm_runtime_set_active() 

> > While that's doable, I don't see how that'd be doable for OMAP since
> > they want to hide clock handling from drivers.
> > 
> > Any tips ?
> 
> Whichever piece of code is responsible for associating a clock with a
> device should also be responsible for making sure that neither is
> suspended when the driver's probe routine runs.  I'm not sure how 
> different platforms do this; using a PM domain could be one answer.

that's alright, but it generates a different set of problems. That same
piece of code which associates a device with its clock, doesn't really
know if the driver is even available which means we could be enabling
clocks for no reason and just wasting precious battery juice ;-)

> All this is somewhat off the point of my original comment, however.  
> Drivers must be sure to balance their pm_runtime_get() and _put()  
> calls.  Having an unbalanced _put() in the remove routine is almost
> certainly a mistake -- especially if it is conditional on the device's
> power state, because a device can remain unsuspended even after the
> driver does a pm_runtime_put().  For example, this will happen if the
> user wrote "on"  to /sys/.../power/control.

indeed... Makes sense. I'll consider mailing linux-pm for the rest of
the discussion, cheers.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/2] mfd: twl4030-madc: Add support for raw value in twl4030_madc_conversion

[Anton Vorontsov]

On Fri, Feb 15, 2013 at 11:56:49PM +0100, Pali Rohár wrote:
> Driver twl4030-madc has hardcoded channel types (10 - battery current,
> 1 - battery temperature) and also conversation data in variable
> twl4030_divider_ratios. These hardcoded channels are incorrect for
> Nokia RX-51 board (where is channel 0 - battery temperature).
> 
> For Nokia RX-51 there is rx51_battery power_supply driver which reporting
> battery information via twl4030_madc_conversion. But this driver needs
> raw values (not converted via some hardcoded functions). So this patch
> adding new parameter "raw" to struct twl4030_madc_request which tell
> twl4030-madc driver to not convert values, but rather return raw.
> 
> Signed-off-by: Pali Rohár 

It looks good to me; glancing around, I don't see any better way to do it.
So,

Reviewed-by: Anton Vorontsov 

Thanks!

Anton
--
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 URGENT] ext4 regression fix for 3.9

[Theodore Ts'o]

On Sat, Mar 02, 2013 at 11:54:37AM -0800, Linus Torvalds wrote:
> 
> This needs to be fixed or reverted. I traced back some user
> interaction problems to this same issue. It literally gets so bad that
> the whole system is choppy, and a profile shows that a lot of time is
> being spent in the spin-lock protecting these data structures. Called
> from ext4_es_reclaim_extents_count, ext4_es_lru_add and
> ext4_es_shrink.

I'm doing final testing on a pull request that will fix these
problems.  I'll send it to you later this evening.

 - Ted
--
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: [ 34/77] xen/blkback: Dont trust the handle from the frontend.

[Ben Hutchings]

On Sat, 2013-03-02 at 23:35 +0100, Paul Bolle wrote:
[...]
> 0) I've had another look at the relevant code in v3.8.2-rc1. It can be
> summarized like this:
> 
> static int xen_vbd_translate()
> {
>   [...]
>   int rc = -EACCES;
> 
>   if ([...])
>   goto out;
>   [...]
> 
>   [p]req->dev  = vbd->pdevice;
>   [p]req->bdev = vbd->bdev;
>   [...]
> 
>  out:
>   return rc;
> }
> 
> static int dispatch_rw_block_io()
> {
>   struct phys_req preq;
>   [...]
> 
>   preq.sector_number = req->u.rw.sector_number;
>   preq.nr_sects  = 0;
>   [...]
> 
>   for ([...]) {
>   [...]
>   preq.nr_sects += seg[i].nsec;
>   }
> 
>   if (xen_vbd_translate(, blkif, operation) != 0) {
>   pr_debug(DRV_PFX "access denied: %s of [%llu,%llu] on 
> dev=%04x\n",
>operation == READ ? "read" : "write",
>preq.sector_number,
>preq.sector_number + preq.nr_sects, preq.dev);
>   goto [...];
>   }
>   [...]
> }
> 
> 1) So if xen_vbd_translate() fails, it can return before setting
> preq.dev. That makes the call of pr_debug() use an uninitialized value,
> doesn't it?

Oh yes, so it's a completely valid warning in this case!

> Does inlining xen_vbd_translate() and/or
> dispatch_rw_block_io() generate code were that can't happen anymore?
> (Both functions being static they probably are inlined.)
> 
> 2) And even if inlining does generate code where this can't happen,
> isn't it enough that preq.dev can be used uninitialized if no code were
> inlined?

If gcc inlines a function call, it analyses data flow between the two
functions.  Otherwise it assumes that the called function will
initialise any variable it's given a pointer to, and the warning doesn't
appear.  (That's my experience, anyway.)

Ben.

-- 
Ben Hutchings
Computers are not intelligent.  They only think they are.


signature.asc
Description: This is a digitally signed message part

Re: [PATCH 3.2] iommu/amd: Initialize device table after dma_ops

[Ben Hutchings]

On Thu, 2013-02-28 at 14:39 -0700, Shuah Khan wrote:
> When dma_ops are initialized the unity mappings are created. The
> init_device_table_dma() function makes sure DMA from all devices is
> blocked by default. This opens a short window in time where DMA to
> unity mapped regions is blocked by the IOMMU. Make sure this does not
> happen by initializing the device table after dma_ops.
> 
> Back-port upstream commit: f528d980c17b8714aedc918ba86e058af914d66b
> Tested on 3.2.38
> 
> Signed-off-by: Joerg Roedel 
> Signed-off-by: Shuah Khan 
> CC: sta...@vger.kernel.org 3.2

I'm not convinced about this backport, because the order of
initialisation already changed a lot after 3.2 and before the upstream
commit.  So I'm going to wait for Joerg to confirm that this makes sense
before adding it to the patch queue.

Ben.

> ---
>  drivers/iommu/amd_iommu_init.c |   10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
> index 62a4d5c..b7d1cdd 100644
> --- a/drivers/iommu/amd_iommu_init.c
> +++ b/drivers/iommu/amd_iommu_init.c
> @@ -1396,6 +1396,7 @@ static struct syscore_ops amd_iommu_syscore_ops = {
>   */
>  static int __init amd_iommu_init(void)
>  {
> + struct amd_iommu *iommu;
>   int i, ret = 0;
>  
>   /*
> @@ -1444,9 +1445,6 @@ static int __init amd_iommu_init(void)
>   if (amd_iommu_pd_alloc_bitmap == NULL)
>   goto free;
>  
> - /* init the device table */
> - init_device_table();
> -
>   /*
>* let all alias entries point to itself
>*/
> @@ -1496,6 +1494,12 @@ static int __init amd_iommu_init(void)
>   if (ret)
>   goto free_disable;
>  
> + /* init the device table */
> + init_device_table();
> +
> + for_each_iommu(iommu)
> + iommu_flush_all_caches(iommu);
> +
>   amd_iommu_init_api();
>  
>   amd_iommu_init_notifier();

-- 
Ben Hutchings
Computers are not intelligent.  They only think they are.


signature.asc
Description: This is a digitally signed message part

Re: [RFC v2 2/3] power: power_supply: Add core support for supplied_nodes

[Anton Vorontsov]

On Thu, Feb 28, 2013 at 02:48:03PM -0500, Rhyland Klein wrote:
[...]
> Anton, David, would you be adverse to the changing of supplied_to
> from being a
> list of batteries stored in a charger to being a list of chargers
> stored in batteries?

I wonder if we can support both ways?..

Thanks,
Anton
--
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 05/11] staging: refactoring request/free voice channels

[Ryan Mallon]

On 01/03/13 21:57, Michail Kurachkin wrote:

> From: Michail Kurochkin 
> 
> Signed-off-by: Michail Kurochkin 
> ---
>  drivers/staging/tdm/kirkwood_tdm.c |  162 
> +---
>  drivers/staging/tdm/kirkwood_tdm.h |   10 ++-
>  drivers/staging/tdm/tdm.h  |5 +-
>  drivers/staging/tdm/tdm_core.c |   65 +++
>  4 files changed, 154 insertions(+), 88 deletions(-)
> 
> diff --git a/drivers/staging/tdm/kirkwood_tdm.c 
> b/drivers/staging/tdm/kirkwood_tdm.c
> index 4366d38..e4a9106 100644
> --- a/drivers/staging/tdm/kirkwood_tdm.c
> +++ b/drivers/staging/tdm/kirkwood_tdm.c
> @@ -75,7 +75,7 @@ static int kirkwood_tdm_hw_init(struct tdm_controller *tdm)
>   u32 control_val = 0;
>   u32 pclk_freq;
>   unsigned long flags;
> - spinlock_t lock;
> + static spinlock_t lock;
>   spin_lock_init();


Global spinlocks should be declared outside of functions using the
spinlock initialisers, eg:

static DEFINE_SPINLOCK(lock_name);

Having a global spinlock just called 'lock' is not very informative.
I also can't see any new uses of this lock in this patch, so why
is it being made global, and what use was it in the first place?

>  
>  
> @@ -192,13 +192,14 @@ static void kirkwood_tdm_hw_deinit(struct 
> tdm_controller *tdm)
>  }
>  
>  /**
> - * Setup hardware voice channel
> + * Initialization hardware voice channel
> + * for specify TDM device
> + * @param tdm_dev - specify TDM device
>   * @param ch - voice hardware channel
>   * @return 0 - OK
>   */
> -int kirkwood_setup_voice_channel(struct tdm_voice_channel* ch)
> +static int kirkwood_init_voice_channel(struct tdm_device *tdm_dev, struct 
> tdm_voice_channel* ch)
>  {
> - struct tdm_device *tdm_dev = to_tdm_device(ch->dev);
>   struct tdm_controller *tdm = tdm_dev->controller;
>   struct tdm_controller_hw_settings *hw = tdm->settings;
>   struct kirkwood_tdm *onchip_tdm =
> @@ -208,15 +209,15 @@ int kirkwood_setup_voice_channel(struct 
> tdm_voice_channel* ch)
>   unsigned long timeout;
>   u32 state;
>   int i;
> -
> + int rc = 0;
>   u8 voice_num = ch->channel_num;
>  
>   /* calculate buffer size */
>   ch->buffer_len = tdm_dev->buffer_sample_count * hw->channel_size;
>  
>   /* Request timeslot for voice channel */
> - writeb(ch->tdm_channel, (u8*)>chan_time_slot_ctrl + 2 * 
> voice_num);
> - writeb(ch->tdm_channel, (u8*)>chan_time_slot_ctrl + 1 + 2 * 
> voice_num);
> + writeb(tdm_dev->tdm_channel_num, (u8*)>chan_time_slot_ctrl + 2 * 
> voice_num);
> + writeb(tdm_dev->tdm_channel_num, (u8*)>chan_time_slot_ctrl + 1 + 
> 2 * voice_num);
>  
>   /* FIXME: move coherent_dma_mask to board specific */
>   tdm_dev->dev.coherent_dma_mask = 0x;
> @@ -226,11 +227,12 @@ int kirkwood_setup_voice_channel(struct 
> tdm_voice_channel* ch)
>   /* allocate memory for DMA receiver */
>   onchip_ch->rx_buf[i] =
>   dma_alloc_coherent(_dev->dev,
> - ch->buffer_len, onchip_ch->rx_buff_phy + i, GFP_DMA);
> + ch->buffer_len, onchip_ch->rx_buff_phy + i, GFP_KERNEL);


Why are refactors like this happening as a separate patch? Why not
just fold these changes into the first patch so that it is correct
from the beginning (and easier to review)?

>  
>   if (onchip_ch->rx_buf == NULL) {
>   dev_err(ch->dev, "Can't allocate memory for TDM 
> receiver DMA buffer\n");
> - return -ENOMEM;
> + rc = -ENOMEM;
> + goto out1;
>   }
>   memset(onchip_ch->rx_buf[i], 0, ch->buffer_len);
>  
> @@ -238,20 +240,16 @@ int kirkwood_setup_voice_channel(struct 
> tdm_voice_channel* ch)
>   /* allocate memory for DMA transmitter */
>   onchip_ch->tx_buf[i] =
>   dma_alloc_coherent(_dev->dev,
> - ch->buffer_len, onchip_ch->tx_buff_phy + i, GFP_DMA);
> + ch->buffer_len, onchip_ch->tx_buff_phy + i, GFP_KERNEL);
>  
>   if (onchip_ch->tx_buf == NULL) {
>   dev_err(ch->dev, "Can't allocate memory for TDM 
> transmitter DMA buffer\n");
> - return -ENOMEM;
> + rc = -ENOMEM;
> + goto out1;
>   }
>   memset(onchip_ch->tx_buf[i], 0, ch->buffer_len);
>   }
>  
> - atomic_set(_ch->write_rx_buf_num, 0);
> - atomic_set(_ch->write_tx_buf_num, 0);
> - atomic_set(_ch->read_rx_buf_num, 0);
> - atomic_set(_ch->read_tx_buf_num, 0);
> -
>   /* Set length for DMA */
>   writel(((tdm_dev->buffer_sample_count - 32) << 8) | 
> tdm_dev->buffer_sample_count,
>  >chan0_total_sample + voice_num);
> @@ -262,8 +260,10 @@ int kirkwood_setup_voice_channel(struct 
> tdm_voice_channel* ch)
>   state = readl(>chan0_buff_ownership + 4 * 

Re: [ 34/77] xen/blkback: Dont trust the handle from the frontend.

[Paul Bolle]

On Sat, 2013-03-02 at 19:48 +, Ben Hutchings wrote:
> When gcc compiles something like this:
> 
> static int foo(int *p)
> {
>   if (rand() & 1)
>   return -1;
>   *p = 0;
>   return 0;
> }
> 
> int bar(void)
> {
>   int i;
>   if (foo() < 0)
>   return 1;
>   return i;
> }
> 
> and inlines foo() into bar(), sometimes it fails to recognise that i
> will definitely be initialised before use.  This simple example seems to
> be OK but more complex functions such as these will often trigger this
> warning.  The warning is really quite useless now.

0) I've had another look at the relevant code in v3.8.2-rc1. It can be
summarized like this:

static int xen_vbd_translate()
{
[...]
int rc = -EACCES;

if ([...])
goto out;
[...]

[p]req->dev  = vbd->pdevice;
[p]req->bdev = vbd->bdev;
[...]

 out:
return rc;
}

static int dispatch_rw_block_io()
{
struct phys_req preq;
[...]

preq.sector_number = req->u.rw.sector_number;
preq.nr_sects  = 0;
[...]

for ([...]) {
[...]
preq.nr_sects += seg[i].nsec;
}

if (xen_vbd_translate(, blkif, operation) != 0) {
pr_debug(DRV_PFX "access denied: %s of [%llu,%llu] on 
dev=%04x\n",
 operation == READ ? "read" : "write",
 preq.sector_number,
 preq.sector_number + preq.nr_sects, preq.dev);
goto [...];
}
[...]
}

1) So if xen_vbd_translate() fails, it can return before setting
preq.dev. That makes the call of pr_debug() use an uninitialized value,
doesn't it? Does inlining xen_vbd_translate() and/or
dispatch_rw_block_io() generate code were that can't happen anymore?
(Both functions being static they probably are inlined.)

2) And even if inlining does generate code where this can't happen,
isn't it enough that preq.dev can be used uninitialized if no code were
inlined?


Paul Bolle

--
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: Put git commit 51ac8893a7a51b196501164e645583bf78138699 on the stable tree please

[Ben Hutchings]

On Mon, 2013-02-25 at 11:46 -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 22, 2013 at 09:07:42AM -0800, Greg KH wrote:
> > On Fri, Feb 22, 2013 at 11:57:04AM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Feb 22, 2013 at 08:19:30AM -0800, Greg KH wrote:
> > > > On Fri, Feb 22, 2013 at 10:46:45AM -0500, Konrad Rzeszutek Wilk wrote:
> > > > > Hey Greg,
> > > > > 
> > > > > Please put git commit 51ac8893a7a51b196501164e645583bf78138699
> > > > > commit 51ac8893a7a51b196501164e645583bf78138699
> > > > > Author: Jan Beulich 
> > > > > Date:   Wed Feb 6 10:30:38 2013 -0500
> > > > > 
> > > > > xen-pciback: rate limit error messages from 
> > > > > xen_pcibk_enable_msi{,x}()
> > > > > 
> > > > > on the stable tree please. It is an security errata fix and should
> > > > > have had the CC: sta...@vger.kernel.org but did not.
> > > > 
> > > > Thanks, what stable kernel releases should it be queued up for?
> > > 
> > > 3.4 and later please.
> > 
> > On Fri, Feb 22, 2013 at 04:45:55PM +, Jan Beulich wrote:
> > > Anyone from 3.1 onwards that is still being maintained.
> > 
> > Hm, who should I believe here...  :)
> 
> Just in case my previous email crossed paths or got deleted.
> > 
> > It doesn't matter for me, but for the 3.2 tree, it does.
> 
> 3.1 and later please.

Queued up for 3.2.

I had to add '#include ' in
drivers/xen/xen-pciback/xen-pciback.c, as printk_ratelimited() uses
DEFINE_RATELIMIT_STATE() which is defined in .  (In
mainline this is inclued in , but really it ought to be
included in  as well.)

Ben.

-- 
Ben Hutchings
Computers are not intelligent.  They only think they are.


signature.asc
Description: This is a digitally signed message part

Re: [PATCH 1/2] mfd: twl4030-madc: Add support for raw value in twl4030_madc_conversion

[Pali Rohár]

On Friday 15 February 2013 23:56:49 Pali Rohár wrote:
> Driver twl4030-madc has hardcoded channel types (10 - battery
> current, 1 - battery temperature) and also conversation data
> in variable twl4030_divider_ratios. These hardcoded channels
> are incorrect for Nokia RX-51 board (where is channel 0 -
> battery temperature).
> 
> For Nokia RX-51 there is rx51_battery power_supply driver
> which reporting battery information via
> twl4030_madc_conversion. But this driver needs raw values
> (not converted via some hardcoded functions). So this patch
> adding new parameter "raw" to struct twl4030_madc_request
> which tell twl4030-madc driver to not convert values, but
> rather return raw.
> 
> Signed-off-by: Pali Rohár 
> ---
>  drivers/mfd/twl4030-madc.c   |   14 ++
>  include/linux/i2c/twl4030-madc.h |2 ++
>  2 files changed, 12 insertions(+), 4 deletions(-)
> 

Hello, can somebody review this twl4030-madc patch?

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

[PATCH 0/2] ACPI / LPSS: Clocks handling rework and LTR support

[Rafael J. Wysocki]

Hi,

The following two patches rework the initialization of Intel Lynxpoint LPSS
device clocks and add support for reading LTR (Latency Tolerance Reporting)
registers of those devices.

[1/2] Add special ACPI scan handler for Intel Lynxpoint LPSS devices.
[2/2] Add support for exposing the LTR registers of LPSS devices to user space.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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] ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some
common features that aren't shared with any other platform devices,
including the clock and LTR (Latency Tolerance Reporting) registers.
It is better to handle those features in common code than to bother
device drivers with doing that (I/O functionality-wise the LPSS
devices are generally compatible with other devices that don't
have those special registers and may be handled by the same drivers).

The clock registers of the LPSS devices are now taken care of by
the special clk-x86-lpss driver, but the MMIO mappings used for
accessing those registers can also be used for accessing the LTR
registers on those devices (LTR support for the Lynxpoint LPSS is
going to be added by a subsequent patch).  Thus it is convenient
to add a special ACPI scan handler for the Lynxpoint LPSS devices
that will create the MMIO mappings for accessing the clock (and
LTR in the future) registers and will register the LPSS devices'
clocks, so the clk-x86-lpss driver will only need to take care of
the main Lynxpoint LPSS clock.

Introduce a special ACPI scan handler for Intel Lynxpoint LPSS
devices as described above.  This also reduces overhead related to
browsing the ACPI namespace in search of the LPSS devices before the
registration of their clocks, removes some LPSS-specific (and
somewhat ugly) code from acpi_platform.c and shrinks the overall code
size slightly.

Signed-off-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki 
---
 drivers/acpi/Makefile  |1 
 drivers/acpi/acpi_lpss.c   |  163 +
 drivers/acpi/acpi_platform.c   |   40 
 drivers/acpi/internal.h|8 +
 drivers/acpi/scan.c|1 
 drivers/clk/x86/Makefile   |2 
 drivers/clk/x86/clk-lpss.c |   99 
 drivers/clk/x86/clk-lpss.h |   36 ---
 drivers/clk/x86/clk-lpt.c  |   40 
 include/linux/platform_data/clk-lpss.h |   18 +++
 10 files changed, 195 insertions(+), 213 deletions(-)
 create mode 100644 drivers/acpi/acpi_lpss.c
 delete mode 100644 drivers/clk/x86/clk-lpss.c
 delete mode 100644 drivers/clk/x86/clk-lpss.h
 create mode 100644 include/linux/platform_data/clk-lpss.h

Index: linux-pm/drivers/acpi/Makefile
===
--- linux-pm.orig/drivers/acpi/Makefile
+++ linux-pm/drivers/acpi/Makefile
@@ -39,6 +39,7 @@ acpi-y+= ec.o
 acpi-$(CONFIG_ACPI_DOCK)   += dock.o
 acpi-y += pci_root.o pci_link.o pci_irq.o
 acpi-y += csrt.o
+acpi-$(CONFIG_X86_INTEL_LPSS)  += acpi_lpss.o
 acpi-y += acpi_platform.o
 acpi-y += power.o
 acpi-y += event.o
Index: linux-pm/drivers/acpi/acpi_lpss.c
===
--- /dev/null
+++ linux-pm/drivers/acpi/acpi_lpss.c
@@ -0,0 +1,163 @@
+/*
+ * ACPI support for Intel Lynxpoint LPSS.
+ *
+ * Copyright (C) 2013, Intel Corporation
+ * Authors: Mika Westerberg 
+ *  Rafael J. Wysocki 
+ *
+ * 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 
+#include 
+#include 
+
+#include "internal.h"
+
+ACPI_MODULE_NAME("acpi_lpss");
+
+#define LPSS_CLK_OFFSET 0x800
+#define LPSS_CLK_SIZE  0x04
+
+struct lpss_device_desc {
+   bool clk_required;
+   const char *clk_parent;
+};
+
+struct lpss_private_data {
+   void __iomem *mmio_base;
+   resource_size_t mmio_size;
+   struct clk *clk;
+   const struct lpss_device_desc *dev_desc;
+};
+
+static struct lpss_device_desc lpt_dev_desc = {
+   .clk_required = true,
+   .clk_parent = "lpss_clk",
+};
+
+static const struct acpi_device_id acpi_lpss_device_ids[] = {
+   /* Lynxpoint LPSS devices */
+   { "INT33C0", (unsigned long)_dev_desc },
+   { "INT33C1", (unsigned long)_dev_desc },
+   { "INT33C2", (unsigned long)_dev_desc },
+   { "INT33C3", (unsigned long)_dev_desc },
+   { "INT33C4", (unsigned long)_dev_desc },
+   { "INT33C5", (unsigned long)_dev_desc },
+   { "INT33C6", },
+   { "INT33C7", },
+
+   { }
+};
+
+static int is_memory(struct acpi_resource *res, void *not_used)
+{
+   struct resource r;
+   return !acpi_dev_resource_memory(res, );
+}
+
+/* LPSS main clock device. */
+static struct platform_device *lpss_clk_dev;
+
+static inline void lpt_register_clock_device(void)
+{
+   lpss_clk_dev = platform_device_register_simple("clk-lpt", -1, NULL, 0);
+}
+
+static int register_device_clock(struct acpi_device *adev,
+struct 

[PATCH 2/2] ACPI / LPSS: Add support for exposing LTR registers to user space

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have
registers providing access to LTR (Latency Tolerance Reporting)
functionality that allows software to monitor and possibly influence
the aggressiveness of the platform's active-state power management.

For each LPSS device, there are two modes of operation related to LTR,
the auto mode and the software mode.  In the auto mode the LTR is
set up by the platform firmware and managed by hardware.  Software
can only read the LTR register values to monitor the platform's
behavior.  In the software mode it is possible to use LTR to control
the extent to which the platform will use its built-in power
management features.

This changeset adds support for reading the LPSS devices' LTR
registers and exposing their values to user space for monitoring and
diagnostics purposes.  It re-uses the MMIO mappings created to access
the LPSS devices' clock registers for reading the values of the LTR
registers and exposes them to user space through sysfs device
attributes.  Namely, a new atrribute group, lpss_ltr, is created for
each LPSS device.  It contains three new attributes: ltr_mode,
auto_ltr, sw_ltr.  The value of the ltr_mode attribute reflects the
LTR mode being used at the moment (software vs auto) and the other
two contain the actual register values (raw) whose meaning depends
on the LTR mode.  All of these attributes are read-only.

Signed-off-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki 
---
 Documentation/ABI/testing/sysfs-devices-lpss_ltr |   44 +++
 drivers/acpi/acpi_lpss.c |  139 ++-
 2 files changed, 178 insertions(+), 5 deletions(-)

Index: linux-pm/Documentation/ABI/testing/sysfs-devices-lpss_ltr
===
--- /dev/null
+++ linux-pm/Documentation/ABI/testing/sysfs-devices-lpss_ltr
@@ -0,0 +1,44 @@
+What:  /sys/devices/.../lpss_ltr/
+Date:  March 2013
+Contact:   Rafael J. Wysocki 
+Description:
+   The /sys/devices/.../lpss_ltr/ directory is only present for
+   devices included into the Intel Lynxpoint Low Power Subsystem
+   (LPSS).  If present, it contains attributes containing the LTR
+   mode and the values of LTR registers of the device.
+
+What:  /sys/devices/.../lpss_ltr/ltr_mode
+Date:  March 2013
+Contact:   Rafael J. Wysocki 
+Description:
+   The /sys/devices/.../lpss_ltr/ltr_mode attribute contains an
+   integer number (0 or 1) indicating whether or not the devices'
+   LTR functionality is working in the software mode (1).
+
+   This attribute is read-only.  If the device is in a low-power
+   state, attempts to read from this attribute cause -EAGAIN to
+   be returned.
+
+What:  /sys/devices/.../lpss_ltr/auto_ltr
+Date:  March 2013
+Contact:   Rafael J. Wysocki 
+Description:
+   The /sys/devices/.../lpss_ltr/auto_ltr attribute contains the
+   current value of the device's AUTO_LTR register (raw)
+   represented as an 8-digit hexadecimal number.
+
+   This attribute is read-only.  If the device is in a low-power
+   state, attempts to read from this attribute cause -EAGAIN to
+   be returned.
+
+What:  /sys/devices/.../lpss_ltr/sw_ltr
+Date:  March 2013
+Contact:   Rafael J. Wysocki 
+Description:
+   The /sys/devices/.../lpss_ltr/auto_ltr attribute contains the
+   current value of the device's SW_LTR register (raw) represented
+   as an 8-digit hexadecimal number.
+
+   This attribute is read-only.  If the device is in a low-power
+   state, attempts to read from this attribute cause -EAGAIN to
+   be returned.
Index: linux-pm/drivers/acpi/acpi_lpss.c
===
--- linux-pm.orig/drivers/acpi/acpi_lpss.c
+++ linux-pm/drivers/acpi/acpi_lpss.c
@@ -18,17 +18,26 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "internal.h"
 
 ACPI_MODULE_NAME("acpi_lpss");
 
-#define LPSS_CLK_OFFSET 0x800
 #define LPSS_CLK_SIZE  0x04
+#define LPSS_LTR_SIZE  0x18
+
+/* Offsets relative to LPSS_PRIVATE_OFFSET */
+#define LPSS_GENERAL   0x08
+#define LPSS_GENERAL_LTR_MODE_SW   BIT(2)
+#define LPSS_SW_LTR0x10
+#define LPSS_AUTO_LTR  0x14
 
 struct lpss_device_desc {
bool clk_required;
const char *clk_parent;
+   bool ltr_required;
+   unsigned int prv_offset;
 };
 
 struct lpss_private_data {
@@ -41,6 +50,13 @@ struct lpss_private_data {
 static struct lpss_device_desc lpt_dev_desc = {
.clk_required = true,
.clk_parent = "lpss_clk",
+   .prv_offset = 0x800,
+   .ltr_required = true,
+};
+
+static struct 

Re: [PATCH v2 06/10] usb: xhci: Enable runtime pm in xhci-plat

[Alan Stern]

On Sat, 2 Mar 2013, Felipe Balbi wrote:

> > > @@ -174,6 +177,10 @@ static int xhci_plat_remove(struct platform_device 
> > > *dev)
> > >   struct usb_hcd  *hcd = platform_get_drvdata(dev);
> > >   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> > >  
> > > + if (!pm_runtime_suspended(>dev))
> > > + pm_runtime_put(>dev);
> > > + pm_runtime_disable(>dev);
> > > +
> > >   usb_remove_hcd(xhci->shared_hcd);
> > >   usb_put_hcd(xhci->shared_hcd);
> > 
> > This is very strange.  Why have a pm_runtime_put with no balancing 
> > pm_runtime_get?
> 
> this is good point and, in fact, a doubt I have myself. How are we
> supposed to check if device is suspended ? In case it _is_ suspended we
> might not be able to read device's registers due to clocks possibly
> being gated.

That's really a separate question.  It has a simple answer, though: If 
you want to access a device's registers, call pm_runtime_get_sync() 
beforehand and pm_runtime_put() (or _put_sync()) afterward.  Then it 
won't matter if the device was suspended originally.

If you actually do want to tell whether or not a device is suspended
and nothing more, call pm_runtime_status_suspended().  Of course, this
is racy -- the power state might change right after you make the call.

> Also, considering that some drivers are used in multiple platforms and
> those might behave differently when it comes to clock handling, how do
> we do that ? Should we require drivers to explicitly clk_get();
> clk_prepare_enable(); pm_runtime_set_active(); pm_runtime_enable() ?

I don't know much about clock handling.  In general, the
pm_runtime_set_active() and pm_runtime_enable() parts should be done by
the subsystem, not the driver, whenever possible.

> While that's doable, I don't see how that'd be doable for OMAP since
> they want to hide clock handling from drivers.
> 
> Any tips ?

Whichever piece of code is responsible for associating a clock with a
device should also be responsible for making sure that neither is
suspended when the driver's probe routine runs.  I'm not sure how 
different platforms do this; using a PM domain could be one answer.

All this is somewhat off the point of my original comment, however.  
Drivers must be sure to balance their pm_runtime_get() and _put()  
calls.  Having an unbalanced _put() in the remove routine is almost
certainly a mistake -- especially if it is conditional on the device's
power state, because a device can remain unsuspended even after the
driver does a pm_runtime_put().  For example, this will happen if the
user wrote "on"  to /sys/.../power/control.

Alan Stern

--
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] late arch/metag fixes for v3.9-rc1

[James Hogan]

Hi Linus,

Here's the arch/metag tree for v3.9-rc1, based on v3.8. Details can be
found in tag message.

The hard conflicts when merging are all trivial. There is a build fix
required after merging though. Commit 373d4d ("taint: add explicit flag
to show whether lock dep is still OK") adds a flags argument to
add_taint that causes:

arch/metag/kernel/traps.c In function 'die':
arch/metag/kernel/traps.c +110 : error: too few arguments to function 
'add_taint'

The fix is like the others in the aforementioned commit:

diff --git a/arch/metag/kernel/traps.c b/arch/metag/kernel/traps.c
index 5cad156..8961f24 100644
--- a/arch/metag/kernel/traps.c
+++ b/arch/metag/kernel/traps.c
@@ -107,7 +107,7 @@ void die(const char *str, struct pt_regs *regs, long err,
   task_pid_nr(current), task_stack_page(current) + THREAD_SIZE);
 
bust_spinlocks(0);
-   add_taint(TAINT_DIE);
+   add_taint(TAINT_DIE, LOCKDEP_NOW_UNRELIABLE);
if (kexec_should_crash(current))
crash_kexec(regs);
 
The other integration issues expected are all harmless, so I'm happy to
fix these up in a later set of patches if you prefer:

* arch/metag/Kconfig: CONFIG_METAG selects GENERIC_SIGALTSTACK which no
  longer exists since d64008a ("burying unused conditionals")
* arch/metag/Kconfig: CONFIG_METAG selects HAVE_IRQ_WORK which no longer
  exists since cf9b286 ("metag: remove select CONFIG_HAVE_IRQ_WORK")
* arch/metag/Kconfig: defines ARCH_NO_VIRT_TO_BUS which no longer does
  anything since 887cbce0 ("arch Kconfig: centralise
  CONFIG_ARCH_NO_VIRT_TO_BUS")
* arch/metag/configs/*: CONFIG_EXPERIMENTAL=y no longer needed

Please consider pulling.

Thanks
James

The following changes since commit 19f949f52599ba7c3f67a5897ac6be14bfcb1200:

  Linux 3.8 (2013-02-18 15:58:34 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/metag.git 
tags/metag-v3.9-rc1-v4

for you to fetch changes up to c60ac31542e93499b58dcfc1e3f6550ba5b5728e:

  metag: Provide dma_get_sgtable() (2013-03-02 20:11:17 +)


ImgTec Meta architecture changes for v3.9-rc1

This adds core architecture support for Imagination's Meta processor
cores, followed by some later miscellaneous arch/metag cleanups and
fixes which I kept separate to ease review:

 - Support for basic Meta 1 (ATP) and Meta 2 (HTP) core architecture
 - A few fixes all over, particularly for symbol prefixes
 - A few privilege protection fixes
 - Several cleanups (setup.c includes, split out a lot of metag_ksyms.c)
 - Fix some missing exports
 - Convert hugetlb to use vm_unmapped_area()
 - Copy device tree to non-init memory
 - Provide dma_get_sgtable()

Signed-off-by: James Hogan 


James Hogan (61):
  asm-generic/io.h: check CONFIG_VIRT_TO_BUS
  asm-generic/unistd.h: handle symbol prefixes in cond_syscall
  Revert some of "binfmt_elf: cleanups"
  Add HAVE_64BIT_ALIGNED_ACCESS
  trace/ring_buffer: handle 64bit aligned structs
  metag: Add MAINTAINERS entry
  metag: Headers for core arch constants
  metag: Header for core memory mapped registers
  metag: Boot
  metag: TBX header
  metag: TBX source
  metag: Cache/TLB handling
  metag: Memory management
  metag: Memory handling
  metag: Huge TLB
  metag: Highmem support
  metag: TCM support
  metag: Signal handling
  metag: Device tree
  metag: ptrace
  metag: Time keeping
  metag: Traps
  metag: IRQ handling
  metag: Internal and external irqchips
  metag: System Calls
  metag: Scheduling/Process management
  metag: Module support
  metag: Atomics, locks and bitops
  metag: Basic documentation
  metag: SMP support
  metag: DMA
  metag: Optimised library functions
  metag: Stack unwinding
  metag: Various other headers
  mm: define VM_GROWSUP for CONFIG_METAG
  Kconfig.debug: add METAG to dependency lists
  metag: Build infrastructure
  metag: Perf
  metag: ftrace support
  scripts/checkstack.pl: Add metag support
  metag: Add JTAG Debug Adapter (DA) support
  metag: add __init to metag_cache_probe()
  metag: add boot time LNKGET/LNKSET check
  perf: Enable building perf tools for Meta
  metag: kernel/setup.c: sort includes
  metag: make TXPRIVEXT bits explicit
  metag: protect more non-MMU memory regions
  metag: export metag_code_cache_flush_all
  metag: export clear_page and copy_page
  metag: hugetlb: convert to vm_unmapped_area()
  genksyms: fix metag symbol prefix on crc symbols
  metag: move irq enable out of irqflags.h on SMP
  metag: move traps.c exports out of metag_ksyms.c
  metag: move kick.c exports out of metag_ksyms.c
  metag: move setup.c exports out of metag_ksyms.c
  metag: move usercopy.c exports out of 

[PATCH 2/4] Coccinelle: Cleanup the setting of the FLAGS and OPTIONS variables

[Nicolas Palix]

The FLAGS variable is factorized independently of the ONLINE mode.
The OPTIONS variable is now based on LINUXINCLUDE and explicit
includes are thus removed.

The format of the -I option differs between gcc and spatch.
The COCCIINCLUDE is used to adapt the format. This rewritting
needs bash.

Signed-off-by: Nicolas Palix 
---
 scripts/coccicheck |   25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/scripts/coccicheck b/scripts/coccicheck
index 7f0d6a6..cdde8e0 100755
--- a/scripts/coccicheck
+++ b/scripts/coccicheck
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
 
 SPATCH="`which ${SPATCH:=spatch}`"
 
@@ -11,24 +11,25 @@ else
VERBOSE=0
 fi
 
+FLAGS="-very_quiet"
+
+# spatch only allows include directories with the syntax "-I include"
+# while gcc also allows "-Iinclude" and "-include include"
+COCCIINCLUDE=${LINUXINCLUDE//-I/-I }
+COCCIINCLUDE=${COCCIINCLUDE//-include/-I}
+
 if [ "$C" = "1" -o "$C" = "2" ]; then
 ONLINE=1
 
-# This requires Coccinelle >= 0.2.3
-#FLAGS="-ignore_unknown_options -very_quiet"
-#OPTIONS=$*
-
-# Workaround for Coccinelle < 0.2.3
-   FLAGS="-I $srctree/include -very_quiet"
-   shift $(( $# - 1 ))
-   OPTIONS=$1
+# Take only the last argument, which is the C file to test
+shift $(( $# - 1 ))
+OPTIONS="$COCCIINCLUDE $1"
 else
 ONLINE=0
-FLAGS="-very_quiet"
 if [ "$KBUILD_EXTMOD" = "" ] ; then
-OPTIONS="-dir $srctree"
+OPTIONS="-dir $srctree $COCCIINCLUDE"
 else
-OPTIONS="-dir $KBUILD_EXTMOD -patch $srctree -I $srctree/include -I 
$KBUILD_EXTMOD/include"
+OPTIONS="-dir $KBUILD_EXTMOD -patch $srctree $COCCIINCLUDE"
 fi
 fi
 
-- 
1.7.10.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/4] Coccinelle: Add support to the SPFLAGS variable

[Nicolas Palix]

The SPFLAGS variable allows to pass additional options
to spatch, e.g. -use_glimpse.

Signed-off-by: Nicolas Palix 
---
 Documentation/coccinelle.txt |   11 ++-
 scripts/coccicheck   |2 +-
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/Documentation/coccinelle.txt b/Documentation/coccinelle.txt
index dffa2d6..18de785 100644
--- a/Documentation/coccinelle.txt
+++ b/Documentation/coccinelle.txt
@@ -114,7 +114,7 @@ To apply Coccinelle to a specific directory, M= can be used.
 For example, to check drivers/net/wireless/ one may write:
 
 make coccicheck M=drivers/net/wireless/
-
+
 To apply Coccinelle on a file basis, instead of a directory basis, the
 following command may be used:
 
@@ -134,6 +134,15 @@ MODE variable explained above.
 In this mode, there is no information about semantic patches
 displayed, and no commit message proposed.
 
+ Additional flags
+~~
+
+Additional flags can be passed to spatch through the SPFLAGS
+variable.
+
+make SPFLAGS=--use_glimpse coccicheck
+
+See spatch --help to learn more about spatch options.
 
  Proposing new semantic patches
 
diff --git a/scripts/coccicheck b/scripts/coccicheck
index cdde8e0..6d492c0 100755
--- a/scripts/coccicheck
+++ b/scripts/coccicheck
@@ -11,7 +11,7 @@ else
VERBOSE=0
 fi
 
-FLAGS="-very_quiet"
+FLAGS="$SPFLAGS -very_quiet"
 
 # spatch only allows include directories with the syntax "-I include"
 # while gcc also allows "-Iinclude" and "-include include"
-- 
1.7.10.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/4] Coccinelle: Restore coccicheck verbosity in ONLINE mode (C=1 or C=2)

[Nicolas Palix]

A recent patch have introduce the VERBOSE variable and comments
now depend on it. However, the message printed for each cocci file
such not be printed when the ONLINE mode is active, whatever is
the value of VERBOSE.

Signed-off-by: Nicolas Palix 
---
 scripts/coccicheck |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/coccicheck b/scripts/coccicheck
index 85d3189..7f0d6a6 100755
--- a/scripts/coccicheck
+++ b/scripts/coccicheck
@@ -72,7 +72,7 @@ coccinelle () {
 #
 #$SPATCH -D $MODE $FLAGS -parse_cocci $COCCI $OPT > /dev/null
 
-if [ $VERBOSE -ne 0 ] ; then
+if [ $VERBOSE -ne 0 -a $ONLINE -eq 0 ] ; then
 
FILE=`echo $COCCI | sed "s|$srctree/||"`
 
-- 
1.7.10.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/4] Coccinelle: Fix patch output when coccicheck is used with M= and C=

[Nicolas Palix]

When the M variable is used, the -patch option should be given
to spatch. This patch fixes the case where C is used.

Signed-off-by: Nicolas Palix 
---
 scripts/coccicheck |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/scripts/coccicheck b/scripts/coccicheck
index 6d492c0..06fcb33 100755
--- a/scripts/coccicheck
+++ b/scripts/coccicheck
@@ -29,10 +29,14 @@ else
 if [ "$KBUILD_EXTMOD" = "" ] ; then
 OPTIONS="-dir $srctree $COCCIINCLUDE"
 else
-OPTIONS="-dir $KBUILD_EXTMOD -patch $srctree $COCCIINCLUDE"
+OPTIONS="-dir $KBUILD_EXTMOD $COCCIINCLUDE"
 fi
 fi
 
+if [ "$KBUILD_EXTMOD" != "" ] ; then
+OPTIONS="-patch $srctree $OPTIONS"
+fi
+
 if [ ! -x "$SPATCH" ]; then
 echo 'spatch is part of the Coccinelle project and is available at 
http://coccinelle.lip6.fr/'
 exit 1
-- 
1.7.10.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 PATCH 1/2] ipc: introduce obtaining a lockless ipc object

[Linus Torvalds]

On Fri, Mar 1, 2013 at 4:16 PM, Davidlohr Bueso  wrote:
> @@ -784,7 +806,7 @@ struct kern_ipc_perm *ipcctl_pre_down(struct 
> ipc_namespace *ns,
> int err;
>
> down_write(>rw_mutex);
> -   ipcp = ipc_lock_check(ids, id);
> +   ipcp = ipc_obtain_object_check(ids, id);
> if (IS_ERR(ipcp)) {
> err = PTR_ERR(ipcp);
> goto out_up;
> @@ -801,7 +823,7 @@ struct kern_ipc_perm *ipcctl_pre_down(struct 
> ipc_namespace *ns,
> return ipcp;
>
> err = -EPERM;
> -   ipc_unlock(ipcp);
> +   rcu_read_unlock();
>  out_up:
> up_write(>rw_mutex);
> return ERR_PTR(err);

Uhhuh. This is very buggy, and I think it's the reason for the later
bugs that Emmanuel reported.

In particular, the *non-error* case is buggy, where it in the middle
of the function does

return ipcp;

for a successful lookup.

It used to return a locked ipcp, now it no longer does. And you didn't
change any of the callers, which still do the "ipc_unlock()" at the
end.  So all the locking gets completely confused.

Oops.

 Linus
--
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 PATCH 0/2] ipc: do not hold ipc lock more than necessary

[Davidlohr Bueso]

On Fri, 2013-03-01 at 17:32 -0800, Linus Torvalds wrote:
> On Fri, Mar 1, 2013 at 4:16 PM, Davidlohr Bueso  
> wrote:
> >
> > With Rik's semop-multi.c microbenchmark we can see the following
> > results:
> 
> Ok, that certainly looks very good.
> 
> > +  59.40%a.out  [kernel.kallsyms]  [k] _raw_spin_lock
> > +  17.47%a.out  [kernel.kallsyms]  [k] _raw_spin_lock
> 
> I had somewhat high expectations, but that's just better than I really
> hoped for. Not only is the percentage down, it's down for the case of
> a much smaller number of overall cycle cost, so it's a really big
> reduction in contention spinning.
> 
> Of course, contention will come back and overwhelm you at *some*
> point, but it seems the patches certainly moved the really bad
> contention point out some way..
> 
> > +   6.14%a.out  [kernel.kallsyms]  [k] sys_semtimedop
> > +  11.08%a.out  [kernel.kallsyms]  [k] sys_semtimedop
> > While the _raw_spin_lock time is drastically reduced, others do increase.
> > This results in an overall speedup of ~1.7x regarding ops/sec.
> 
> Actually, the others don't really increase. Sure, the *percentages* go
> up, but that's just because it has to add up to 100% in the end. So
> it's not that you're moving costs from one place to another - the 1.7x
> speedup is the real reduction in costs, and then that 6.14% -> 11.08%
> "growth" is really nothing but that (and yes, 1.7 x 6.14 really does
> get pretty close).
> 
> So nothing really got slower, despite the percentages going up.
> 
> Looks good to me. Of course, the *real* issue is if this is a win on
> real code too. And I bet it is, it just won't be quite as noticeable.
> But if anything, real code is likely to have less contention to begin
> with, because it has more things going on outside of the spinlocks. So
> it should see an improvement, but not nearly the kind of improvement
> you quote here.
> 
> Although your 800-user swingbench numbers were pretty horrible, so
> maybe that case can improve by comparable amounts in the bad cases.
> 

Absolutely, I'll be sure to try these changes with my Oracle workloads
and report with some numbers. This obviously still needs a lot of
testing.

Thanks,
Davidlohr

--
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 PATCH 0/2] ipc: do not hold ipc lock more than necessary

[Davidlohr Bueso]

On Sat, 2013-03-02 at 15:35 +0700, Emmanuel Benisty wrote:
> On Sat, Mar 2, 2013 at 2:08 PM, Michel Lespinasse  wrote:
> > On Sat, Mar 2, 2013 at 12:43 PM, Emmanuel Benisty  
> > wrote:
> >> Hi,
> >>
> >> On Sat, Mar 2, 2013 at 7:16 AM, Davidlohr Bueso  
> >> wrote:
> >>> The following set of not-thoroughly-tested patches are based on the
> >>> discussion of holding the ipc lock unnecessarily, such as for permissions
> >>> and security checks:
> >>>
> >>> https://lkml.org/lkml/2013/2/28/540
> >>>
> >>> Patch 0/1: Introduces new functions, analogous to ipc_lock and 
> >>> ipc_lock_check
> >>> in the ipc utility code, allowing to obtain the ipc object without 
> >>> holding the lock.
> >>>
> >>> Patch 0/2: Use the new functions and only acquire the ipc lock when 
> >>> needed.
> >>
> >> Not sure how much a work in progress this is but my machine dies
> >> immediately when I start chromium, crappy mobile phone picture here:
> >> http://i.imgur.com/S0hfPz3.jpg
> >
> > We are missing the top of the trace there, so it's hard to be sure -
> > however, this could well be caused by the if (!out) check (instead of
> > if (IS_ERR(out)) that I noticed in patch 1/2.
> 
> Merci Michel but unfortunately, I'm still getting the same issue.

Will try to reproduce (and further testing on other machines) and debug
later today.

Thanks for testing,
Davidlohr

--
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 2/2] ipc: semaphores: do not hold ipc lock more than necessary

[Davidlohr Bueso]

On Fri, 2013-03-01 at 17:20 -0800, Linus Torvalds wrote:
> On Fri, Mar 1, 2013 at 4:16 PM, Davidlohr Bueso  
> wrote:
> > +static inline struct sem_array *sem_obtain_object(struct ipc_namespace 
> > *ns, int id)
> > +{
> > +   struct kern_ipc_perm *ipcp = ipc_obtain_object(_ids(ns), id);
> > +
> > +   if (IS_ERR(ipcp))
> > +   return (struct sem_array *)ipcp;
> 
> This should use ERR_CAST() to make it more obvious what's going on.
> 
> > +static inline struct sem_array *sem_obtain_object_check(struct 
> > ipc_namespace *ns,
> > +   int id)
> > +{
> > +   struct kern_ipc_perm *ipcp = ipc_obtain_object_check(_ids(ns), 
> > id);
> > +
> > +   if (IS_ERR(ipcp))
> > +   return (struct sem_array *)ipcp;
> 
> Same here.

Ok

> 
> > +/*
> > + * Call inside the rcu read section.
> > + */
> > +static inline void sem_getref(struct sem_array *sma)
> > +{
> > +   spin_lock(&(sma)->sem_perm.lock);
> > +   ipc_rcu_getref(sma);
> > +   ipc_unlock(&(sma)->sem_perm);
> > +}
> 
> This really makes me wonder if we shouldn't just use an atomic counter
> for "refcount". But I guess that would be a separate patch.
> 

Ah, yes indeed.

> But all the uses of refcount really look like the normal atomic ops
> migth be the right thing. Especially if we no longer expect to hold
> the lock most of the time.
> 
> > +   spin_lock(>sem_perm.lock);
> 
> I really would almost want to make these things be "ipc_lock_object()"
> rather than an open-coded spinlock like this. But that's not a big
> deal.

Sure.

> 
> Patch looks fine to me in general.
> 

Thanks for taking a look!

Davidlohr

--
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 2/2] ipc: semaphores: do not hold ipc lock more than necessary

[Davidlohr Bueso]

On Sat, 2013-03-02 at 12:41 +0800, Michel Lespinasse wrote:
> On Sat, Mar 2, 2013 at 8:16 AM, Davidlohr Bueso  
> wrote:
> > Instead of holding the ipc lock for permissions and security
> > checks, among others, only acquire it when necessary.
> >
> > Signed-off-by: Davidlohr Bueso 
> 
> You got some really great test results on this; I think they deserve
> to be mentioned in the commit message.

Absolutely.

> 
> Code looks fine to me otherwise, but I only had a quick look.
> 
> Nice work!
> 
> Acked-by: Michel Lespinasse 
> 

Thanks for reviewing, Michel.

Davidlohr

--
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] caif_dev: fix sparse warnings for caif_flow_cb

[Silviu-Mihai Popescu]

This fixed the following sparse warning:
net/caif/caif_dev.c:121:6: warning: symbol 'caif_flow_cb' was not
declared. Should it be static?

Signed-off-by: Silviu-Mihai Popescu 
---
 net/caif/caif_dev.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/caif/caif_dev.c b/net/caif/caif_dev.c
index 1ae1d9c..21760f0 100644
--- a/net/caif/caif_dev.c
+++ b/net/caif/caif_dev.c
@@ -118,7 +118,7 @@ static struct caif_device_entry *caif_get(struct net_device 
*dev)
return NULL;
 }
 
-void caif_flow_cb(struct sk_buff *skb)
+static void caif_flow_cb(struct sk_buff *skb)
 {
struct caif_device_entry *caifd;
void (*dtor)(struct sk_buff *skb) = NULL;
-- 
1.7.9.5

--
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 06/10] usb: xhci: Enable runtime pm in xhci-plat

[Felipe Balbi]

Hi,

On Sat, Mar 02, 2013 at 10:53:16AM -0500, Alan Stern wrote:
> On Sat, 2 Mar 2013, Vivek Gautam wrote:
> 
> > By enabling runtime pm in this driver allows users of
> > xhci-plat to enter into runtime pm. This is not full
> > runtime pm support (AKA xhci-plat doesn't actually power
> > anything off when in runtime suspend mode) but,
> > just basic enablement.
> > 
> > Signed-off-by: Vivek Gautam 
> > CC: Doug Anderson 
> > ---
> >  drivers/usb/host/xhci-plat.c |7 +++
> >  1 files changed, 7 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> > index c9c7e13..595cb52 100644
> > --- a/drivers/usb/host/xhci-plat.c
> > +++ b/drivers/usb/host/xhci-plat.c
> > @@ -12,6 +12,7 @@
> >   */
> >  
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  
> > @@ -149,6 +150,8 @@ static int xhci_plat_probe(struct platform_device *pdev)
> > if (ret)
> > goto put_usb3_hcd;
> >  
> > +   pm_runtime_enable(>dev);
> 
> This is generally not a good idea.  You shouldn't enable a device for 
> runtime PM without first telling the PM core what state it is in.
> 
> > @@ -174,6 +177,10 @@ static int xhci_plat_remove(struct platform_device 
> > *dev)
> > struct usb_hcd  *hcd = platform_get_drvdata(dev);
> > struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> >  
> > +   if (!pm_runtime_suspended(>dev))
> > +   pm_runtime_put(>dev);
> > +   pm_runtime_disable(>dev);
> > +
> > usb_remove_hcd(xhci->shared_hcd);
> > usb_put_hcd(xhci->shared_hcd);
> 
> This is very strange.  Why have a pm_runtime_put with no balancing 
> pm_runtime_get?

this is good point and, in fact, a doubt I have myself. How are we
supposed to check if device is suspended ? In case it _is_ suspended we
might not be able to read device's registers due to clocks possibly
being gated.

Also, considering that some drivers are used in multiple platforms and
those might behave differently when it comes to clock handling, how do
we do that ? Should we require drivers to explicitly clk_get();
clk_prepare_enable(); pm_runtime_set_active(); pm_runtime_enable() ?

While that's doable, I don't see how that'd be doable for OMAP since
they want to hide clock handling from drivers.

Any tips ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 30/31] driver/base: implement subsys_virtual_register()

[Tejun Heo]

Hello, Greg.

On Sat, Mar 02, 2013 at 10:17:27AM -0800, Greg Kroah-Hartman wrote:
> I'm almost afraid to ask what you want to export to userspace for a
> workqueue that userspace would care about...

Workqueue is being extended to support worker pools with custom
attributes so that it can replace private worker pool implementations
in writeback, btrfs and other places.  They want to expose
per-workqueue tunables to userland - nice level, cpu affinity and
cgroup association of those IO threads to userland, so that's where
the sysfs interface comes in.  The export is opt-in and those
workqueues should have well defined name.

> If you create a subsystem, the devices will show up under the virtual
> "bus" if you don't give them a parent, so this patch shouldn't be
> needed, unless you are abusing the driver model.  What am I missing
> here?

If you don't give the parent, it ends up in /sys/devices/ with
symlinks appearing under /sys/bus/.  I didn't know where to put it.
Right under /sys/devices/ doesn't seem right to me.  We already have
one like that /sys/devices/software/ which actually is for perf
software events and it just is weird.  I was wondering where to put it
and Kay told me that /sys/devices/virtual/ would be the best fit
although we don't yet have proper interface for it, so the patch.  I
don't really care where it shows up and it apparently shouldn't matter
for userland as long as /sys/bus/ part is there but /sys/virtual/
seems to be the best fit at the moment.

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] irq: add quirk for broken interrupt remapping on 55XX chipsets

[Neil Horman]

On Sat, Mar 02, 2013 at 11:21:29AM -0500, Prarit Bhargava wrote:
> On 03/01/2013 12:17 PM, Neil Horman wrote:
> > A few years back intel published a spec update:
> > http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf
> > 
> > For the 5520 and 5500 chipsets which contained an errata (specificially 
> > errata
> > 53), which noted that these chipsets can't properly do interrupt remapping, 
> > and
> > as a result the recommend that interrupt remapping be disabled in bios.  
> > While
> > many vendors have a bios update to do exactly that, not all do, and of 
> > course
> > not all users update their bios to a level that corrects the problem.  As a
> > result, occasionally interrupts can arrive at a cpu even after affinity for 
> > that
> > interrupt has be moved, leading to lost or spurrious interrupts (usually
> > characterized by the message:
> > kernel: do_IRQ: 7.71 No irq handler for vector (irq -1)
> > 
> > There have been several incidents recently of people seeing this error, and
> > investigation has shown that they have system for which their BIOS level is 
> > such
> > that this feature was not properly turned off.  As such, it would be good to
> > give them a reminder that their systems are vulnurable to this problem.
> > 
> > Signed-off-by: Neil Horman 
> > CC: Prarit Bhargava 
> > CC: Don Zickus 
> > CC: Don Dutile 
> > CC: Bjorn Helgaas 
> > CC: Asit Mallick 
> > CC: linux-...@vger.kernel.org
> > ---
> >  drivers/iommu/intel_irq_remapping.c | 20 
> >  include/linux/pci_ids.h |  2 ++
> >  2 files changed, 22 insertions(+)
> > 
> > diff --git a/drivers/iommu/intel_irq_remapping.c 
> > b/drivers/iommu/intel_irq_remapping.c
> > index f3b8f23..9bfb6c2 100644
> > --- a/drivers/iommu/intel_irq_remapping.c
> > +++ b/drivers/iommu/intel_irq_remapping.c
> > @@ -1113,3 +1113,23 @@ struct irq_remap_ops intel_irq_remap_ops = {
> > .msi_setup_irq  = intel_msi_setup_irq,
> > .setup_hpet_msi = intel_setup_hpet_msi,
> >  };
> > +
> > +
> > +static void intel_remapping_check(struct pci_dev *dev)
> > +{
> > +   u8 revision;
> > +
> > +   pci_read_config_byte(dev, PCI_REVISION_ID, );
> > +
> > +   if ((revision == 0x13) && irq_remapping_enabled) {
> > +   pr_warn("WARNING WARNING WARNING WARNING WARNING WARNING\n"
> > +   "This system BIOS has enabled interrupt remapping\n"
> > +   "on a chipset that contains an errata making that\n"
> > +   "feature unstable.  Please reboot with nointremap\n"
> > +   "added to the kernel command line and contact\n"
> > +   "your BIOS vendor for an update");
> 
> Make this one line?  Might be too long but I believe the preferred policy is 
> now
> to keep the output on one line so that it is easy to find in the kernel 
> source.
> 
> Also, IMO, remove the WARNING WARNING stuff.
> 
> You also should probably use HW_ERR here too.
> 
> P.
> 
I can do that, I'll post version 2 on monday.
Neil

--
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 URGENT] ext4 regression fix for 3.9

[Linus Torvalds]

On Thu, Feb 28, 2013 at 8:00 PM, Theodore Ts'o  wrote:
>
> ext4_es_reclaim_extents_count() is getting called out of the slab
> shrinker.  It's getting called too often when there is significant
> memory pressure.  We can optimize this so we're not calculating it all
> the time.

This needs to be fixed or reverted. I traced back some user
interaction problems to this same issue. It literally gets so bad that
the whole system is choppy, and a profile shows that a lot of time is
being spent in the spin-lock protecting these data structures. Called
from ext4_es_reclaim_extents_count, ext4_es_lru_add and
ext4_es_shrink.

We're talking very user-noticeable pauses, so it's not just the
spinlock, there's some real badness that comes in with it too.
Possibly related to other (sleeping) locks being held while the data
structures are then refilled or something.

   Linus
--
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: fasync race in fs/fcntl.c

[Al Viro]

On Sat, Mar 02, 2013 at 03:00:28AM -0800, Russ Dill wrote:
> I'm seeing a race in fs/fcntl.c. I'm not sure exactly how the race is
> occurring, but the following is my best guess. A kernel log is
> attached.

[snip the analysis - it's a different lock anyway]

The traces below are essentially sys_execve() getting to get_random_bytes(),
to kill_fasync(), to send_sigio(), which spins on tasklist_lock.

Could you rebuild it with lockdep enabled and try to reproduce that?
I very much doubt that this execve() is a part of deadlock - it's
getting caught on one, but it shouldn't be holding any locks that
nest inside tasklist_lock at that point, so even it hadn't been there,
the process holding tasklist_lock probably wouldn't have progressed any
further...

> I exercise this by running a UML instance which uses /dev/random.
> After a day or so, I'll eventually get a crash or a hang. I captured
> this with netconsole.
> 
> 
> [172635.399438] [ cut here ]
> [172635.399449] WARNING: at
> /build/buildd/linux-3.8.0/kernel/watchdog.c:246
> watchdog_overflow_callback+0x9c/0xd0()
> [172635.399451] Hardware name: VPCSE190X
> [172635.399454] Watchdog detected hard LOCKUP on cpu 0
> [172635.399456] Modules linked in: ftdi_sio netconsole(F) configfs(F)
> ext2(F) nls_iso8859_1(F) usb_storage(F) pl2303 usbserial snd
> _usb_audio snd_usbmidi_lib parport_pc(F) ppdev(F) lp(F) parport(F)
> bnep rfcomm bluetooth binfmt_misc(F) dm_crypt(F) uvcvideo arc4(
> F) snd_hda_codec_hdmi iwldvm snd_hda_codec_realtek snd_hda_intel
> videobuf2_vmalloc videobuf2_memops mac80211 videobuf2_core snd_hd
> a_codec videodev snd_hwdep(F) coretemp snd_pcm(F) snd_page_alloc(F)
> joydev(F) iwlwifi[172635.399521] [ cut here ]
> [172635.399525] WARNING: at
> /build/buildd/linux-3.8.0/net/core/skbuff.c:573
> skb_release_head_state+0xed/0x100()
> [172635.399525] Hardware name: VPCSE190X
> [172635.399526] Modules linked in: ftdi_sio netconsole(F) configfs(F)
> ext2(F) nls_iso8859_1(F) usb_storage(F) pl2303 usbserial snd_usb_audio
> snd_usbmidi_lib parport_pc(F) ppdev(F) lp(F) parport(F) bnep rfcomm
> bluetooth binfmt_misc(F) dm_crypt(F) uvcvideo arc4(F)
> snd_hda_codec_hdmi iwldvm snd_hda_codec_realtek snd_hda_intel
> videobuf2_vmalloc videobuf2_memops mac80211 videobuf2_core
> snd_hda_codec videodev snd_hwdep(F) coretemp snd_pcm(F)
> snd_page_alloc(F) joydev(F) iwlwifi kvm_intel snd_seq_midi(F)
> snd_seq_midi_event(F) snd_rawmidi(F) kvm cfg80211 dm_multipath(F)
> snd_seq(F) snd_seq_device(F) tpm_infineon snd_timer(F) psmouse(F)
> snd(F) soundcore(F) scsi_dh serio_raw(F) sony_laptop rtsx_pci_ms mei
> microcode(F) memstick mac_hid pcspkr lpc_ich tpm_tis firewire_sbp2
> firewire_core crc_itu_t(F) btrfs(F) zlib_deflate(F) libcrc32c(F)
> hid_generic usbhid hid rtsx_pci_sdmmc ghash_clmulni_intel(F)
> aesni_intel(F) aes_x86_64(F) xts(F) lrw(F) gf128mul(F) ablk_helper(F)
> cryptd(F) radeon ahci(F) libahci(F) r8169 i915 ttm i2c_algo_bit
> drm_kms_helper video(F) drm rtsx_pci
> [172635.399572] Pid: 12575, comm: flock Tainted: GF
> 3.8.0-7-generic #15-Ubuntu
> [172635.399572] Call Trace:
> [172635.399573][] warn_slowpath_common+0x7f/0xc0
> [172635.399577]  [] warn_slowpath_null+0x1a/0x20
> [172635.399579]  [] skb_release_head_state+0xed/0x100
> [172635.399580]  [] __kfree_skb+0x12/0xa0
> [172635.399582]  [] consume_skb+0x2c/0x80
> [172635.399586]  [] rtl8169_poll+0x4b7/0x6d0 [r8169]
> [172635.399590]  [] netpoll_poll_dev+0x162/0x580
> [172635.399593]  [] ? __alloc_skb+0x8b/0x2a0
> [172635.399595]  [] netpoll_send_skb_on_dev+0x18c/0x3a0
> [172635.399598]  [] netpoll_send_udp+0x278/0x2a0
> [172635.399600]  [] write_msg+0xc7/0x110 [netconsole]
> [172635.399603]  []
> call_console_drivers.constprop.13+0x91/0x100
> [172635.399605]  [] console_unlock+0x2db/0x420
> [172635.399606]  [] vprintk_emit+0x1fd/0x4e0
> [172635.399608]  [] ? watchdog_overflow_callback+0x9c/0xd0
> [172635.399610]  [] printk+0x67/0x69
> [172635.399613]  [] print_modules+0xa3/0xd0
> [172635.399617]  [] warn_slowpath_common+0x7a/0xc0
> [172635.399618]  [] warn_slowpath_fmt+0x4c/0x50
> [172635.399620]  [] ? sched_clock_cpu+0xbd/0x110
> [172635.399623]  [] ? touch_nmi_watchdog+0x80/0x80
> [172635.399625]  [] watchdog_overflow_callback+0x9c/0xd0
> [172635.399627]  [] __perf_event_overflow+0x9d/0x230
> [172635.399630]  [] ? x86_perf_event_set_period+0xd7/0x160
> [172635.399632]  [] perf_event_overflow+0x14/0x20
> [172635.399634]  [] intel_pmu_handle_irq+0x1ab/0x330
> [172635.399637]  [] perf_event_nmi_handler+0x1d/0x20
> [172635.399640]  [] nmi_handle.isra.0+0x51/0x80
> [172635.399641]  [] do_nmi+0xe0/0x360
> [172635.399643]  [] end_repeat_nmi+0x1e/0x2e
> [172635.399645]  [] ? __read_lock_failed+0x9/0x20
> [172635.399648]  [] ? __read_lock_failed+0x9/0x20
> [172635.399649]  [] ? __read_lock_failed+0x9/0x20
> [172635.399651]  <>  [] _raw_read_lock+0x13/0x20
> [172635.399654]  [] send_sigio+0x52/0xf0
> [172635.399656]  [] kill_fasync+0x61/0x90
> [172635.399658] 

Re: [ 34/77] xen/blkback: Dont trust the handle from the frontend.

[Ben Hutchings]

On Fri, 2013-03-01 at 22:12 +0100, Paul Bolle wrote:
> On Fri, 2013-03-01 at 11:44 -0800, Greg Kroah-Hartman wrote:
> > 3.8-stable review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: Konrad Rzeszutek Wilk 
> > 
> > commit 01c681d4c70d64cb72142a2823f27c4146a02e63 upstream.
> > 
> > The 'handle' is the device that the request is from. For the life-time
> > of the ring we copy it from a request to a response so that the frontend
> > is not surprised by it. But we do not need it - when we start processing
> > I/Os we have our own 'struct phys_req' which has only most essential
> > information about the request. In fact the 'vbd_translate' ends up
> > over-writing the preq.dev with a value from the backend.
> 
> Unless that call to vb_translate() fails, doesn't it? Wouldn't preq.dev
> still contain random data in that case?
> 
> > This assignment of preq.dev with the 'handle' value is superfluous
> > so lets not do it.
> > 
> > Acked-by: Jan Beulich 
> > Acked-by: Ian Campbell 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> > Signed-off-by: Greg Kroah-Hartman 
> > 
> > ---
> >  drivers/block/xen-blkback/blkback.c |1 -
> >  1 file changed, 1 deletion(-)
> > 
> > --- a/drivers/block/xen-blkback/blkback.c
> > +++ b/drivers/block/xen-blkback/blkback.c
> > @@ -879,7 +879,6 @@ static int dispatch_rw_block_io(struct x
> > goto fail_response;
> > }
> >  
> > -   preq.dev   = req->u.rw.handle;
> > preq.sector_number = req->u.rw.sector_number;
> > preq.nr_sects  = 0;
> >  
> 
> This introduces a new GCC warning in the stable 3.8.y tree:
> drivers/block/xen-blkback/blkback.c: In function 'dispatch_rw_block_io':
> drivers/block/xen-blkback/blkback.c:904:3: warning: 'preq.dev' may be 
> used uninitialized in this function [-Wuninitialized]
> 
> It does look GCC is right here. But I'm totally new to the code in
> question, so I'll just ask whether this can really go in stable as is.

When gcc compiles something like this:

static int foo(int *p)
{
if (rand() & 1)
return -1;
*p = 0;
return 0;
}

int bar(void)
{
int i;
if (foo() < 0)
return 1;
return i;
}

and inlines foo() into bar(), sometimes it fails to recognise that i
will definitely be initialised before use.  This simple example seems to
be OK but more complex functions such as these will often trigger this
warning.  The warning is really quite useless now.

Ben.

-- 
Ben Hutchings
Computers are not intelligent.  They only think they are.


signature.asc
Description: This is a digitally signed message part

Re: [GIT PULL] late arch/metag fixes for v3.9-rc1

[Linus Torvalds]

On Sat, Mar 2, 2013 at 11:19 AM, Borislav Petkov  wrote:
>
> I have a faint suspicion who "somebody" might be. :)

Nobody has *ever* called me subtle.

Linus
--
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: fasync race in fs/fcntl.c

[Al Viro]

On Sat, Mar 02, 2013 at 06:42:43PM +, Al Viro wrote:
> ... what makes you think that it's fown->lock, in the first place?
> 
> > [172635.399651]  <>  [] _raw_read_lock+0x13/0x20
> > [172635.399654]  [] send_sigio+0x52/0xf0
> 
> send_sigio() is
>   [initialization of a local variable to 1]
>   read_lock(>lock);
>   [getting type and pid, checking them]
>   read_lock(_lock);
>   [loop doing the majority of work]
>   read_unlock(_lock);
>   read_unlock(>lock);
> and you are at about 1/3 into the function.  Who said it's fown->lock and
> not tasklist_lock?  Could you check (or post) disassembly of send_sigio
> to see which one it is?

FWIW, after having grabbed Ubuntu binary of 3.8.0-8 generic (yours is -7, it's
not immediately visible on their site and the odds the damn thing has changed
in send_sigio() between those revisions are low):

send_sigio: (address is off by 16 compared to yours)
811a4bf0:   e8 cb b5 52 00  callq  0x816d01c0
(that's __fentry__)
811a4bf5:   55  push   %rbp
811a4bf6:   48 89 e5mov%rsp,%rbp
811a4bf9:   41 57   push   %r15
811a4bfb:   41 89 d7mov%edx,%r15d
811a4bfe:   41 56   push   %r14
811a4c00:   41 89 f6mov%esi,%r14d
811a4c03:   41 55   push   %r13
811a4c05:   41 54   push   %r12
811a4c07:   53  push   %rbx
811a4c08:   48 89 fbmov%rdi,%rbx
811a4c0b:   48 83 ec 10 sub$0x10,%rsp
811a4c0f:   e8 1c 32 52 00  callq  0x816c7e30
(first _raw_read_lock())

811a4c14:   44 8b 4b 10 mov0x10(%rbx),%r9d
811a4c18:   41 83 f9 03 cmp$0x3,%r9d
811a4c1c:   0f 84 a6 00 00 00   je 0x811a4cc8
811a4c22:   c7 45 d4 01 00 00 00movl   $0x1,-0x2c(%rbp)
811a4c29:   4c 8b 63 08 mov0x8(%rbx),%r12
811a4c2d:   4d 85 e4test   %r12,%r12
811a4c30:   74 5b   je 0x811a4c8d
811a4c32:   48 c7 c7 40 60 c0 81mov$0x81c06040,%rdi
811a4c39:   44 89 4d c8 mov%r9d,-0x38(%rbp)
811a4c3d:   e8 ee 31 52 00  callq  0x816c7e30
811a4c42:
... and this was the second one, i.e. read_lock(_lock).  Note that
return address is send_sigio + 0x52, just as in your trace.

In other words, tasklist_lock it is...
--
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] late arch/metag fixes for v3.9-rc1

[Borislav Petkov]

On Sat, Mar 02, 2013 at 10:40:16AM -0800, Linus Torvalds wrote:
> > Hmm, so this comes up almost everytime new maintainers send stuff (and
> > when seasoned maintainers forget :)), maybe we should hold it down
> > somewhere in Documentation/ for future reference?
> 
> If somebody wants to edit it a bit for readability (and maybe try to
> gather previous rants of mine), I'll happily take the patch.

I have a faint suspicion who "somebody" might be. :)

> And we should probably add some commentary from submaintainers too.
> They often have their own issues. Some of them are the same "dammit, I
> relied on a rebased tree of another", but I bet there are cross-merge
> issues *within* submaintainerships too (eg there are some trees that I
> pull that have their internal topic branches with multiple maintainers
> where they merge between them, and some of them sometimes seem to have
> a bit too much merging going on).

I'll scribble something up.

-- 
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] tty: Prevent deadlock in n_gsm driver

[Ben Hutchings]

I'm looking at commit 4d9b109060f690f5c835130ff54165ae157b3087 ('tty:
Prevent deadlock in n_gsm driver') which was cc'd to stable.  This drops
the tty lock in gsm_dlci_release().

I could apply it to 3.2.y with some adjustment, but I checked the
locking context of this function and I think there's another bug to fix.
Tracing back the callers in 3.2.y I found:

gsm_dlci_release
<- gsm_cleanup_mux
   <- gsmld_detach_gsm
  <- gsmld_close
 <- tty_ldisc_close
<- tty_set_ldisc [with tty_lock]
<- tty_ldisc_reinit
   <- tty_ldisc_hangup [with tty_lock]
   <- gsmld_config
  <- gsmld_ioctl
 <- tty_ioctl [without tty lock]

and I think the call chains are much the same in mainline.  So
gsmld_config() presumably needs to acquire the tty lock.

Ben.

-- 
Ben Hutchings
Computers are not intelligent.  They only think they are.


signature.asc
Description: This is a digitally signed message part

Re: [GIT PULL] late arch/metag fixes for v3.9-rc1

[James Hogan]

On 02/03/13 16:28, Linus Torvalds wrote:
> You are the
> architecture maintainer, and your job is not integration, it's to make
> sure that *your* work is as stable and unsurprising as possible.

Right, make sense. This is what it comes down to.

> See why I hate rebasing and back-merges so much?

Yes. To be clear I wasn't keen on the idea of rebasing the tree (which
is why I had fixes applied on top of it instead of keeping rebasing it),
but I was missing your point about not being my job to do integration so
I wasn't sure what other alternative to back-merges there was.

> Right now, I think your best option is to rebase just your own commits
> on top of v3.8, and then ask me to pull the result, with explanations
> of what the conflicts will be. And while I much prefer explanations
> (and also a general over-view, just so that I can put it in the commit
> message), I actually even prefer unexplained merge conflicts that I
> have to resolve over the "I did a back-merge at some random point
> because I was trying to be helpful, or because I wanted to use a new
> and untested feature that isn't even in a release kernel yet".

Okay,

> But I do *not* take new trees that do bad things. If I take a new
> architecture, I want to feel like I'm not just getting the
> architecture, but I'm also getting a maintainer that knows about
> keeping his history clean and not mixing with the independent work
> other people did, or messing up other people by rebasing public
> commits etc.

I actually take slightly obsessive pride in trying to have a clean
history where every commit works so that bisection doesn't break, which
is probably the problem here. I was trying too hard to make it just work
when everything is integrated (e.g. trying to make linux-next just work,
which now seems like a conflicting goal) instead of helping you do that.
Obviously I'll have to do better.

Thanks
James

--
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] late arch/metag fixes for v3.9-rc1

[Raymond Jennings]

On Sat, Mar 2, 2013 at 10:10 AM, Borislav Petkov  wrote:
> On Sat, Mar 02, 2013 at 08:28:56AM -0800, Linus Torvalds wrote:
>> On Sat, Mar 2, 2013 at 2:22 AM, James Hogan  wrote:
>> >
>> > Okay, I've rebased the arch/metag tree onto mainline to make all the
>> > back-merges unnecessary and applied those simple fixes into "Build
>> > infrastructure" and "Various other headers" commits (additionally
>> > trivially removing ARCH_NO_VIRT_TO_BUS which is also now unnecessary).
>>
>> No, this is *exactly* the wrong thing to do.
>
> 
>
> Hmm, so this comes up almost everytime new maintainers send stuff (and
> when seasoned maintainers forget :)), maybe we should hold it down
> somewhere in Documentation/ for future reference?

Hear hear!

Come to think of it given how often Linus has bitched about rebasing
and back merging I'm surprised it's not already mentioned.

> --
> 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/
--
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/

[GIT PULL] target updates for v3.9-rc1 (round two)

[Nicholas A. Bellinger]

Hi Linus,

Here are the remaining target-pending patches for v3.9-rc1.  Please go
ahead and pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next

The most important one here is the immediate queue starvation regression
fix for iscsi-target, which addresses a bug that's effecting v3.5+
kernels under heavy sustained READ only workloads.  Thanks alot to
Benjamin Estrabaud for helping to track this down!

Also included is a pSCSI exception bugfix from Asias, along with a
handful of other minor changes.  Both bugfixes are CC'ed to stable.

Thank you,

--nab

Asias He (4):
  target: Add __exit annotation for module_exit functions
  target/pscsi: Drop unnecessary NULL assignment to bio->bi_next
  target/pscsi: Fix page increment
  target/pscsi: Rename sg_num to nr_vecs in pscsi_get_bio()

Nicholas Bellinger (1):
  iscsi-target: Fix immediate queue starvation regression with DATAIN

 drivers/target/iscsi/iscsi_target.c |   11 +--
 drivers/target/sbp/sbp_target.c |2 +-
 drivers/target/target_core_file.c   |2 +-
 drivers/target/target_core_iblock.c |2 +-
 drivers/target/target_core_pscsi.c  |9 +++--
 5 files changed, 15 insertions(+), 11 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: fasync race in fs/fcntl.c

[Al Viro]

On Sat, Mar 02, 2013 at 03:00:28AM -0800, Russ Dill wrote:
> I'm seeing a race in fs/fcntl.c. I'm not sure exactly how the race is
> occurring, but the following is my best guess. A kernel log is
> attached.
> 
> The comment for fasync_insert_entry:
> 
>  * NOTE! It is very important that the FASYNC flag always
>  * match the state "is the filp on a fasync list".
> 
> Is not always true leading to deadlock.
> 
> CPU0 calls syscall fcntl(fd, F_SETFL, FASYNC)
> fcntl calls fdget_raw, the count on the filp is 1, so it is not
> incremented (no reference taken)

You misunderstand what fdget_raw() checks, but in any case...

> pointer points to freed memory. send_sigio is called with this
> pointer, which calls read_lock(>lock), however, the memory used
> by that lock has been reused and the system hardlocks.

... what makes you think that it's fown->lock, in the first place?

> [172635.399651]  <>  [] _raw_read_lock+0x13/0x20
> [172635.399654]  [] send_sigio+0x52/0xf0

send_sigio() is
[initialization of a local variable to 1]
read_lock(>lock);
[getting type and pid, checking them]
read_lock(_lock);
[loop doing the majority of work]
read_unlock(_lock);
read_unlock(>lock);
and you are at about 1/3 into the function.  Who said it's fown->lock and
not tasklist_lock?  Could you check (or post) disassembly of send_sigio
to see which one it is?
--
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] late arch/metag fixes for v3.9-rc1

[Linus Torvalds]

On Sat, Mar 2, 2013 at 10:10 AM, Borislav Petkov  wrote:
>
> Hmm, so this comes up almost everytime new maintainers send stuff (and
> when seasoned maintainers forget :)), maybe we should hold it down
> somewhere in Documentation/ for future reference?

If somebody wants to edit it a bit for readability (and maybe try to
gather previous rants of mine), I'll happily take the patch.

And we should probably add some commentary from submaintainers too.
They often have their own issues. Some of them are the same "dammit, I
relied on a rebased tree of another", but I bet there are cross-merge
issues *within* submaintainerships too (eg there are some trees that I
pull that have their internal topic branches with multiple maintainers
where they merge between them, and some of them sometimes seem to have
a bit too much merging going on).

Linus
--
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/