Re: [RFC] drop owner assignment from platform_drivers
> I missed the one code path you pointed out, and that should be fixed, > but that doesn't mean that the original patch should be reverted, as it > is the way we want things to be, let's just fix up the bug and move on. OK, that is a clear statement. So, what is your opinion on the original cleanup series removing unnecessary '.owner = THIS_MODULE' lines in drivers? Helpful? Noise? Thanks, Wolfram signature.asc Description: Digital signature
Re: [PATCH] tty/serial_core: Introduce lock mechanism for RS485
On 10/10/2014 15:38, Ricardo Ribalda Delgado :
> Introduce an homogeneous lock system between setting and using the rs485
> data of the uart_port.
>
> This patch should not be split into multiple ones in order to avoid
> leaving the tree in an unstable state.
>
> Suggested-by: Alan Cox
> Cc: Nicolas Ferre
> Cc: Greg Kroah-Hartman
> Cc: Jiri Slaby
> Cc: One Thousand Gnomes
> Signed-off-by: Ricardo Ribalda Delgado
> ---
>
>
> This patch sits on top of the series: "[PATCH 00/12] Handle TIOC[GS]RS485
> iocts on serial_core"
>
> If there are major changes on the other patches I will resend the whole
> patchset with this patch as part of it
>
> drivers/tty/serial/atmel_serial.c | 10 --
> drivers/tty/serial/mcf.c | 5 +
> drivers/tty/serial/omap-serial.c | 3 ---
> drivers/tty/serial/serial_core.c | 13 -
> 4 files changed, 17 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/tty/serial/atmel_serial.c
> b/drivers/tty/serial/atmel_serial.c
> index e8df8e4..32b2a8d 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -293,9 +293,6 @@ static int atmel_config_rs485(struct uart_port *port,
> {
> struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
> unsigned int mode;
> - unsigned long flags;
> -
> - spin_lock_irqsave(>lock, flags);
>
> /* Disable interrupts */
> UART_PUT_IDR(port, atmel_port->tx_done_mask);
> @@ -326,8 +323,6 @@ static int atmel_config_rs485(struct uart_port *port,
> /* Enable interrupts */
> UART_PUT_IER(port, atmel_port->tx_done_mask);
>
> - spin_unlock_irqrestore(>lock, flags);
> -
> return 0;
> }
>
> @@ -2509,6 +2504,7 @@ static int atmel_serial_probe(struct platform_device
> *pdev)
> struct atmel_uart_data *pdata = dev_get_platdata(>dev);
> void *data;
> int ret = -ENODEV;
> + bool rs485_enabled;
>
> BUILD_BUG_ON(ATMEL_SERIAL_RINGSIZE & (ATMEL_SERIAL_RINGSIZE - 1));
>
> @@ -2556,6 +2552,8 @@ static int atmel_serial_probe(struct platform_device
> *pdev)
> port->rx_ring.buf = data;
> }
>
> + rs485_enabled = port->uart.rs485.flags & SER_RS485_ENABLED;
> +
I have the feeling that moving the code chunk that uses this new
variable (rs485_enabled) here ...
> ret = uart_add_one_port(_uart, >uart);
> if (ret)
> goto err_add_port;
> @@ -2574,7 +2572,7 @@ static int atmel_serial_probe(struct platform_device
> *pdev)
> device_init_wakeup(>dev, 1);
> platform_set_drvdata(pdev, port);
>
> - if (port->uart.rs485.flags & SER_RS485_ENABLED) {
> + if (rs485_enabled) {
> UART_PUT_MR(>uart, ATMEL_US_USMODE_NORMAL);
> UART_PUT_CR(>uart, ATMEL_US_RTSEN);
> }
... (this one ^^^) up where you can test the SER_RS485_ENABLED, can be
even simpler.
otherwise, it seems good so you can add my:
Acked-by: Nicolas Ferre
Thanks.
> diff --git a/drivers/tty/serial/mcf.c b/drivers/tty/serial/mcf.c
> index d7be1f1..fdd5c7b 100644
> --- a/drivers/tty/serial/mcf.c
> +++ b/drivers/tty/serial/mcf.c
> @@ -257,12 +257,12 @@ static void mcf_set_termios(struct uart_port *port,
> struct ktermios *termios,
> mr2 |= MCFUART_MR2_TXCTS;
> }
>
> + spin_lock_irqsave(>lock, flags);
> if (port->rs485.flags & SER_RS485_ENABLED) {
> dev_dbg(port->dev, "Setting UART to RS485\n");
> mr2 |= MCFUART_MR2_TXRTS;
> }
>
> - spin_lock_irqsave(>lock, flags);
> uart_update_timeout(port, termios->c_cflag, baud);
> writeb(MCFUART_UCR_CMDRESETRX, port->membase + MCFUART_UCR);
> writeb(MCFUART_UCR_CMDRESETTX, port->membase + MCFUART_UCR);
> @@ -442,10 +442,8 @@ static int mcf_verify_port(struct uart_port *port,
> struct serial_struct *ser)
> static int mcf_config_rs485(struct uart_port *port, struct serial_rs485
> *rs485)
> {
> struct mcf_uart *pp = container_of(port, struct mcf_uart, port);
> - unsigned long flags;
> unsigned char mr1, mr2;
>
> - spin_lock_irqsave(>lock, flags);
> /* Get mode registers */
> mr1 = readb(port->membase + MCFUART_UMR);
> mr2 = readb(port->membase + MCFUART_UMR);
> @@ -460,7 +458,6 @@ static int mcf_config_rs485(struct uart_port *port,
> struct serial_rs485 *rs485)
> writeb(mr1, port->membase + MCFUART_UMR);
> writeb(mr2, port->membase + MCFUART_UMR);
> port->rs485 = *rs485;
> - spin_unlock_irqrestore(>lock, flags);
>
> return 0;
> }
> diff --git a/drivers/tty/serial/omap-serial.c
> b/drivers/tty/serial/omap-serial.c
> index 9d4726f..6675dbf 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -1360,12 +1360,10 @@ static int
> serial_omap_config_rs485(struct uart_port *port, struct serial_rs485
> *rs485conf)
> {
> struct uart_omap_port *up = to_uart_omap_port(port);
> - unsigned long flags;
>
Re: fs/namei.c: Misuse of sequence counts?
Here's a patch for reference (untested):
diff --git a/fs/namei.c b/fs/namei.c
index a7b05bf..84704e4 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -649,17 +649,15 @@ static __always_inline void set_root(struct nameidata *nd)
static int link_path_walk(const char *, struct nameidata *);
-static __always_inline unsigned set_root_rcu(struct nameidata *nd)
+static __always_inline void set_root_rcu(struct nameidata *nd)
{
struct fs_struct *fs = current->fs;
- unsigned seq, res;
+ unsigned seq;
do {
seq = read_seqcount_begin(>seq);
nd->root = fs->root;
- res = __read_seqcount_begin(>root.dentry->d_seq);
} while (read_seqcount_retry(>seq, seq));
- return res;
}
static void path_put_conditional(struct path *path, struct nameidata *nd)
@@ -1854,11 +1852,21 @@ static int path_init(int dfd, const char *name,
unsigned int flags,
nd->m_seq = read_seqbegin(_lock);
if (*name=='/') {
if (flags & LOOKUP_RCU) {
+ struct fs_struct *fs = current->fs;
+ unsigned seq;
+
rcu_read_lock();
- nd->seq = set_root_rcu(nd);
+
+ do {
+ seq = read_seqcount_begin(>seq);
+ nd->root = fs->root;
+ nd->inode = nd->root.dentry->d_inode;
+ nd->seq =
__read_seqcount_begin(>root.dentry->d_seq);
+ } while (read_seqcount_retry(>seq, seq));
} else {
set_root(nd);
path_get(>root);
+ nd->inode = nd->root.dentry->d_inode;
}
nd->path = nd->root;
} else if (dfd == AT_FDCWD) {
@@ -1871,10 +1879,12 @@ static int path_init(int dfd, const char *name,
unsigned int flags,
do {
seq = read_seqcount_begin(>seq);
nd->path = fs->pwd;
+ nd->inode = nd->path.dentry->d_inode;
nd->seq =
__read_seqcount_begin(>path.dentry->d_seq);
} while (read_seqcount_retry(>seq, seq));
} else {
get_fs_pwd(current->fs, >path);
+ nd->inode = nd->path.dentry->d_inode;
}
} else {
/* Caller must check execute permissions on the starting path
component */
@@ -1894,6 +1904,7 @@ static int path_init(int dfd, const char *name, unsigned
int flags,
}
nd->path = f.file->f_path;
+ nd->inode = file_inode(f.file);
if (flags & LOOKUP_RCU) {
if (f.flags & FDPUT_FPUT)
*fp = f.file;
@@ -1904,16 +1915,7 @@ static int path_init(int dfd, const char *name, unsigned
int flags,
fdput(f);
}
}
-
- nd->inode = nd->path.dentry->d_inode;
- if (!(flags & LOOKUP_RCU))
- return 0;
- if (likely(!read_seqcount_retry(>path.dentry->d_seq, nd->seq)))
- return 0;
- if (!(nd->flags & LOOKUP_ROOT))
- nd->root.mnt = NULL;
- rcu_read_unlock();
- return -ECHILD;
+ return 0;
}
static inline int lookup_last(struct nameidata *nd, struct path *path)
--
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] drm: drm_err: Remove unnecessary __func__ argument
Removing the unnecessary drm_err __func__ argument by using
the equivalent %pf and __builtin_return_address(0) makes the
code smaller for every use of the DRM_ERROR macro.
For instance: (allmodconfig)
$ size drivers/gpu/drm/i915/i915.o*
textdata bss dec hex filename
922447 193257 296736 1412440 158d58 drivers/gpu/drm/i915/i915.o.new
928111 193257 296736 1418104 15a378 drivers/gpu/drm/i915/i915.o.old
Signed-off-by: Joe Perches
---
drivers/gpu/drm/drm_drv.c | 5 +++--
include/drm/drmP.h| 8
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 9f0e1b9..e9263d9 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -68,7 +68,7 @@ static struct idr drm_minors_idr;
struct class *drm_class;
static struct dentry *drm_debugfs_root;
-void drm_err(const char *func, const char *format, ...)
+void drm_err(const char *format, ...)
{
struct va_format vaf;
va_list args;
@@ -78,7 +78,8 @@ void drm_err(const char *func, const char *format, ...)
vaf.fmt = format;
vaf.va =
- printk(KERN_ERR "[" DRM_NAME ":%s] *ERROR* %pV", func, );
+ printk(KERN_ERR "[" DRM_NAME ":%pf] *ERROR* %pV",
+ __builtin_return_address(0), );
va_end(args);
}
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index ca374ac..5e9ff52 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -125,8 +125,8 @@ struct reservation_object;
extern __printf(2, 3)
void drm_ut_debug_printk(const char *function_name,
const char *format, ...);
-extern __printf(2, 3)
-void drm_err(const char *func, const char *format, ...);
+extern __printf(1, 2)
+void drm_err(const char *format, ...);
/***/
/** \name DRM template customization defaults */
@@ -168,7 +168,7 @@ void drm_err(const char *func, const char *format, ...);
* \param arg arguments
*/
#define DRM_ERROR(fmt, ...)\
- drm_err(__func__, fmt, ##__VA_ARGS__)
+ drm_err(fmt, ##__VA_ARGS__)
/**
* Rate limited error output. Like DRM_ERROR() but won't flood the log.
@@ -183,7 +183,7 @@ void drm_err(const char *func, const char *format, ...);
DEFAULT_RATELIMIT_BURST); \
\
if (__ratelimit(&_rs)) \
- drm_err(__func__, fmt, ##__VA_ARGS__); \
+ drm_err(fmt, ##__VA_ARGS__);\
})
#define DRM_INFO(fmt, ...) \
--
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 v9 06/12] mpx: extend siginfo structure to include bound violation information
This patch adds new fields about bound violation into siginfo
structure. si_lower and si_upper are respectively lower bound
and upper bound when bound violation is caused.
Signed-off-by: Qiaowei Ren
---
include/uapi/asm-generic/siginfo.h |9 -
kernel/signal.c|4
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/include/uapi/asm-generic/siginfo.h
b/include/uapi/asm-generic/siginfo.h
index ba5be7f..1e35520 100644
--- a/include/uapi/asm-generic/siginfo.h
+++ b/include/uapi/asm-generic/siginfo.h
@@ -91,6 +91,10 @@ typedef struct siginfo {
int _trapno;/* TRAP # which caused the signal */
#endif
short _addr_lsb; /* LSB of the reported address */
+ struct {
+ void __user *_lower;
+ void __user *_upper;
+ } _addr_bnd;
} _sigfault;
/* SIGPOLL */
@@ -131,6 +135,8 @@ typedef struct siginfo {
#define si_trapno _sifields._sigfault._trapno
#endif
#define si_addr_lsb_sifields._sigfault._addr_lsb
+#define si_lower _sifields._sigfault._addr_bnd._lower
+#define si_upper _sifields._sigfault._addr_bnd._upper
#define si_band_sifields._sigpoll._band
#define si_fd _sifields._sigpoll._fd
#ifdef __ARCH_SIGSYS
@@ -199,7 +205,8 @@ typedef struct siginfo {
*/
#define SEGV_MAPERR(__SI_FAULT|1) /* address not mapped to object */
#define SEGV_ACCERR(__SI_FAULT|2) /* invalid permissions for mapped
object */
-#define NSIGSEGV 2
+#define SEGV_BNDERR(__SI_FAULT|3) /* failed address bound checks */
+#define NSIGSEGV 3
/*
* SIGBUS si_codes
diff --git a/kernel/signal.c b/kernel/signal.c
index 8f0876f..2c403a4 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2748,6 +2748,10 @@ int copy_siginfo_to_user(siginfo_t __user *to, const
siginfo_t *from)
if (from->si_code == BUS_MCEERR_AR || from->si_code ==
BUS_MCEERR_AO)
err |= __put_user(from->si_addr_lsb, >si_addr_lsb);
#endif
+#ifdef SEGV_BNDERR
+ err |= __put_user(from->si_lower, >si_lower);
+ err |= __put_user(from->si_upper, >si_upper);
+#endif
break;
case __SI_CHLD:
err |= __put_user(from->si_pid, >si_pid);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 04/12] x86, mpx: add MPX to disaabled features
This allows us to use cpu_feature_enabled(X86_FEATURE_MPX) as both a runtime and compile-time check. When CONFIG_X86_INTEL_MPX is disabled, cpu_feature_enabled(X86_FEATURE_MPX) will evaluate at compile-time to 0. If CONFIG_X86_INTEL_MPX=y, then the cpuid flag will be checked at runtime. This patch must be applied after another Dave's commit: 381aa07a9b4e1f82969203e9e4863da2a157781d Signed-off-by: Dave Hansen Signed-off-by: Qiaowei Ren --- arch/x86/include/asm/disabled-features.h |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/arch/x86/include/asm/disabled-features.h b/arch/x86/include/asm/disabled-features.h index 97534a7..f226df0 100644 --- a/arch/x86/include/asm/disabled-features.h +++ b/arch/x86/include/asm/disabled-features.h @@ -10,6 +10,12 @@ * cpu_feature_enabled(). */ +#ifdef CONFIG_X86_INTEL_MPX +# define DISABLE_MPX 0 +#else +# define DISABLE_MPX (1<<(X86_FEATURE_MPX & 31)) +#endif + #ifdef CONFIG_X86_64 # define DISABLE_VME (1<<(X86_FEATURE_VME & 31)) # define DISABLE_K6_MTRR (1<<(X86_FEATURE_K6_MTRR & 31)) @@ -34,6 +40,6 @@ #define DISABLED_MASK6 0 #define DISABLED_MASK7 0 #define DISABLED_MASK8 0 -#define DISABLED_MASK9 0 +#define DISABLED_MASK9 (DISABLE_MPX) #endif /* _ASM_X86_DISABLED_FEATURES_H */ -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 07/12] mips: sync struct siginfo with general version
New fields about bound violation are added into general struct
siginfo. This will impact MIPS and IA64, which extend general
struct siginfo. This patch syncs this struct for MIPS with
general version.
Signed-off-by: Qiaowei Ren
---
arch/mips/include/uapi/asm/siginfo.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/mips/include/uapi/asm/siginfo.h
b/arch/mips/include/uapi/asm/siginfo.h
index e811744..d08f83f 100644
--- a/arch/mips/include/uapi/asm/siginfo.h
+++ b/arch/mips/include/uapi/asm/siginfo.h
@@ -92,6 +92,10 @@ typedef struct siginfo {
int _trapno;/* TRAP # which caused the signal */
#endif
short _addr_lsb;
+ struct {
+ void __user *_lower;
+ void __user *_upper;
+ } _addr_bnd;
} _sigfault;
/* SIGPOLL, SIGXFSZ (To do ...) */
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 05/12] x86, mpx: on-demand kernel allocation of bounds tables
MPX only has 4 hardware registers for storing bounds information.
If MPX-enabled code needs more than these 4 registers, it needs to
spill them somewhere. It has two special instructions for this
which allow the bounds to be moved between the bounds registers
and some new "bounds tables".
They are similar conceptually to a page fault and will be raised by
the MPX hardware during both bounds violations or when the tables
are not present. This patch handles those #BR exceptions for
not-present tables by carving the space out of the normal processes
address space (essentially calling the new mmap() interface indroduced
earlier in this patch set.) and then pointing the bounds-directory
over to it.
The tables *need* to be accessed and controlled by userspace because
the instructions for moving bounds in and out of them are extremely
frequent. They potentially happen every time a register pointing to
memory is dereferenced. Any direct kernel involvement (like a syscall)
to access the tables would obviously destroy performance.
Why not do this in userspace?
This patch is obviously doing this allocation in the kernel.
However, MPX does not strictly *require* anything in the kernel.
It can theoretically be done completely from userspace. Here are
a few ways this *could* be done. I don't think any of them are
practical in the real-world, but here they are.
Q: Can virtual space simply be reserved for the bounds tables so
that we never have to allocate them?
A: As noted earlier, these tables are *HUGE*. An X-GB virtual
area needs 4*X GB of virtual space, plus 2GB for the bounds
directory. If we were to preallocate them for the 128TB of
user virtual address space, we would need to reserve 512TB+2GB,
which is larger than the entire virtual address space today.
This means they can not be reserved ahead of time. Also, a
single process's pre-popualated bounds directory consumes 2GB
of virtual *AND* physical memory. IOW, it's completely
infeasible to prepopulate bounds directories.
Q: Can we preallocate bounds table space at the same time memory
is allocated which might contain pointers that might eventually
need bounds tables?
A: This would work if we could hook the site of each and every
memory allocation syscall. This can be done for small,
constrained applications. But, it isn't practical at a larger
scale since a given app has no way of controlling how all the
parts of the app might allocate memory (think libraries). The
kernel is really the only place to intercept these calls.
Q: Could a bounds fault be handed to userspace and the tables
allocated there in a signal handler instead of in the kernel?
A: (thanks to tglx) mmap() is not on the list of safe async
handler functions and even if mmap() would work it still
requires locking or nasty tricks to keep track of the
allocation state there.
Having ruled out all of the userspace-only approaches for managing
bounds tables that we could think of, we create them on demand in
the kernel.
Signed-off-by: Qiaowei Ren
---
arch/x86/include/asm/mpx.h | 20 +
arch/x86/kernel/Makefile |1 +
arch/x86/kernel/mpx.c | 101
arch/x86/kernel/traps.c| 52 ++-
4 files changed, 173 insertions(+), 1 deletions(-)
create mode 100644 arch/x86/kernel/mpx.c
diff --git a/arch/x86/include/asm/mpx.h b/arch/x86/include/asm/mpx.h
index 5725ac4..b7598ac 100644
--- a/arch/x86/include/asm/mpx.h
+++ b/arch/x86/include/asm/mpx.h
@@ -18,6 +18,8 @@
#define MPX_BT_ENTRY_SHIFT 5
#define MPX_IGN_BITS 3
+#define MPX_BD_ENTRY_TAIL 3
+
#else
#define MPX_BD_ENTRY_OFFSET20
@@ -26,13 +28,31 @@
#define MPX_BT_ENTRY_SHIFT 4
#define MPX_IGN_BITS 2
+#define MPX_BD_ENTRY_TAIL 2
+
#endif
+#define MPX_BNDSTA_TAIL2
+#define MPX_BNDCFG_TAIL12
+#define MPX_BNDSTA_ADDR_MASK (~((1UL<
+ * Dave Hansen
+ */
+
+#include
+#include
+#include
+
+/*
+ * With 32-bit mode, MPX_BT_SIZE_BYTES is 4MB, and the size of each
+ * bounds table is 16KB. With 64-bit mode, MPX_BT_SIZE_BYTES is 2GB,
+ * and the size of each bounds table is 4MB.
+ */
+static int allocate_bt(long __user *bd_entry)
+{
+ unsigned long bt_addr;
+ unsigned long expected_old_val = 0;
+ unsigned long actual_old_val = 0;
+ int ret = 0;
+
+ /*
+* Carve the virtual space out of userspace for the new
+* bounds table:
+*/
+ bt_addr = mpx_mmap(MPX_BT_SIZE_BYTES);
+ if (IS_ERR((void *)bt_addr))
+ return PTR_ERR((void *)bt_addr);
+ /*
+* Set the valid flag (kinda like _PAGE_PRESENT in a pte)
+*/
+ bt_addr = bt_addr | MPX_BD_ENTRY_VALID_FLAG;
+
+ /*
+* Go poke the address of the new bounds table in to the
+* bounds directory entry out in userspace memory. Note:
+* we may race with
[PATCH v9 03/12] x86, mpx: add MPX specific mmap interface
We have to do the allocation of bounds tables in kernel (See the patch
"on-demand kernel allocation of bounds tables"). Moreover, if we want
to track MPX VMAs we need to be able to stick new VM_MPX flag and a
specific vm_ops for MPX in the vma_area_struct.
But there are not suitable interfaces to do this in current kernel.
Existing interfaces, like do_mmap_pgoff(), could not stick specific
->vm_ops in the vma_area_struct when a VMA is created. So, this patch
adds MPX specific mmap interface to do the allocation of bounds tables.
Signed-off-by: Qiaowei Ren
---
arch/x86/Kconfig |4 ++
arch/x86/include/asm/mpx.h | 38 +
arch/x86/mm/Makefile |2 +
arch/x86/mm/mpx.c | 79
4 files changed, 123 insertions(+), 0 deletions(-)
create mode 100644 arch/x86/include/asm/mpx.h
create mode 100644 arch/x86/mm/mpx.c
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 4b663e1..e5bcc70 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -243,6 +243,10 @@ config HAVE_INTEL_TXT
def_bool y
depends on INTEL_IOMMU && ACPI
+config X86_INTEL_MPX
+ def_bool y
+ depends on CPU_SUP_INTEL
+
config X86_32_SMP
def_bool y
depends on X86_32 && SMP
diff --git a/arch/x86/include/asm/mpx.h b/arch/x86/include/asm/mpx.h
new file mode 100644
index 000..5725ac4
--- /dev/null
+++ b/arch/x86/include/asm/mpx.h
@@ -0,0 +1,38 @@
+#ifndef _ASM_X86_MPX_H
+#define _ASM_X86_MPX_H
+
+#include
+#include
+
+#ifdef CONFIG_X86_64
+
+/* upper 28 bits [47:20] of the virtual address in 64-bit used to
+ * index into bounds directory (BD).
+ */
+#define MPX_BD_ENTRY_OFFSET28
+#define MPX_BD_ENTRY_SHIFT 3
+/* bits [19:3] of the virtual address in 64-bit used to index into
+ * bounds table (BT).
+ */
+#define MPX_BT_ENTRY_OFFSET17
+#define MPX_BT_ENTRY_SHIFT 5
+#define MPX_IGN_BITS 3
+
+#else
+
+#define MPX_BD_ENTRY_OFFSET20
+#define MPX_BD_ENTRY_SHIFT 2
+#define MPX_BT_ENTRY_OFFSET10
+#define MPX_BT_ENTRY_SHIFT 4
+#define MPX_IGN_BITS 2
+
+#endif
+
+#define MPX_BD_SIZE_BYTES (1UL<<(MPX_BD_ENTRY_OFFSET+MPX_BD_ENTRY_SHIFT))
+#define MPX_BT_SIZE_BYTES (1UL<<(MPX_BT_ENTRY_OFFSET+MPX_BT_ENTRY_SHIFT))
+
+#define MPX_BNDSTA_ERROR_CODE 0x3
+
+unsigned long mpx_mmap(unsigned long len);
+
+#endif /* _ASM_X86_MPX_H */
diff --git a/arch/x86/mm/Makefile b/arch/x86/mm/Makefile
index 6a19ad9..ecfdc46 100644
--- a/arch/x86/mm/Makefile
+++ b/arch/x86/mm/Makefile
@@ -30,3 +30,5 @@ obj-$(CONFIG_ACPI_NUMA) += srat.o
obj-$(CONFIG_NUMA_EMU) += numa_emulation.o
obj-$(CONFIG_MEMTEST) += memtest.o
+
+obj-$(CONFIG_X86_INTEL_MPX)+= mpx.o
diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c
new file mode 100644
index 000..e1b28e6
--- /dev/null
+++ b/arch/x86/mm/mpx.c
@@ -0,0 +1,79 @@
+#include
+#include
+#include
+#include
+#include
+
+static const char *mpx_mapping_name(struct vm_area_struct *vma)
+{
+ return "[mpx]";
+}
+
+static struct vm_operations_struct mpx_vma_ops = {
+ .name = mpx_mapping_name,
+};
+
+/*
+ * this is really a simplified "vm_mmap". it only handles mpx
+ * related maps, including bounds table and bounds directory.
+ *
+ * here we can stick new vm_flag VM_MPX in the vma_area_struct
+ * when create a bounds table or bounds directory, in order to
+ * track MPX specific memory.
+ */
+unsigned long mpx_mmap(unsigned long len)
+{
+ unsigned long ret;
+ unsigned long addr, pgoff;
+ struct mm_struct *mm = current->mm;
+ vm_flags_t vm_flags;
+ struct vm_area_struct *vma;
+
+ /* Only bounds table and bounds directory can be allocated here */
+ if (len != MPX_BD_SIZE_BYTES && len != MPX_BT_SIZE_BYTES)
+ return -EINVAL;
+
+ down_write(>mmap_sem);
+
+ /* Too many mappings? */
+ if (mm->map_count > sysctl_max_map_count) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ /* Obtain the address to map to. we verify (or select) it and ensure
+* that it represents a valid section of the address space.
+*/
+ addr = get_unmapped_area(NULL, 0, len, 0, MAP_ANONYMOUS | MAP_PRIVATE);
+ if (addr & ~PAGE_MASK) {
+ ret = addr;
+ goto out;
+ }
+
+ vm_flags = VM_READ | VM_WRITE | VM_MPX |
+ mm->def_flags | VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC;
+
+ /* Set pgoff according to addr for anon_vma */
+ pgoff = addr >> PAGE_SHIFT;
+
+ ret = mmap_region(NULL, addr, len, vm_flags, pgoff);
+ if (IS_ERR_VALUE(ret))
+ goto out;
+
+ vma = find_vma(mm, ret);
+ if (!vma) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ vma->vm_ops = _vma_ops;
+
+ if (vm_flags & VM_LOCKED) {
+ up_write(>mmap_sem);
+ mm_populate(ret, len);
+ return
[PATCH v9 01/12] x86, mpx: introduce VM_MPX to indicate that a VMA is MPX specific
MPX-enabled applications using large swaths of memory can potentially have large numbers of bounds tables in process address space to save bounds information. These tables can take up huge swaths of memory (as much as 80% of the memory on the system) even if we clean them up aggressively. In the worst-case scenario, the tables can be 4x the size of the data structure being tracked. IOW, a 1-page structure can require 4 bounds-table pages. Being this huge, our expectation is that folks using MPX are going to be keen on figuring out how much memory is being dedicated to it. So we need a way to track memory use for MPX. If we want to specifically track MPX VMAs we need to be able to distinguish them from normal VMAs, and keep them from getting merged with normal VMAs. A new VM_ flag set only on MPX VMAs does both of those things. With this flag, MPX bounds-table VMAs can be distinguished from other VMAs, and userspace can also walk /proc/$pid/smaps to get memory usage for MPX. Except this flag, we also introduce a specific ->vm_ops for MPX VMAs (see the patch "add MPX specific mmap interface"), but currently vmas with different ->vm_ops could be not prevented from merging. We understand that VM_ flags are scarce and are open to other options. Signed-off-by: Qiaowei Ren --- fs/proc/task_mmu.c |1 + include/linux/mm.h |6 ++ 2 files changed, 7 insertions(+), 0 deletions(-) diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index dfc791c..cc31520 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -549,6 +549,7 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma) [ilog2(VM_GROWSDOWN)] = "gd", [ilog2(VM_PFNMAP)] = "pf", [ilog2(VM_DENYWRITE)] = "dw", + [ilog2(VM_MPX)] = "mp", [ilog2(VM_LOCKED)] = "lo", [ilog2(VM_IO)] = "io", [ilog2(VM_SEQ_READ)]= "sr", diff --git a/include/linux/mm.h b/include/linux/mm.h index 8981cc8..942be8a 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -127,6 +127,7 @@ extern unsigned int kobjsize(const void *objp); #define VM_HUGETLB 0x0040 /* Huge TLB Page VM */ #define VM_NONLINEAR 0x0080 /* Is non-linear (remap_file_pages) */ #define VM_ARCH_1 0x0100 /* Architecture-specific flag */ +#define VM_ARCH_2 0x0200 #define VM_DONTDUMP0x0400 /* Do not include in the core dump */ #ifdef CONFIG_MEM_SOFT_DIRTY @@ -154,6 +155,11 @@ extern unsigned int kobjsize(const void *objp); # define VM_MAPPED_COPYVM_ARCH_1 /* T if mapped copy of data (nommu mmap) */ #endif +#if defined(CONFIG_X86) +/* MPX specific bounds table or bounds directory */ +# define VM_MPXVM_ARCH_2 +#endif + #ifndef VM_GROWSUP # define VM_GROWSUPVM_NONE #endif -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 08/12] ia64: sync struct siginfo with general version
New fields about bound violation are added into general struct
siginfo. This will impact MIPS and IA64, which extend general
struct siginfo. This patch syncs this struct for IA64 with
general version.
Signed-off-by: Qiaowei Ren
---
arch/ia64/include/uapi/asm/siginfo.h |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/ia64/include/uapi/asm/siginfo.h
b/arch/ia64/include/uapi/asm/siginfo.h
index 4ea6225..bce9bc1 100644
--- a/arch/ia64/include/uapi/asm/siginfo.h
+++ b/arch/ia64/include/uapi/asm/siginfo.h
@@ -63,6 +63,10 @@ typedef struct siginfo {
unsigned int _flags;/* see below */
unsigned long _isr; /* isr */
short _addr_lsb;/* lsb of faulting address */
+ struct {
+ void __user *_lower;
+ void __user *_upper;
+ } _addr_bnd;
} _sigfault;
/* SIGPOLL */
@@ -110,9 +114,9 @@ typedef struct siginfo {
/*
* SIGSEGV si_codes
*/
-#define __SEGV_PSTKOVF (__SI_FAULT|3) /* paragraph stack overflow */
+#define __SEGV_PSTKOVF (__SI_FAULT|4) /* paragraph stack overflow */
#undef NSIGSEGV
-#define NSIGSEGV 3
+#define NSIGSEGV 4
#undef NSIGTRAP
#define NSIGTRAP 4
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 12/12] x86, mpx: add documentation on Intel MPX
This patch adds the Documentation/x86/intel_mpx.txt file with some information about Intel MPX. Signed-off-by: Qiaowei Ren --- Documentation/x86/intel_mpx.txt | 245 +++ 1 files changed, 245 insertions(+), 0 deletions(-) create mode 100644 Documentation/x86/intel_mpx.txt diff --git a/Documentation/x86/intel_mpx.txt b/Documentation/x86/intel_mpx.txt new file mode 100644 index 000..3c20a17 --- /dev/null +++ b/Documentation/x86/intel_mpx.txt @@ -0,0 +1,245 @@ +1. Intel(R) MPX Overview + + +Intel(R) Memory Protection Extensions (Intel(R) MPX) is a new capability +introduced into Intel Architecture. Intel MPX provides hardware features +that can be used in conjunction with compiler changes to check memory +references, for those references whose compile-time normal intentions are +usurped at runtime due to buffer overflow or underflow. + +For more information, please refer to Intel(R) Architecture Instruction +Set Extensions Programming Reference, Chapter 9: Intel(R) Memory Protection +Extensions. + +Note: Currently no hardware with MPX ISA is available but it is always +possible to use SDE (Intel(R) Software Development Emulator) instead, which +can be downloaded from +http://software.intel.com/en-us/articles/intel-software-development-emulator + + +2. How to get the advantage of MPX +== + +For MPX to work, changes are required in the kernel, binutils and compiler. +No source changes are required for applications, just a recompile. + +There are a lot of moving parts of this to all work right. The following +is how we expect the compiler, application and kernel to work together. + +1) Application developer compiles with -fmpx. The compiler will add the + instrumentation as well as some setup code called early after the app + starts. New instruction prefixes are noops for old CPUs. +2) That setup code allocates (virtual) space for the "bounds directory", + points the "bndcfgu" register to the directory and notifies the kernel + (via the new prctl(PR_MPX_ENABLE_MANAGEMENT)) that the app will be using + MPX. +3) The kernel detects that the CPU has MPX, allows the new prctl() to + succeed, and notes the location of the bounds directory. Userspace is + expected to keep the bounds directory at that locationWe note it + instead of reading it each time because the 'xsave' operation needed + to access the bounds directory register is an expensive operation. +4) If the application needs to spill bounds out of the 4 registers, it + issues a bndstx instruction. Since the bounds directory is empty at + this point, a bounds fault (#BR) is raised, the kernel allocates a + bounds table (in the user address space) and makes the relevant entry + in the bounds directory point to the new table. +5) If the application violates the bounds specified in the bounds registers, + a separate kind of #BR is raised which will deliver a signal with + information about the violation in the 'struct siginfo'. +6) Whenever memory is freed, we know that it can no longer contain valid + pointers, and we attempt to free the associated space in the bounds + tables. If an entire table becomes unused, we will attempt to free + the table and remove the entry in the directory. + +To summarize, there are essentially three things interacting here: + +GCC with -fmpx: + * enables annotation of code with MPX instructions and prefixes + * inserts code early in the application to call in to the "gcc runtime" +GCC MPX Runtime: + * Checks for hardware MPX support in cpuid leaf + * allocates virtual space for the bounds directory (malloc() essentially) + * points the hardware BNDCFGU register at the directory + * calls a new prctl(PR_MPX_ENABLE_MANAGEMENT) to notify the kernel to + start managing the bounds directories +Kernel MPX Code: + * Checks for hardware MPX support in cpuid leaf + * Handles #BR exceptions and sends SIGSEGV to the app when it violates + bounds, like during a buffer overflow. + * When bounds are spilled in to an unallocated bounds table, the kernel + notices in the #BR exception, allocates the virtual space, then + updates the bounds directory to point to the new table. It keeps + special track of the memory with a VM_MPX flag. + * Frees unused bounds tables at the time that the memory they described + is unmapped. + + +3. How does MPX kernel code work + + +Handling #BR faults caused by MPX +- + +When MPX is enabled, there are 2 new situations that can generate +#BR faults. + * new bounds tables (BT) need to be allocated to save bounds. + * bounds violation caused by MPX instructions. + +We hook #BR handler to handle these two new situations. + +On-demand kernel allocation of bounds tables + + +MPX only has 4 hardware registers for storing bounds information. If +MPX-enabled code needs
[PATCH v9 09/12] x86, mpx: decode MPX instruction to get bound violation information
This patch sets bound violation fields of siginfo struct in #BR
exception handler by decoding the user instruction and constructing
the faulting pointer.
This patch does't use the generic decoder, and implements a limited
special-purpose decoder to decode MPX instructions, simply because the
generic decoder is very heavyweight not just in terms of performance
but in terms of interface -- because it has to.
Signed-off-by: Qiaowei Ren
---
arch/x86/include/asm/mpx.h | 23
arch/x86/kernel/mpx.c | 299
arch/x86/kernel/traps.c|6 +
3 files changed, 328 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/mpx.h b/arch/x86/include/asm/mpx.h
index b7598ac..780af63 100644
--- a/arch/x86/include/asm/mpx.h
+++ b/arch/x86/include/asm/mpx.h
@@ -3,6 +3,7 @@
#include
#include
+#include
#ifdef CONFIG_X86_64
@@ -44,15 +45,37 @@
#define MPX_BNDSTA_ERROR_CODE 0x3
#define MPX_BD_ENTRY_VALID_FLAG0x1
+struct mpx_insn {
+ struct insn_field rex_prefix; /* REX prefix */
+ struct insn_field modrm;
+ struct insn_field sib;
+ struct insn_field displacement;
+
+ unsigned char addr_bytes; /* effective address size */
+ unsigned char limit;
+ unsigned char x86_64;
+
+ const unsigned char *kaddr; /* kernel address of insn to analyze */
+ const unsigned char *next_byte;
+};
+
+#define MAX_MPX_INSN_SIZE 15
+
unsigned long mpx_mmap(unsigned long len);
#ifdef CONFIG_X86_INTEL_MPX
int do_mpx_bt_fault(struct xsave_struct *xsave_buf);
+void do_mpx_bounds(struct pt_regs *regs, siginfo_t *info,
+ struct xsave_struct *xsave_buf);
#else
static inline int do_mpx_bt_fault(struct xsave_struct *xsave_buf)
{
return -EINVAL;
}
+static inline void do_mpx_bounds(struct pt_regs *regs, siginfo_t *info,
+ struct xsave_struct *xsave_buf)
+{
+}
#endif /* CONFIG_X86_INTEL_MPX */
#endif /* _ASM_X86_MPX_H */
diff --git a/arch/x86/kernel/mpx.c b/arch/x86/kernel/mpx.c
index 2103b5e..b7e4c0e 100644
--- a/arch/x86/kernel/mpx.c
+++ b/arch/x86/kernel/mpx.c
@@ -10,6 +10,275 @@
#include
#include
+enum reg_type {
+ REG_TYPE_RM = 0,
+ REG_TYPE_INDEX,
+ REG_TYPE_BASE,
+};
+
+static unsigned long get_reg(struct mpx_insn *insn, struct pt_regs *regs,
+enum reg_type type)
+{
+ int regno = 0;
+ unsigned char modrm = (unsigned char)insn->modrm.value;
+ unsigned char sib = (unsigned char)insn->sib.value;
+
+ static const int regoff[] = {
+ offsetof(struct pt_regs, ax),
+ offsetof(struct pt_regs, cx),
+ offsetof(struct pt_regs, dx),
+ offsetof(struct pt_regs, bx),
+ offsetof(struct pt_regs, sp),
+ offsetof(struct pt_regs, bp),
+ offsetof(struct pt_regs, si),
+ offsetof(struct pt_regs, di),
+#ifdef CONFIG_X86_64
+ offsetof(struct pt_regs, r8),
+ offsetof(struct pt_regs, r9),
+ offsetof(struct pt_regs, r10),
+ offsetof(struct pt_regs, r11),
+ offsetof(struct pt_regs, r12),
+ offsetof(struct pt_regs, r13),
+ offsetof(struct pt_regs, r14),
+ offsetof(struct pt_regs, r15),
+#endif
+ };
+
+ switch (type) {
+ case REG_TYPE_RM:
+ regno = X86_MODRM_RM(modrm);
+ if (X86_REX_B(insn->rex_prefix.value) == 1)
+ regno += 8;
+ break;
+
+ case REG_TYPE_INDEX:
+ regno = X86_SIB_INDEX(sib);
+ if (X86_REX_X(insn->rex_prefix.value) == 1)
+ regno += 8;
+ break;
+
+ case REG_TYPE_BASE:
+ regno = X86_SIB_BASE(sib);
+ if (X86_REX_B(insn->rex_prefix.value) == 1)
+ regno += 8;
+ break;
+
+ default:
+ break;
+ }
+
+ return regs_get_register(regs, regoff[regno]);
+}
+
+/*
+ * return the address being referenced be instruction
+ * for rm=3 returning the content of the rm reg
+ * for rm!=3 calculates the address using SIB and Disp
+ */
+static unsigned long get_addr_ref(struct mpx_insn *insn, struct pt_regs *regs)
+{
+ unsigned long addr;
+ unsigned long base;
+ unsigned long indx;
+ unsigned char modrm = (unsigned char)insn->modrm.value;
+ unsigned char sib = (unsigned char)insn->sib.value;
+
+ if (X86_MODRM_MOD(modrm) == 3) {
+ addr = get_reg(insn, regs, REG_TYPE_RM);
+ } else {
+ if (insn->sib.nbytes) {
+ base = get_reg(insn, regs, REG_TYPE_BASE);
+ indx = get_reg(insn, regs, REG_TYPE_INDEX);
+ addr = base + indx * (1 << X86_SIB_SCALE(sib));
+ } else {
+ addr = get_reg(insn,
[PATCH v9 11/12] x86, mpx: cleanup unused bound tables
There are two mappings in play: 1. The mapping with the actual data,
which userspace is munmap()ing or brk()ing away, etc... 2. The mapping
for the bounds table *backing* the data (is tagged with mpx_vma_ops,
see the patch "add MPX specific mmap interface").
If userspace use the prctl() indroduced earlier in this patchset to
enable the management of bounds tables in kernel, when it unmaps the
first kind of mapping with the actual data, kernel needs to free the
mapping for the bounds table backing the data. This patch calls
arch_unmap() at the very end of do_unmap() to do so. This will walk
the directory to look at the entries covered in the data vma and unmaps
the bounds table which is referenced from the directory and then clears
the directory entry.
Unmapping of bounds tables is called under vm_munmap() of the data VMA.
So we have to check ->vm_ops to prevent recursion. This recursion represents
having bounds tables for bounds tables, which should not occur normally.
Being strict about it here helps ensure that we do not have an exploitable
stack overflow.
Once we unmap the bounds table, we would have a bounds directory entry
pointing at empty address space. That address space could now be allocated
for some other (random) use, and the MPX hardware is now going to go
trying to walk it as if it were a bounds table. That would be bad. So
any unmapping of a bounds table has to be accompanied by a corresponding
write to the bounds directory entry to have it invalid. That write to
the bounds directory can fault.
Since we are doing the freeing from munmap() (and other paths like it),
we hold mmap_sem for write. If we fault, the page fault handler will
attempt to acquire mmap_sem for read and we will deadlock. For now, to
avoid deadlock, we disable page faults while touching the bounds directory
entry. This keeps us from being able to free the tables in this case.
This deficiency will be addressed in later patches.
Signed-off-by: Qiaowei Ren
---
arch/x86/include/asm/mmu_context.h | 16 ++
arch/x86/include/asm/mpx.h |9 +
arch/x86/mm/mpx.c | 317
include/asm-generic/mmu_context.h |6 +
mm/mmap.c |2 +
5 files changed, 350 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/mmu_context.h
b/arch/x86/include/asm/mmu_context.h
index e33ddb7..2b52d1b 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -111,4 +111,20 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm,
#endif
}
+static inline void arch_unmap(struct mm_struct *mm,
+ struct vm_area_struct *vma,
+ unsigned long start, unsigned long end)
+{
+#ifdef CONFIG_X86_INTEL_MPX
+ /*
+* Userspace never asked us to manage the bounds tables,
+* so refuse to help.
+*/
+ if (!kernel_managing_mpx_tables(current->mm))
+ return;
+
+ mpx_notify_unmap(mm, vma, start, end);
+#endif
+}
+
#endif /* _ASM_X86_MMU_CONTEXT_H */
diff --git a/arch/x86/include/asm/mpx.h b/arch/x86/include/asm/mpx.h
index 32f13f5..a1a0155 100644
--- a/arch/x86/include/asm/mpx.h
+++ b/arch/x86/include/asm/mpx.h
@@ -48,6 +48,13 @@
#define MPX_BD_SIZE_BYTES (1UL<<(MPX_BD_ENTRY_OFFSET+MPX_BD_ENTRY_SHIFT))
#define MPX_BT_SIZE_BYTES (1UL<<(MPX_BT_ENTRY_OFFSET+MPX_BT_ENTRY_SHIFT))
+#define MPX_BD_ENTRY_MASK ((1<>(MPX_BT_ENTRY_OFFSET+ \
+ MPX_IGN_BITS)) & MPX_BD_ENTRY_MASK) << MPX_BD_ENTRY_SHIFT)
+#define MPX_GET_BT_ENTRY_OFFSET(addr) addr)>>MPX_IGN_BITS) & \
+ MPX_BT_ENTRY_MASK) << MPX_BT_ENTRY_SHIFT)
+
#define MPX_BNDSTA_ERROR_CODE 0x3
#define MPX_BNDCFG_ENABLE_FLAG 0x1
#define MPX_BD_ENTRY_VALID_FLAG0x1
@@ -73,6 +80,8 @@ static inline int kernel_managing_mpx_tables(struct mm_struct
*mm)
return (mm->bd_addr != MPX_INVALID_BOUNDS_DIR);
}
unsigned long mpx_mmap(unsigned long len);
+void mpx_notify_unmap(struct mm_struct *mm, struct vm_area_struct *vma,
+ unsigned long start, unsigned long end);
#ifdef CONFIG_X86_INTEL_MPX
int do_mpx_bt_fault(struct xsave_struct *xsave_buf);
diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c
index 376f2ee..dcc6621 100644
--- a/arch/x86/mm/mpx.c
+++ b/arch/x86/mm/mpx.c
@@ -1,7 +1,16 @@
+/*
+ * mpx.c - Memory Protection eXtensions
+ *
+ * Copyright (c) 2014, Intel Corporation.
+ * Qiaowei Ren
+ * Dave Hansen
+ */
+
#include
#include
#include
#include
+#include
#include
static const char *mpx_mapping_name(struct vm_area_struct *vma)
@@ -13,6 +22,11 @@ static struct vm_operations_struct mpx_vma_ops = {
.name = mpx_mapping_name,
};
+int is_mpx_vma(struct vm_area_struct *vma)
+{
+ return (vma->vm_ops == _vma_ops);
+}
+
/*
* this is really a simplified "vm_mmap". it only handles mpx
* related maps, including bounds table and bounds directory.
@@ -66,3 +80,306 @@ unsigned long mpx_mmap(unsigned long len)
[PATCH v9 10/12] x86, mpx: add prctl commands PR_MPX_ENABLE_MANAGEMENT, PR_MPX_DISABLE_MANAGEMENT
This patch adds two prctl() commands to provide one explicit interaction
mechanism to enable or disable the management of bounds tables in kernel,
including on-demand kernel allocation (See the patch "on-demand kernel
allocation of bounds tables") and cleanup (See the patch "cleanup unused
bound tables"). Applications do not strictly need the kernel to manage
bounds tables and we expect some applications to use MPX without taking
advantage of the kernel support. This means the kernel can not simply
infer whether an application needs bounds table management from the
MPX registers. prctl() is an explicit signal from userspace.
PR_MPX_ENABLE_MANAGEMENT is meant to be a signal from userspace to
require kernel's help in managing bounds tables. And
PR_MPX_DISABLE_MANAGEMENT is the opposite, meaning that userspace don't
want kernel's help any more. With PR_MPX_DISABLE_MANAGEMENT, kernel
won't allocate and free the bounds table, even if the CPU supports MPX
feature.
PR_MPX_ENABLE_MANAGEMENT will do an xsave and fetch the base address
of bounds directory from the xsave buffer and then cache it into new
filed "bd_addr" of struct mm_struct. PR_MPX_DISABLE_MANAGEMENT will
set "bd_addr" to one invalid address. Then we can check "bd_addr" to
judge whether the management of bounds tables in kernel is enabled.
xsaves are expensive, so "bd_addr" is kept for caching to reduce the
number of we have to do at munmap() time. But we still have to do
xsave to get the value of BNDSTATUS at #BR fault time. In addition,
with this caching, userspace can't just move the bounds directory
around willy-nilly. For sane applications, base address of the bounds
directory won't be changed, otherwise we would be in a world of hurt.
But we will still check whether it is changed by users at #BR fault
time.
Signed-off-by: Qiaowei Ren
---
arch/x86/include/asm/mmu_context.h |9
arch/x86/include/asm/mpx.h | 11 +
arch/x86/include/asm/processor.h | 18 +++
arch/x86/kernel/mpx.c | 88
arch/x86/kernel/setup.c|8 +++
arch/x86/kernel/traps.c| 30 -
arch/x86/mm/mpx.c | 25 +++---
fs/exec.c |2 +
include/asm-generic/mmu_context.h |5 ++
include/linux/mm_types.h |3 +
include/uapi/linux/prctl.h |6 +++
kernel/sys.c | 12 +
12 files changed, 198 insertions(+), 19 deletions(-)
diff --git a/arch/x86/include/asm/mmu_context.h
b/arch/x86/include/asm/mmu_context.h
index 166af2a..e33ddb7 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#ifndef CONFIG_PARAVIRT
#include
@@ -102,4 +103,12 @@ do { \
} while (0)
#endif
+static inline void arch_bprm_mm_init(struct mm_struct *mm,
+ struct vm_area_struct *vma)
+{
+#ifdef CONFIG_X86_INTEL_MPX
+ mm->bd_addr = MPX_INVALID_BOUNDS_DIR;
+#endif
+}
+
#endif /* _ASM_X86_MMU_CONTEXT_H */
diff --git a/arch/x86/include/asm/mpx.h b/arch/x86/include/asm/mpx.h
index 780af63..32f13f5 100644
--- a/arch/x86/include/asm/mpx.h
+++ b/arch/x86/include/asm/mpx.h
@@ -5,6 +5,12 @@
#include
#include
+/*
+ * NULL is theoretically a valid place to put the bounds
+ * directory, so point this at an invalid address.
+ */
+#define MPX_INVALID_BOUNDS_DIR ((void __user *)-1)
+
#ifdef CONFIG_X86_64
/* upper 28 bits [47:20] of the virtual address in 64-bit used to
@@ -43,6 +49,7 @@
#define MPX_BT_SIZE_BYTES (1UL<<(MPX_BT_ENTRY_OFFSET+MPX_BT_ENTRY_SHIFT))
#define MPX_BNDSTA_ERROR_CODE 0x3
+#define MPX_BNDCFG_ENABLE_FLAG 0x1
#define MPX_BD_ENTRY_VALID_FLAG0x1
struct mpx_insn {
@@ -61,6 +68,10 @@ struct mpx_insn {
#define MAX_MPX_INSN_SIZE 15
+static inline int kernel_managing_mpx_tables(struct mm_struct *mm)
+{
+ return (mm->bd_addr != MPX_INVALID_BOUNDS_DIR);
+}
unsigned long mpx_mmap(unsigned long len);
#ifdef CONFIG_X86_INTEL_MPX
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 020142f..b35aefa 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -953,6 +953,24 @@ extern void start_thread(struct pt_regs *regs, unsigned
long new_ip,
extern int get_tsc_mode(unsigned long adr);
extern int set_tsc_mode(unsigned int val);
+/* Register/unregister a process' MPX related resource */
+#define MPX_ENABLE_MANAGEMENT(tsk) mpx_enable_management((tsk))
+#define MPX_DISABLE_MANAGEMENT(tsk)mpx_disable_management((tsk))
+
+#ifdef CONFIG_X86_INTEL_MPX
+extern int mpx_enable_management(struct task_struct *tsk);
+extern int mpx_disable_management(struct task_struct *tsk);
+#else
+static inline int mpx_enable_management(struct task_struct *tsk)
+{
+ return -EINVAL;
+}
+static inline int mpx_disable_management(struct
Re: fs/namei.c: Misuse of sequence counts?
On Sun, Oct 12, 2014 at 05:37:37AM +0100, Al Viro wrote: > > Gets clumsy in set_root_rcu() - you do *not* want it to bugger nd->inode > when done by follow_dotdot_rcu(), so we'd need either some indication which > caller it is, or something like struct inode **inode in argument list, > with NULL passed from follow_dotdot_rcu(), while path_init() would give > it >inode... > > Doable, but unpleasant. And the price of that check is trivial - after all, > in case we *don't* bugger off immediately, we have that ->d_seq in cache - > we'd fetched it just before. Or set_root_rcu() can be hand-inlined, like the AT_FDCWD case. Then the only caller of set_root_rcu() would be follow_dotdot_rcu(), and the unnecessary __read_seqcount_begin() could be removed. (Probably gcc can't optimize it out currently, because of the ACCESS_ONCE().) -- 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 v9 00/12] Intel MPX support
This patch set adds support for the Memory Protection eXtensions (MPX) feature found in future Intel processors. MPX is used in conjunction with compiler changes to check memory references, and can be used to catch buffer overflow or underflow. For MPX to work, changes are required in the kernel, binutils and compiler. No source changes are required for applications, just a recompile. There are a lot of moving parts of this to all work right: = Example Compiler / Application / Kernel Interaction = 1. Application developer compiles with -fmpx. The compiler will add the instrumentation as well as some setup code called early after the app starts. New instruction prefixes are noops for old CPUs. 2. That setup code allocates (virtual) space for the "bounds directory", points the "bndcfgu" register to the directory and notifies the kernel (via the new prctl(PR_MPX_ENABLE_MANAGEMENT)) that the app will be using MPX. 3. The kernel detects that the CPU has MPX, allows the new prctl() to succeed, and notes the location of the bounds directory. Userspace is expected to keep the bounds directory at that location. We note it instead of reading it each time because the 'xsave' operation needed to access the bounds directory register is an expensive operation. 4. If the application needs to spill bounds out of the 4 registers, it issues a bndstx instruction. Since the bounds directory is empty at this point, a bounds fault (#BR) is raised, the kernel allocates a bounds table (in the user address space) and makes the relevant entry in the bounds directory point to the new table. [1] 5. If the application violates the bounds specified in the bounds registers, a separate kind of #BR is raised which will deliver a signal with information about the violation in the 'struct siginfo'. 6. Whenever memory is freed, we know that it can no longer contain valid pointers, and we attempt to free the associated space in the bounds tables. If an entire table becomes unused, we will attempt to free the table and remove the entry in the directory. To summarize, there are essentially three things interacting here: GCC with -fmpx: * enables annotation of code with MPX instructions and prefixes * inserts code early in the application to call in to the "gcc runtime" GCC MPX Runtime: * Checks for hardware MPX support in cpuid leaf * allocates virtual space for the bounds directory (malloc() essentially) * points the hardware BNDCFGU register at the directory * calls a new prctl() to notify the kernel to start managing the bounds directories Kernel MPX Code: * Checks for hardware MPX support in cpuid leaf * Handles #BR exceptions and sends SIGSEGV to the app when it violates bounds, like during a buffer overflow. * When bounds are spilled in to an unallocated bounds table, the kernel notices in the #BR exception, allocates the virtual space, then updates the bounds directory to point to the new table. It keeps special track of the memory with a specific ->vm_ops for MPX. * Frees unused bounds tables at the time that the memory they described is unmapped. (See "cleanup unused bound tables") = Testing = This patchset has been tested on real internal hardware platform at Intel. We have some simple unit tests in user space, which directly call MPX instructions to produce #BR to let kernel allocate bounds tables and cause bounds violations. We also compiled several benchmarks with an MPX-enabled compiler and ran them with this patch set. We found a number of bugs in this code in these tests. 1. For more info on why the kernel does these allocations, see the patch "on-demand kernel allocation of bounds tables" Future TODO items: 1) support 32-bit binaries on 64-bit kernels. Changes since v1: * check to see if #BR occurred in userspace or kernel space. * use generic structure and macro as much as possible when decode mpx instructions. Changes since v2: * fix some compile warnings. * update documentation. Changes since v3: * correct some syntax errors at documentation, and document extended struct siginfo. * for kill the process when the error code of BNDSTATUS is 3. * add some comments. * remove new prctl() commands. * fix some compile warnings for 32-bit. Changes since v4: * raise SIGBUS if the allocations of the bound tables fail. Changes since v5: * hook unmap() path to cleanup unused bounds tables, and use new prctl() command to register bounds directory address to struct mm_struct to check whether one process is MPX enabled during unmap(). * in order track precisely MPX memory usage, add MPX specific mmap interface and one VM_MPX flag to check whether a VMA is MPX bounds table. * add macro cpu_has_mpx to do performance optimization. * sync struct figinfo for mips with general version to avoid build issue. Changes since v6: * because arch_vma_name is removed, this
[PATCH v9 02/12] x86, mpx: rename cfg_reg_u and status_reg
According to Intel SDM extension, MPX configuration and status registers
should be BNDCFGU and BNDSTATUS. This patch renames cfg_reg_u and
status_reg to bndcfgu and bndstatus.
Signed-off-by: Qiaowei Ren
---
arch/x86/include/asm/processor.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index eb71ec7..020142f 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -379,8 +379,8 @@ struct bndregs_struct {
} __packed;
struct bndcsr_struct {
- u64 cfg_reg_u;
- u64 status_reg;
+ u64 bndcfgu;
+ u64 bndstatus;
} __packed;
struct xsave_hdr_struct {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: fs/namei.c: Misuse of sequence counts?
On Sat, Oct 11, 2014 at 11:01:42PM -0500, Eric Biggers wrote: > On Sun, Oct 12, 2014 at 01:12:59AM +0100, Al Viro wrote: > > > > Huh? What's to guarantee that dentry hasn't become negative since the > > moment we'd fetched the seqcount? _That_ is the problem we are dealing > > with here - link_path_walk() relies on nd->inode being non-NULL. > > Hmm, I guess that makes sense. So the code is actually verifying that the > inode > is still the inode that was referenced from the current or root directory when > nd->path was set. But couldn't the problem also be solved by setting > nd->inode > directly in the fs->seq retry loops? Gets clumsy in set_root_rcu() - you do *not* want it to bugger nd->inode when done by follow_dotdot_rcu(), so we'd need either some indication which caller it is, or something like struct inode **inode in argument list, with NULL passed from follow_dotdot_rcu(), while path_init() would give it >inode... Doable, but unpleasant. And the price of that check is trivial - after all, in case we *don't* bugger off immediately, we have that ->d_seq in cache - we'd fetched it just before. -- 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: fs/namei.c: Misuse of sequence counts?
On Sat, Oct 11, 2014 at 10:55:10PM -0500, Eric Biggers wrote: > On Sun, Oct 12, 2014 at 12:46:35AM +0100, Al Viro wrote: > > > > Nope. What we do is > > * pick parent inode and seqcount (in whatever order) > > * THEN check that child is still unchanged. > > The second part guarantees that parent dentry had been the parent of > > child all along, since the moment we'd first fetched _child's_ seqcount. > > And since a pinned positive dentry can't have its ->d_inode changed, > > we know that the value of parent's inode we'd fetched remained valid > > at least until we'd checked the child's seqcount and found it unchanged. > > Which means that we had it valid at some point after we'd fetched parent's > > seqcount. > > Ah, very tricky. And I take it that the other two fetches of d_inode in > follow_dotdot_rcu() can likewise be unordered with respect to > read_seqcount_begin(), because the underlying dentries are pinned as either > mnt_mountpoint or mnt_root --- which in RCU mode, is only guaranteed because > of > the call to synchronize_rcu() in namespace_unlock() prior to dropping > references? The last one is actually covered by read_seqretry(_lock, nd->m_seq) - if it still matches, we know that whatever we got from __lookup_mnt() must have been valid through fetching ->d_inode and ->d_seq of its mnt_root. Which means that those two are consistent regardless of that synchronize_rcu(). The one before it would probably be better off with similar check on mount_lock as well. That code *is* correct for the reason you've mentioned, but I wonder if explicit check of mount_lock would be better - right now it's more subtle than I'd like it to be. I don't think the cost would be noticable - it's smp_rmb() + fetch + comparison when we cross a mountpoint while following .. in lazy pathwalk, but that needs profiling - handwaving is not good enough... -- 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: fs/namei.c: Misuse of sequence counts?
On Sun, Oct 12, 2014 at 01:12:59AM +0100, Al Viro wrote: > > Huh? What's to guarantee that dentry hasn't become negative since the > moment we'd fetched the seqcount? _That_ is the problem we are dealing > with here - link_path_walk() relies on nd->inode being non-NULL. Hmm, I guess that makes sense. So the code is actually verifying that the inode is still the inode that was referenced from the current or root directory when nd->path was set. But couldn't the problem also be solved by setting nd->inode directly in the fs->seq retry loops? (The file descriptor case could be 'nd->inode = file_inode(f.file);'.) Then there would be no need for the extra read_seqcount_retry() just for the inode. The patch you posted looks correct, but I wonder if this approach would be better. -- 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: fs/namei.c: Misuse of sequence counts?
On Sun, Oct 12, 2014 at 12:46:35AM +0100, Al Viro wrote: > > Nope. What we do is > * pick parent inode and seqcount (in whatever order) > * THEN check that child is still unchanged. > The second part guarantees that parent dentry had been the parent of > child all along, since the moment we'd first fetched _child's_ seqcount. > And since a pinned positive dentry can't have its ->d_inode changed, > we know that the value of parent's inode we'd fetched remained valid > at least until we'd checked the child's seqcount and found it unchanged. > Which means that we had it valid at some point after we'd fetched parent's > seqcount. Ah, very tricky. And I take it that the other two fetches of d_inode in follow_dotdot_rcu() can likewise be unordered with respect to read_seqcount_begin(), because the underlying dentries are pinned as either mnt_mountpoint or mnt_root --- which in RCU mode, is only guaranteed because of the call to synchronize_rcu() in namespace_unlock() prior to dropping references? -- 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: hfsplus: invalid memory access in hfsplus_brec_lenoff
On Sat, 2014-10-11 at 23:04 -0400, Sasha Levin wrote: > Hi all, > > While fuzzing with trinity inside a KVM tools guest running the latest -next > kernel, I've stumbled on the following spew: > > > [ 2435.025476] BUG: unable to handle kernel paging request at 88056730bfd4 Thank you. I guess that I know about such issue. Likewise issue was reported by Luis G.F . As far as I can judge, Hin-Tak Leung tried to discuss likewise issue many times. Anyway, the reason of this issue is synchronization issue with b-tree's nodes locking technique, from my point of view. Unfortunately, I hadn't opportunity for this activity during last time. I hope that I'll find time for this in the near future. But I can't promise something definite. Thanks, Vyacheslav Dubeyko. > [ 2435.033434] IP: memcpy (arch/x86/lib/memcpy_64.S:160) > [ 2435.034378] PGD 145c3067 PUD a6e3e5067 PMD a6e2ab067 PTE 80056730b060 > [ 2435.035052] Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN > [ 2435.035052] Dumping ftrace buffer: > [ 2435.035052](ftrace buffer empty) > [ 2435.035052] Modules linked in: > [ 2435.035052] CPU: 24 PID: 26772 Comm: trinity-c611 Not tainted > 3.17.0-next-20141010-sasha-00053-g16471e7-dirty #1379 > [ 2435.035052] task: 880226ec3000 ti: 88021a9c8000 task.ti: > 88021a9c8000 > [ 2435.035052] RIP: memcpy (arch/x86/lib/memcpy_64.S:160) > [ 2435.035052] RSP: 0018:88021a9cb4d0 EFLAGS: 00010246 > [ 2435.035052] RAX: 88021a9cb544 RBX: 0004 RCX: > 88056730bfd4 > [ 2435.035052] RDX: 0004 RSI: 88056730bfd4 RDI: > 88021a9cb544 > [ 2435.035052] RBP: 88021a9cb528 R08: dfffe901 R09: > 88021a9cb547 > [ 2435.035052] R10: 1100435396a8 R11: 1100435396a8 R12: > 0004 > [ 2435.035052] R13: 880630e8b560 R14: 88021a9cb544 R15: > 0004 > [ 2435.035052] FS: 7ff4c9a4d700() GS:88006dc0() > knlGS: > [ 2435.035052] CS: 0010 DS: ES: CR0: 80050033 > [ 2435.035052] CR2: 88056730bfd4 CR3: 00024a2e6000 CR4: > 06a0 > [ 2435.035052] Stack: > [ 2435.035052] 8b6c6897 8800 cccd > 1600 > [ 2435.035052] 88056730bfd4 88021a9cb518 880630e8b4d0 > 88021a9cb58a > [ 2435.035052] 88024f075668 0014 0003 > 88021a9cb568 > [ 2435.035052] Call Trace: > [ 2435.035052] hfsplus_brec_lenoff (include/uapi/linux/swab.h:49 > fs/hfsplus/brec.c:26) > [ 2435.035052] __hfsplus_brec_find (fs/hfsplus/bfind.c:130) > [ 2435.035052] hfsplus_brec_find (fs/hfsplus/bfind.c:196) > [ 2435.035052] hfsplus_brec_read (fs/hfsplus/bfind.c:224) > [ 2435.035052] hfsplus_find_cat (fs/hfsplus/catalog.c:202) > [ 2435.035052] hfsplus_iget (fs/hfsplus/super.c:79) > [ 2435.035052] hfsplus_lookup (fs/hfsplus/dir.c:118) > [ 2435.035052] lookup_real (fs/namei.c:1345) > [ 2435.035052] __lookup_hash (fs/namei.c:1364) > [ 2435.093450] walk_component (fs/namei.c:1471 fs/namei.c:1550) > [ 2435.094918] path_lookupat (fs/namei.c:1925 fs/namei.c:1959) > [ 2435.094918] filename_lookup (fs/namei.c:1998) > [ 2435.094918] user_path_at_empty (fs/namei.c:2150) > [ 2435.094918] user_path_at (fs/namei.c:2161) > [ 2435.094918] SyS_chown (fs/open.c:606 fs/open.c:591 fs/open.c:625 > fs/open.c:623) > [ 2435.094918] tracesys_phase2 (arch/x86/kernel/entry_64.S:529) > [ 2435.094918] Code: 89 5c 17 f8 c3 90 83 fa 08 72 1b 4c 8b 06 4c 8b 4c 16 f8 > 4c 89 07 4c 89 4c 17 f8 c3 66 2e 0f 1f 84 00 00 00 00 00 83 fa 04 72 1b <8b> > 0e 44 8b 44 16 fc 89 0f 44 89 44 17 fc c3 66 66 66 2e 0f 1f > All code > >0: 89 5c 17 f8 mov%ebx,-0x8(%rdi,%rdx,1) >4: c3 retq >5: 90 nop >6: 83 fa 08cmp$0x8,%edx >9: 72 1b jb 0x26 >b: 4c 8b 06mov(%rsi),%r8 >e: 4c 8b 4c 16 f8 mov-0x8(%rsi,%rdx,1),%r9 > 13: 4c 89 07mov%r8,(%rdi) > 16: 4c 89 4c 17 f8 mov%r9,-0x8(%rdi,%rdx,1) > 1b: c3 retq > 1c: 66 2e 0f 1f 84 00 00nopw %cs:0x0(%rax,%rax,1) > 23: 00 00 00 > 26: 83 fa 04cmp$0x4,%edx > 29: 72 1b jb 0x46 > 2b:*8b 0e mov(%rsi),%ecx <-- > trapping instruction > 2d: 44 8b 44 16 fc mov-0x4(%rsi,%rdx,1),%r8d > 32: 89 0f mov%ecx,(%rdi) > 34: 44 89 44 17 fc mov%r8d,-0x4(%rdi,%rdx,1) > 39: c3 retq > 3a: 66 66 66 2e 0f 1f 00data32 data32 nopw %cs:(%rax) > > Code starting with the faulting instruction > === >0: 8b 0e mov(%rsi),%ecx >2: 44 8b 44 16 fc mov-0x4(%rsi,%rdx,1),%r8d >7: 89 0f mov%ecx,(%rdi) >9: 44 89 44 17 fc mov
hfsplus: invalid memory access in hfsplus_brec_lenoff
Hi all, While fuzzing with trinity inside a KVM tools guest running the latest -next kernel, I've stumbled on the following spew: [ 2435.025476] BUG: unable to handle kernel paging request at 88056730bfd4 [ 2435.033434] IP: memcpy (arch/x86/lib/memcpy_64.S:160) [ 2435.034378] PGD 145c3067 PUD a6e3e5067 PMD a6e2ab067 PTE 80056730b060 [ 2435.035052] Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN [ 2435.035052] Dumping ftrace buffer: [ 2435.035052](ftrace buffer empty) [ 2435.035052] Modules linked in: [ 2435.035052] CPU: 24 PID: 26772 Comm: trinity-c611 Not tainted 3.17.0-next-20141010-sasha-00053-g16471e7-dirty #1379 [ 2435.035052] task: 880226ec3000 ti: 88021a9c8000 task.ti: 88021a9c8000 [ 2435.035052] RIP: memcpy (arch/x86/lib/memcpy_64.S:160) [ 2435.035052] RSP: 0018:88021a9cb4d0 EFLAGS: 00010246 [ 2435.035052] RAX: 88021a9cb544 RBX: 0004 RCX: 88056730bfd4 [ 2435.035052] RDX: 0004 RSI: 88056730bfd4 RDI: 88021a9cb544 [ 2435.035052] RBP: 88021a9cb528 R08: dfffe901 R09: 88021a9cb547 [ 2435.035052] R10: 1100435396a8 R11: 1100435396a8 R12: 0004 [ 2435.035052] R13: 880630e8b560 R14: 88021a9cb544 R15: 0004 [ 2435.035052] FS: 7ff4c9a4d700() GS:88006dc0() knlGS: [ 2435.035052] CS: 0010 DS: ES: CR0: 80050033 [ 2435.035052] CR2: 88056730bfd4 CR3: 00024a2e6000 CR4: 06a0 [ 2435.035052] Stack: [ 2435.035052] 8b6c6897 8800 cccd 1600 [ 2435.035052] 88056730bfd4 88021a9cb518 880630e8b4d0 88021a9cb58a [ 2435.035052] 88024f075668 0014 0003 88021a9cb568 [ 2435.035052] Call Trace: [ 2435.035052] hfsplus_brec_lenoff (include/uapi/linux/swab.h:49 fs/hfsplus/brec.c:26) [ 2435.035052] __hfsplus_brec_find (fs/hfsplus/bfind.c:130) [ 2435.035052] hfsplus_brec_find (fs/hfsplus/bfind.c:196) [ 2435.035052] hfsplus_brec_read (fs/hfsplus/bfind.c:224) [ 2435.035052] hfsplus_find_cat (fs/hfsplus/catalog.c:202) [ 2435.035052] hfsplus_iget (fs/hfsplus/super.c:79) [ 2435.035052] hfsplus_lookup (fs/hfsplus/dir.c:118) [ 2435.035052] lookup_real (fs/namei.c:1345) [ 2435.035052] __lookup_hash (fs/namei.c:1364) [ 2435.093450] walk_component (fs/namei.c:1471 fs/namei.c:1550) [ 2435.094918] path_lookupat (fs/namei.c:1925 fs/namei.c:1959) [ 2435.094918] filename_lookup (fs/namei.c:1998) [ 2435.094918] user_path_at_empty (fs/namei.c:2150) [ 2435.094918] user_path_at (fs/namei.c:2161) [ 2435.094918] SyS_chown (fs/open.c:606 fs/open.c:591 fs/open.c:625 fs/open.c:623) [ 2435.094918] tracesys_phase2 (arch/x86/kernel/entry_64.S:529) [ 2435.094918] Code: 89 5c 17 f8 c3 90 83 fa 08 72 1b 4c 8b 06 4c 8b 4c 16 f8 4c 89 07 4c 89 4c 17 f8 c3 66 2e 0f 1f 84 00 00 00 00 00 83 fa 04 72 1b <8b> 0e 44 8b 44 16 fc 89 0f 44 89 44 17 fc c3 66 66 66 2e 0f 1f All code 0: 89 5c 17 f8 mov%ebx,-0x8(%rdi,%rdx,1) 4: c3 retq 5: 90 nop 6: 83 fa 08cmp$0x8,%edx 9: 72 1b jb 0x26 b: 4c 8b 06mov(%rsi),%r8 e: 4c 8b 4c 16 f8 mov-0x8(%rsi,%rdx,1),%r9 13: 4c 89 07mov%r8,(%rdi) 16: 4c 89 4c 17 f8 mov%r9,-0x8(%rdi,%rdx,1) 1b: c3 retq 1c: 66 2e 0f 1f 84 00 00nopw %cs:0x0(%rax,%rax,1) 23: 00 00 00 26: 83 fa 04cmp$0x4,%edx 29: 72 1b jb 0x46 2b:* 8b 0e mov(%rsi),%ecx <-- trapping instruction 2d: 44 8b 44 16 fc mov-0x4(%rsi,%rdx,1),%r8d 32: 89 0f mov%ecx,(%rdi) 34: 44 89 44 17 fc mov%r8d,-0x4(%rdi,%rdx,1) 39: c3 retq 3a: 66 66 66 2e 0f 1f 00data32 data32 nopw %cs:(%rax) Code starting with the faulting instruction === 0: 8b 0e mov(%rsi),%ecx 2: 44 8b 44 16 fc mov-0x4(%rsi,%rdx,1),%r8d 7: 89 0f mov%ecx,(%rdi) 9: 44 89 44 17 fc mov%r8d,-0x4(%rdi,%rdx,1) e: c3 retq f: 66 66 66 2e 0f 1f 00data32 data32 nopw %cs:(%rax) [ 2435.094918] RIP memcpy (arch/x86/lib/memcpy_64.S:160) [ 2435.094918] RSP [ 2435.094918] CR2: 88056730bfd4 Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] staging/lustre: get rid of deprecaed acl mount option code
This is long since unused code, so get rid of it.
Signed-off-by: Oleg Drokin
---
drivers/staging/lustre/lustre/llite/llite_lib.c | 19 ---
1 file changed, 19 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/llite_lib.c
b/drivers/staging/lustre/lustre/llite/llite_lib.c
index a8bcc51..695424b 100644
--- a/drivers/staging/lustre/lustre/llite/llite_lib.c
+++ b/drivers/staging/lustre/lustre/llite/llite_lib.c
@@ -816,25 +816,6 @@ static int ll_options(char *options, int *flags)
*flags &= ~tmp;
goto next;
}
-#if LUSTRE_VERSION_CODE < OBD_OCD_VERSION(2, 5, 50, 0)
- tmp = ll_set_opt("acl", s1, LL_SBI_ACL);
- if (tmp) {
- /* Ignore deprecated mount option. The client will
-* always try to mount with ACL support, whether this
-* is used depends on whether server supports it. */
- LCONSOLE_ERROR_MSG(0x152, "Ignoring deprecated "
- "mount option 'acl'.\n");
- goto next;
- }
- tmp = ll_set_opt("noacl", s1, LL_SBI_ACL);
- if (tmp) {
- LCONSOLE_ERROR_MSG(0x152, "Ignoring deprecated "
- "mount option 'noacl'.\n");
- goto next;
- }
-#else
-#warning "{no}acl options have been deprecated since 1.8, please remove them"
-#endif
tmp = ll_set_opt("remote_client", s1, LL_SBI_RMT_CLIENT);
if (tmp) {
*flags |= tmp;
--
1.9.3
--
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/3] staging/lustre/ptlrpc: get rid of lustre 1.8 compatible checksums
Old version of lustre (1.8) calculated RPC checksums differently,
but the compat code is no longer important since in-kernel
version of lustre is nto compatible with 1.8 lustre servers
(that are long deprecated too).
Signed-off-by: Oleg Drokin
---
drivers/staging/lustre/lustre/include/lustre_net.h | 5 -
.../staging/lustre/lustre/ptlrpc/pack_generic.c| 26 --
drivers/staging/lustre/lustre/ptlrpc/sec_null.c| 18 ---
3 files changed, 49 deletions(-)
diff --git a/drivers/staging/lustre/lustre/include/lustre_net.h
b/drivers/staging/lustre/lustre/include/lustre_net.h
index 0a024d3..0235d7a 100644
--- a/drivers/staging/lustre/lustre/include/lustre_net.h
+++ b/drivers/staging/lustre/lustre/include/lustre_net.h
@@ -2627,12 +2627,7 @@ __u32 lustre_msg_get_timeout(struct lustre_msg *msg);
__u32 lustre_msg_get_service_time(struct lustre_msg *msg);
char *lustre_msg_get_jobid(struct lustre_msg *msg);
__u32 lustre_msg_get_cksum(struct lustre_msg *msg);
-#if LUSTRE_VERSION_CODE < OBD_OCD_VERSION(2, 7, 50, 0)
-__u32 lustre_msg_calc_cksum(struct lustre_msg *msg, int compat18);
-#else
-# warning "remove checksum compatibility support for b1_8"
__u32 lustre_msg_calc_cksum(struct lustre_msg *msg);
-#endif
void lustre_msg_set_handle(struct lustre_msg *msg,
struct lustre_handle *handle);
void lustre_msg_set_type(struct lustre_msg *msg, __u32 type);
diff --git a/drivers/staging/lustre/lustre/ptlrpc/pack_generic.c
b/drivers/staging/lustre/lustre/ptlrpc/pack_generic.c
index 50556db..60552f4 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/pack_generic.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/pack_generic.c
@@ -1313,43 +1313,17 @@ __u32 lustre_msg_get_cksum(struct lustre_msg *msg)
}
}
-#if LUSTRE_VERSION_CODE < OBD_OCD_VERSION(2, 7, 50, 0)
-/*
- * In 1.6 and 1.8 the checksum was computed only on struct ptlrpc_body as
- * it was in 1.6 (88 bytes, smaller than the full size in 1.8). It makes
- * more sense to compute the checksum on the full ptlrpc_body, regardless
- * of what size it is, but in order to keep interoperability with 1.8 we
- * can optionally also checksum only the first 88 bytes (caller decides). */
-# define ptlrpc_body_cksum_size_compat1888
-
-__u32 lustre_msg_calc_cksum(struct lustre_msg *msg, int compat18)
-#else
-# warning "remove checksum compatibility support for b1_8"
__u32 lustre_msg_calc_cksum(struct lustre_msg *msg)
-#endif
{
switch (msg->lm_magic) {
case LUSTRE_MSG_MAGIC_V2: {
struct ptlrpc_body *pb = lustre_msg_ptlrpc_body(msg);
-#if LUSTRE_VERSION_CODE < OBD_OCD_VERSION(2, 7, 50, 0)
- __u32 crc;
- unsigned int hsize = 4;
- __u32 len = compat18 ? ptlrpc_body_cksum_size_compat18 :
- lustre_msg_buflen(msg, MSG_PTLRPC_BODY_OFF);
- LASSERTF(pb, "invalid msg %p: no ptlrpc body!\n", msg);
- cfs_crypto_hash_digest(CFS_HASH_ALG_CRC32, (unsigned char *)pb,
- len, NULL, 0, (unsigned char *),
- );
- return crc;
-#else
-# warning "remove checksum compatibility support for b1_8"
__u32 crc;
unsigned int hsize = 4;
cfs_crypto_hash_digest(CFS_HASH_ALG_CRC32, (unsigned char *)pb,
lustre_msg_buflen(msg, MSG_PTLRPC_BODY_OFF),
NULL, 0, (unsigned char *), );
return crc;
-#endif
}
default:
CERROR("incorrect message magic: %08x\n", msg->lm_magic);
diff --git a/drivers/staging/lustre/lustre/ptlrpc/sec_null.c
b/drivers/staging/lustre/lustre/ptlrpc/sec_null.c
index 099cec3..4e13243 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/sec_null.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/sec_null.c
@@ -101,16 +101,7 @@ int null_ctx_verify(struct ptlrpc_cli_ctx *ctx, struct
ptlrpc_request *req)
if (req->rq_early) {
cksums = lustre_msg_get_cksum(req->rq_repdata);
-#if LUSTRE_VERSION_CODE < OBD_OCD_VERSION(2, 7, 50, 0)
- if (lustre_msghdr_get_flags(req->rq_reqmsg) &
- MSGHDR_CKSUM_INCOMPAT18)
- cksumc = lustre_msg_calc_cksum(req->rq_repmsg, 0);
- else
- cksumc = lustre_msg_calc_cksum(req->rq_repmsg, 1);
-#else
-# warning "remove checksum compatibility support for b1_8"
cksumc = lustre_msg_calc_cksum(req->rq_repmsg);
-#endif
if (cksumc != cksums) {
CDEBUG(D_SEC,
"early reply checksum mismatch: %08x != %08x\n",
@@ -371,16 +362,7 @@ int null_authorize(struct ptlrpc_request *req)
} else {
__u32 cksum;
-#if LUSTRE_VERSION_CODE < OBD_OCD_VERSION(2, 7, 50, 0)
- if (lustre_msghdr_get_flags(req->rq_reqmsg) &
-
[PATCH 3/3] staging/lustre/quota: Get rid of compat quota code
Nobody should be using any fo the old lustre 1.8 era tools
anymore, so drop compatibility with those.
Signed-off-by: Oleg Drokin
---
drivers/staging/lustre/lustre/llite/dir.c | 58 --
.../staging/lustre/lustre/llite/llite_internal.h | 18 ---
2 files changed, 76 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/dir.c
b/drivers/staging/lustre/lustre/llite/dir.c
index b0bb709..a9b460d 100644
--- a/drivers/staging/lustre/lustre/llite/dir.c
+++ b/drivers/staging/lustre/lustre/llite/dir.c
@@ -1694,64 +1694,6 @@ out_poll:
OBD_FREE_PTR(check);
return rc;
}
-#if LUSTRE_VERSION_CODE < OBD_OCD_VERSION(2, 7, 50, 0)
- case LL_IOC_QUOTACTL_18: {
- /* copy the old 1.x quota struct for internal use, then copy
-* back into old format struct. For 1.8 compatibility. */
- struct if_quotactl_18 *qctl_18;
- struct if_quotactl *qctl_20;
-
- qctl_18 = kzalloc(sizeof(*qctl_18), GFP_NOFS);
- if (!qctl_18)
- return -ENOMEM;
-
- qctl_20 = kzalloc(sizeof(*qctl_20), GFP_NOFS);
- if (!qctl_20) {
- rc = -ENOMEM;
- goto out_quotactl_18;
- }
-
- if (copy_from_user(qctl_18, (void *)arg, sizeof(*qctl_18))) {
- rc = -ENOMEM;
- goto out_quotactl_20;
- }
-
- QCTL_COPY(qctl_20, qctl_18);
- qctl_20->qc_idx = 0;
-
- /* XXX: dqb_valid was borrowed as a flag to mark that
-* only mds quota is wanted */
- if (qctl_18->qc_cmd == Q_GETQUOTA &&
- qctl_18->qc_dqblk.dqb_valid) {
- qctl_20->qc_valid = QC_MDTIDX;
- qctl_20->qc_dqblk.dqb_valid = 0;
- } else if (qctl_18->obd_uuid.uuid[0] != '\0') {
- qctl_20->qc_valid = QC_UUID;
- qctl_20->obd_uuid = qctl_18->obd_uuid;
- } else {
- qctl_20->qc_valid = QC_GENERAL;
- }
-
- rc = quotactl_ioctl(sbi, qctl_20);
-
- if (rc == 0) {
- QCTL_COPY(qctl_18, qctl_20);
- qctl_18->obd_uuid = qctl_20->obd_uuid;
-
- if (copy_to_user((void *)arg, qctl_18,
-sizeof(*qctl_18)))
- rc = -EFAULT;
- }
-
-out_quotactl_20:
- OBD_FREE_PTR(qctl_20);
-out_quotactl_18:
- OBD_FREE_PTR(qctl_18);
- return rc;
- }
-#else
-#warning "remove old LL_IOC_QUOTACTL_18 compatibility code"
-#endif /* LUSTRE_VERSION_CODE < OBD_OCD_VERSION(2, 7, 50, 0) */
case LL_IOC_QUOTACTL: {
struct if_quotactl *qctl;
diff --git a/drivers/staging/lustre/lustre/llite/llite_internal.h
b/drivers/staging/lustre/lustre/llite/llite_internal.h
index 36aa0fd..2845aab 100644
--- a/drivers/staging/lustre/lustre/llite/llite_internal.h
+++ b/drivers/staging/lustre/lustre/llite/llite_internal.h
@@ -1509,24 +1509,6 @@ static inline void d_lustre_revalidate(struct dentry
*dentry)
spin_unlock(>d_lock);
}
-#if LUSTRE_VERSION_CODE < OBD_OCD_VERSION(2, 7, 50, 0)
-/* Compatibility for old (1.8) compiled userspace quota code */
-struct if_quotactl_18 {
- __u32 qc_cmd;
- __u32 qc_type;
- __u32 qc_id;
- __u32 qc_stat;
- struct obd_dqinfo qc_dqinfo;
- struct obd_dqblkqc_dqblk;
- charobd_type[16];
- struct obd_uuid obd_uuid;
-};
-#define LL_IOC_QUOTACTL_18 _IOWR('f', 162, struct if_quotactl_18 *)
-/* End compatibility for old (1.8) compiled userspace quota code */
-#else
-#warning "remove old LL_IOC_QUOTACTL_18 compatibility code"
-#endif /* LUSTRE_VERSION_CODE < OBD_OCD_VERSION(2, 7, 50, 0) */
-
enum {
LL_LAYOUT_GEN_NONE = ((__u32)-2), /* layout lock was cancelled */
LL_LAYOUT_GEN_EMPTY = ((__u32)-1) /* for empty layout */
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] Lustre: remove old compat code
These three patches remove support for code that is no longer needed. Mostly ability to talk to old version of lustre clients and servers. Oleg Drokin (3): staging/lustre/ptlrpc: get rid of lustre 1.8 compatible checksums staging/lustre: get rid of deprecaed acl mount option code staging/lustre/quota: Get rid of compat quota code drivers/staging/lustre/lustre/include/lustre_net.h | 5 -- drivers/staging/lustre/lustre/llite/dir.c | 58 -- .../staging/lustre/lustre/llite/llite_internal.h | 18 --- drivers/staging/lustre/lustre/llite/llite_lib.c| 19 --- .../staging/lustre/lustre/ptlrpc/pack_generic.c| 26 -- drivers/staging/lustre/lustre/ptlrpc/sec_null.c| 18 --- 6 files changed, 144 deletions(-) -- 1.9.3 -- 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] char: hw_random: core.c: Changed from using strncpy to strlcpy
On Sat, Oct 11, 2014 at 07:11:22PM -0700, Guenter Roeck wrote: > On Sat, Oct 11, 2014 at 05:27:41PM -0700, Mark D Rustad wrote: > > On Oct 11, 2014, at 3:36 PM, Rickard Strandqvist > > wrote: > > > > > Changed from using strncpy to strlcpy to simplify the code > > > > Actually you changed from using strncat to strlcat. > > > ... and changed the length parameter along the way, making the length check > overall quite worthless and introducing a _real_ problem. > Me talking nonsense; ignore this noise. Guenter -- 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/
unaligned accesses in SLAB etc.
I'm getting tons of the following on sparc64: [603965.383447] Kernel unaligned access at TPC[546b58] free_block+0x98/0x1a0 [603965.396987] Kernel unaligned access at TPC[546b60] free_block+0xa0/0x1a0 [603965.410523] Kernel unaligned access at TPC[546b58] free_block+0x98/0x1a0 [603965.424061] Kernel unaligned access at TPC[546b60] free_block+0xa0/0x1a0 [603965.437617] Kernel unaligned access at TPC[546b58] free_block+0x98/0x1a0 [603970.554394] log_unaligned: 333 callbacks suppressed [603970.564041] Kernel unaligned access at TPC[546b58] free_block+0x98/0x1a0 [603970.577576] Kernel unaligned access at TPC[546b60] free_block+0xa0/0x1a0 [603970.591122] Kernel unaligned access at TPC[546b58] free_block+0x98/0x1a0 [603970.604669] Kernel unaligned access at TPC[546b60] free_block+0xa0/0x1a0 [603970.618216] Kernel unaligned access at TPC[546b58] free_block+0x98/0x1a0 [603976.515633] log_unaligned: 31 callbacks suppressed [603976.525092] Kernel unaligned access at TPC[548080] cache_alloc_refill+0x180/0x3a0 [603976.540196] Kernel unaligned access at TPC[548080] cache_alloc_refill+0x180/0x3a0 [603976.555308] Kernel unaligned access at TPC[548080] cache_alloc_refill+0x180/0x3a0 [603976.570411] Kernel unaligned access at TPC[548080] cache_alloc_refill+0x180/0x3a0 [603976.585526] Kernel unaligned access at TPC[548080] cache_alloc_refill+0x180/0x3a0 [603982.476424] log_unaligned: 43 callbacks suppressed [603982.485881] Kernel unaligned access at TPC[549378] kmem_cache_alloc+0xd8/0x1e0 [603982.501590] Kernel unaligned access at TPC[5470a8] kmem_cache_free+0xc8/0x200 [603982.501605] Kernel unaligned access at TPC[549378] kmem_cache_alloc+0xd8/0x1e0 [603982.530382] Kernel unaligned access at TPC[5470a8] kmem_cache_free+0xc8/0x200 [603982.544820] Kernel unaligned access at TPC[549378] kmem_cache_alloc+0xd8/0x1e0 [603987.567130] log_unaligned: 11 callbacks suppressed [603987.576582] Kernel unaligned access at TPC[548080] cache_alloc_refill+0x180/0x3a0 [603987.591696] Kernel unaligned access at TPC[548080] cache_alloc_refill+0x180/0x3a0 [603987.606811] Kernel unaligned access at TPC[548080] cache_alloc_refill+0x180/0x3a0 [603987.621904] Kernel unaligned access at TPC[548080] cache_alloc_refill+0x180/0x3a0 [603987.637017] Kernel unaligned access at TPC[548080] cache_alloc_refill+0x180/0x3a0 -- 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] char: hw_random: core.c: Changed from using strncpy to strlcpy
On Sat, Oct 11, 2014 at 05:27:41PM -0700, Mark D Rustad wrote:
> On Oct 11, 2014, at 3:36 PM, Rickard Strandqvist
> wrote:
>
> > Changed from using strncpy to strlcpy to simplify the code
>
> Actually you changed from using strncat to strlcat.
>
... and changed the length parameter along the way, making the length check
overall quite worthless and introducing a _real_ problem.
Guenter
> > Signed-off-by: Rickard Strandqvist
> > ---
> > drivers/char/hw_random/core.c | 12
> > 1 file changed, 4 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
> > index aa30a25..1500cfd 100644
> > --- a/drivers/char/hw_random/core.c
> > +++ b/drivers/char/hw_random/core.c
> > @@ -281,7 +281,6 @@ static ssize_t hwrng_attr_available_show(struct device
> > *dev,
> > char *buf)
> > {
> > int err;
> > - ssize_t ret = 0;
> > struct hwrng *rng;
> >
> > err = mutex_lock_interruptible(_mutex);
> > @@ -289,16 +288,13 @@ static ssize_t hwrng_attr_available_show(struct
> > device *dev,
> > return -ERESTARTSYS;
> > buf[0] = '\0';
> > list_for_each_entry(rng, _list, list) {
> > - strncat(buf, rng->name, PAGE_SIZE - ret - 1);
> > - ret += strlen(rng->name);
> > - strncat(buf, " ", PAGE_SIZE - ret - 1);
> > - ret++;
> > + strlcat(buf, rng->name, PAGE_SIZE);
> > + strlcat(buf, " ", PAGE_SIZE);
> > }
> > - strncat(buf, "\n", PAGE_SIZE - ret - 1);
> > - ret++;
> > + strlcat(buf, "\n", PAGE_SIZE);
> > mutex_unlock(_mutex);
> >
> > - return ret;
> > + return strlen(buf);
> > }
> >
> > static DEVICE_ATTR(rng_current, S_IRUGO | S_IWUSR,
> > --
> > 1.7.10.4
>
> --
> Mark Rustad, mrus...@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 0/3] scsi: Add Hyper-V logical block provisioning quirks
> -Original Message-
> From: Jeff Leung [mailto:jle...@v10networks.ca]
> Sent: Saturday, October 11, 2014 1:22 PM
> To: KY Srinivasan; James Bottomley; Christoph Hellwig
> Cc: Sitsofe Wheeler; Haiyang Zhang; Christoph Hellwig; Hannes Reinecke;
> linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org
> Subject: RE: [PATCH 0/3] scsi: Add Hyper-V logical block provisioning quirks
>
> > On the current release of Windows (windows 10), we are advertising SPC3
> compliance.
> > We are ok with declaring compliance to SPC3 in our drivers.
> If you are going to declare SPC3 compliance in the drivers, are you going to
> put in checks to ensure that SPC-3 compliance doesn't get accidentally
> enabled for hypervisors below Win10?
>
> I do know for a fact that Ubuntu's kernels already force SPC3 compliance to
> enable specific features such as TRIM on earlier versions of Hyper-V (Namely
> Hyper-V 2012 and 2012 R2).
You are right; Ubuntu has been carrying a patch that was doing just this and
this has been
working without any issues on many earlier versions of Windows. (2012 and 2012
R2).
On windows 10 we don't need any changes in the Linux driver as the host itself
is
advertising SPC3 compliance. Based on the testing we have done with Ubuntu, we
are
comfortable picking up that patch.
Regards,
K. Y
>
> --Jeff
>
> > Regards,
> >
> > K. Y
> >
> >
> > NryزXvؖ){nlj{zX}zj:v zZzf~zwڢ)jyA
> >
> > i
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH] usb: serial: Fix indentation style issue
On Sat, 2014-10-11 at 13:19 -0700, Greg KH wrote:
> On Sat, Oct 11, 2014 at 08:36:33AM -0700, Joe Perches wrote:
> > On Sat, 2014-10-11 at 07:20 -0700, Greg KH wrote:
> > > On Sat, Oct 11, 2014 at 03:49:43PM +0200, Philip Munksgaard wrote:
> > > > Fix a style issue
> > []
> > > > diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
> > []
> > > > @@ -1616,7 +1616,7 @@ static const struct usb_device_id option_ids[] = {
> > > > { USB_DEVICE(TLAYTECH_VENDOR_ID, TLAYTECH_PRODUCT_TEU800) },
> > > > { USB_DEVICE(LONGCHEER_VENDOR_ID, FOUR_G_SYSTEMS_PRODUCT_W14),
> > > > .driver_info = (kernel_ulong_t)_g_w14_blacklist
> > > > - },
> > > > + },
> > >
> > > Why not fix the same 'space' issue on the line before this at the same
> > > time?
> >
> > I think there is no space issue on the previous line.
> > What do you see Greg?
>
> I see 'space space tab', just like this line that is being changed.
Right, silly evolution previewer can't differentiate space/tab
> /me hands Joe a real editor.
Well, where is it? ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/12] rtc: omap: silence bogus power-up reset message at probe
Hi, On Sat, Oct 11, 2014 at 12:20:04PM +0200, Johan Hovold wrote: > On Fri, Oct 10, 2014 at 01:02:56PM -0500, Felipe Balbi wrote: > > On Fri, Oct 10, 2014 at 01:00:54PM -0500, Felipe Balbi wrote: > > > On Thu, Oct 09, 2014 at 09:06:29PM +0200, Johan Hovold wrote: > > > > Some legacy RTC IP revisions has a power-up reset flag in the status > > > > register that later revisions lack. > > > > > > > > As this flag is always read back as set on later revisions (or is > > > > overloaded with a different flag), make sure to only clear the flag and > > > > print the info message on legacy platforms. > > > > > > > > Signed-off-by: Johan Hovold > > > > > > Reviewed-by: Felipe Balbi > > > > oh, btw. This should be done for DT probes too. > > What do you mean? This is for DT probes (of "ti,da830-rtc" and > "ti,am3352-rtc"). DT probing of legacy RTC IPs is currently not > supported. > > Are you suggesting I should add a new compatible string for that? it seemed to me that you're only passing the new flag through platform_device_id table, not DT table. Did I miss something ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 08/12] rtc: omap: restore irq state after reading TC registers
On Sat, Oct 11, 2014 at 12:12:01PM +0200, Johan Hovold wrote:
> On Fri, Oct 10, 2014 at 01:02:31PM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Thu, Oct 09, 2014 at 09:06:30PM +0200, Johan Hovold wrote:
> > > Make sure to restore local irq state when reading the timer/calendar
> > > (TC) registers, so that omap_rtc_read_time() can be called with
> > > interrupts disabled.
> > >
> > > Signed-off-by: Johan Hovold
> > > ---
> > > drivers/rtc/rtc-omap.c | 6 --
> > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> > > index 0ef016553a97..62e2e9a9887a 100644
> > > --- a/drivers/rtc/rtc-omap.c
> > > +++ b/drivers/rtc/rtc-omap.c
> > > @@ -239,8 +239,10 @@ static void bcd2tm(struct rtc_time *tm)
> > >
> > > static int omap_rtc_read_time(struct device *dev, struct rtc_time *tm)
> > > {
> > > + unsigned long flags;
> > > +
> > > /* we don't report wday/yday/isdst ... */
> > > - local_irq_disable();
> > > + local_irq_save(flags);
> >
> > you should really convert these to a real spin_lock_irq*(), that's
> > because local_irq* do not get re-written with RT patchset, so this
> > pretty much "breaks" RT.
>
> The driver uses local_irq* throughout to guarantee registers are not
> read or written during an update event.
>
> In fact, at least on AM33xx, this is not even necessary when reading (as
> opposed to writing) the TC registers, but I did not dare change that
> without knowing how the legacy platforms work in this respect.
>
> Do you suggest doing this conversion as part of, or on top of, this
> series?
probably on top of is. Safer that way.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 10/12] usb: musb: ux500_dma: use dmaengine_xxx() APIs
Hi, On Sat, Oct 11, 2014 at 09:10:38PM +0530, Vinod Koul wrote: > The drivers should use dmaengine_terminate_all() or dmaengine_slave_config() > API instead of accessing the device_control which will be deprecated soon > > Signed-off-by: Vinod Koul awesome. It looks like it doesn't have a direct dependency with the rest of the series, so I'll take this through my tree with Greg's ack, unless you shout ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH] char: hw_random: core.c: Changed from using strncpy to strlcpy
On Oct 11, 2014, at 3:36 PM, Rickard Strandqvist
wrote:
> Changed from using strncpy to strlcpy to simplify the code
Actually you changed from using strncat to strlcat.
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/char/hw_random/core.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
> index aa30a25..1500cfd 100644
> --- a/drivers/char/hw_random/core.c
> +++ b/drivers/char/hw_random/core.c
> @@ -281,7 +281,6 @@ static ssize_t hwrng_attr_available_show(struct device
> *dev,
>char *buf)
> {
> int err;
> - ssize_t ret = 0;
> struct hwrng *rng;
>
> err = mutex_lock_interruptible(_mutex);
> @@ -289,16 +288,13 @@ static ssize_t hwrng_attr_available_show(struct device
> *dev,
> return -ERESTARTSYS;
> buf[0] = '\0';
> list_for_each_entry(rng, _list, list) {
> - strncat(buf, rng->name, PAGE_SIZE - ret - 1);
> - ret += strlen(rng->name);
> - strncat(buf, " ", PAGE_SIZE - ret - 1);
> - ret++;
> + strlcat(buf, rng->name, PAGE_SIZE);
> + strlcat(buf, " ", PAGE_SIZE);
> }
> - strncat(buf, "\n", PAGE_SIZE - ret - 1);
> - ret++;
> + strlcat(buf, "\n", PAGE_SIZE);
> mutex_unlock(_mutex);
>
> - return ret;
> + return strlen(buf);
> }
>
> static DEVICE_ATTR(rng_current, S_IRUGO | S_IWUSR,
> --
> 1.7.10.4
--
Mark Rustad, mrus...@gmail.com
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: fs/namei.c: Misuse of sequence counts?
On Sat, Oct 11, 2014 at 05:58:08PM -0500, Eric Biggers wrote: > In path_init(), said commit added a call to read_seqcount_retry() after > loading > the inode. I see two problems with this: > > - The read_seqcount_retry() isn't needed just to load the inode pointer, so > the change doesn't seem to accomplish anything. Huh? What's to guarantee that dentry hasn't become negative since the moment we'd fetched the seqcount? _That_ is the problem we are dealing with here - link_path_walk() relies on nd->inode being non-NULL. > - If the -ECHILD code path actually runs, the reference to the 'struct file' > can be leaked. Umm... That, OTOH, might be true, _if_ we could hit it on the path where nd->path comes from file (and descriptor table had been shared). Which could happen, if we could get d_drop() done to that sucker for some reason - other codepaths bumping the seqcount are impossible for pinned dentry (including that of an opened file). Which can, indeed, happen on something like NFS. OK, so all callers of path_init() should go to the same place where they go on link_path_walk() failure, like this. And that's probably what we want in backports; however, longer term we would be better off with a combined path_init + link_path_walk - all callers do exactly the same thing there... OK, that can be in a followup... Signed-off-by: Al Viro --- diff --git a/fs/namei.c b/fs/namei.c index d20d579..0f64aa4 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -1950,7 +1950,7 @@ static int path_lookupat(int dfd, const char *name, err = path_init(dfd, name, flags | LOOKUP_PARENT, nd, ); if (unlikely(err)) - return err; + goto out; current->total_link_count = 0; err = link_path_walk(name, nd); @@ -1982,6 +1982,7 @@ static int path_lookupat(int dfd, const char *name, } } +out: if (base) fput(base); @@ -2301,7 +2302,7 @@ path_mountpoint(int dfd, const char *name, struct path *path, unsigned int flags err = path_init(dfd, name, flags | LOOKUP_PARENT, , ); if (unlikely(err)) - return err; + goto out; current->total_link_count = 0; err = link_path_walk(name, ); -- 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] net: wireless: brcm80211: brcmfmac: dhd_sdio.c: Cleaning up missing null-terminate in conjunction with strncpy
Replacing strncpy with strlcpy to avoid strings that lacks null terminate.
And changed from using strncpy to strlcpy to simplify code.
Signed-off-by: Rickard Strandqvist
---
drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c | 25 ++--
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c
b/drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c
index f55f625..d20d4e6 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c
@@ -670,7 +670,6 @@ static int brcmf_sdio_get_fwnames(struct brcmf_chip *ci,
struct brcmf_sdio_dev *sdiodev)
{
int i;
- uint fw_len, nv_len;
char end;
for (i = 0; i < ARRAY_SIZE(brcmf_fwname_data); i++) {
@@ -684,25 +683,25 @@ static int brcmf_sdio_get_fwnames(struct brcmf_chip *ci,
return -ENODEV;
}
- fw_len = sizeof(sdiodev->fw_name) - 1;
- nv_len = sizeof(sdiodev->nvram_name) - 1;
/* check if firmware path is provided by module parameter */
if (brcmf_firmware_path[0] != '\0') {
- strncpy(sdiodev->fw_name, brcmf_firmware_path, fw_len);
- strncpy(sdiodev->nvram_name, brcmf_firmware_path, nv_len);
- fw_len -= strlen(sdiodev->fw_name);
- nv_len -= strlen(sdiodev->nvram_name);
+ strlcpy(sdiodev->fw_name, brcmf_firmware_path,
+ sizeof(sdiodev->fw_name));
+ strlcpy(sdiodev->nvram_name, brcmf_firmware_path,
+ sizeof(sdiodev->nvram_name));
end = brcmf_firmware_path[strlen(brcmf_firmware_path) - 1];
if (end != '/') {
- strncat(sdiodev->fw_name, "/", fw_len);
- strncat(sdiodev->nvram_name, "/", nv_len);
- fw_len--;
- nv_len--;
+ strlcat(sdiodev->fw_name, "/",
+ sizeof(sdiodev->fw_name));
+ strlcat(sdiodev->nvram_name, "/",
+ sizeof(sdiodev->nvram_name));
}
}
- strncat(sdiodev->fw_name, brcmf_fwname_data[i].bin, fw_len);
- strncat(sdiodev->nvram_name, brcmf_fwname_data[i].nv, nv_len);
+ strlcat(sdiodev->fw_name, brcmf_fwname_data[i].bin,
+ sizeof(sdiodev->fw_name));
+ strlcat(sdiodev->nvram_name, brcmf_fwname_data[i].nv,
+ sizeof(sdiodev->nvram_name));
return 0;
}
--
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: fs/namei.c: Misuse of sequence counts?
On Sat, Oct 11, 2014 at 05:58:08PM -0500, Eric Biggers wrote: > In follow_dotdot_rcu(), said commit moved loads of the inode to just before > read_seqcount_begin(), in several instances. I don't think this is correct, > because (as I understand it) read_seqcount_begin() is opening a seq-read > critical section on the new dentry. So the inode load should come *after* it, > as in the original, to ensure the inode pointer is correctly matched with the > sequence count. Nope. What we do is * pick parent inode and seqcount (in whatever order) * THEN check that child is still unchanged. The second part guarantees that parent dentry had been the parent of child all along, since the moment we'd first fetched _child's_ seqcount. And since a pinned positive dentry can't have its ->d_inode changed, we know that the value of parent's inode we'd fetched remained valid at least until we'd checked the child's seqcount and found it unchanged. Which means that we had it valid at some point after we'd fetched parent's seqcount. The crucial part is that dentry cannot change its ->d_inode for as long as there are references to it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rhashtable: hang while running tests on boot
On 10/11/2014 06:26 PM, Thomas Graf wrote: > On 10/11/14 at 12:09pm, Sasha Levin wrote: >> On 10/11/2014 11:50 AM, Paul E. McKenney wrote: >>> I am guessing that this happens only when running the resizable >>> hashtable >>> tests -- if that guess is incorrect, please let me know. > > I've seen it a few times only with rhashtable related traces, if that ever > changes I'll update - but for now I think it's safe to assume it's > rhashtable > specific. >>> Ah, so this is intermittent. Joy. >> >> Yup, I'm seeing it in about 10% of boot attempts. > > Have you ever seen any traces outside of the test_rht code? I'm > trying to figure out whether it's a bug in the test code or in the > hash table itself. There are odd RCU lockups (one of which is pasted earlier in this thread), but there's nothing pointing to rht code there, and I'm not seeing any other rht related issues. Thanks, Sasha -- 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/1] drivers/staging: Fixed sparse error "directive in argument list"
Ah .. right! I didn't know what OBD_OCD_VERSION() was. Now I see it's
a way to test kernel version. I am going to submit a new patch
shortly.
Thanks,
Filipe
On Sat, Oct 11, 2014 at 9:15 PM, Greg KH wrote:
>
> On Sat, Oct 11, 2014 at 08:13:42PM +0100, Filipe Gonçalves wrote:
>> This patch fixes a sparse warning on layout.c (ptlrpc) that was caused by
>> having preprocessor directives in the arguments to a macro.
>>
>> Signed-off-by: Filipe Gonçalves
>> ---
>> drivers/staging/lustre/lustre/ptlrpc/layout.c | 7 +--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/staging/lustre/lustre/ptlrpc/layout.c
>> b/drivers/staging/lustre/lustre/ptlrpc/layout.c
>> index 5b83371..211df78 100644
>> --- a/drivers/staging/lustre/lustre/ptlrpc/layout.c
>> +++ b/drivers/staging/lustre/lustre/ptlrpc/layout.c
>> @@ -978,10 +978,11 @@ struct req_msg_field RMF_CONN =
>> EXPORT_SYMBOL(RMF_CONN);
>>
>> struct req_msg_field RMF_CONNECT_DATA =
>> +#if LUSTRE_VERSION_CODE > OBD_OCD_VERSION(2, 7, 50, 0)
>> DEFINE_MSGF("cdata",
>> RMF_F_NO_SIZE_CHECK /* we allow extra space for interop */,
>> -#if LUSTRE_VERSION_CODE > OBD_OCD_VERSION(2, 7, 50, 0)
>> sizeof(struct obd_connect_data),
>> + lustre_swab_connect, NULL);
>
> Ick ick ick.
>
> Yeah, sparse might complain about this, but how about just properly
> deleting the #ifdef entirely, and not perpetuate it even more?
>
> It shouldn't be needed anymore now that the code is in the kernel tree.
>
> greg k-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: [patch 3/3] mm: memcontrol: fix transparent huge page allocations under pressure
On Wed, Oct 08, 2014 at 01:47:25PM -0400, Johannes Weiner wrote:
> On Wed, Oct 08, 2014 at 05:33:29PM +0200, Michal Hocko wrote:
> > On Tue 07-10-14 21:11:06, Johannes Weiner wrote:
> > > On Tue, Oct 07, 2014 at 03:59:50PM +0200, Michal Hocko wrote:
> > > > Another part that matters is the size. Memcgs might be really small and
> > > > that changes the math. Large reclaim target will get to low prio reclaim
> > > > and thus the excessive reclaim.
> > >
> > > I already addressed page size vs. memcg size before.
> > >
> > > However, low priority reclaim does not result in excessive reclaim.
> > > The reclaim goal is checked every time it scanned SWAP_CLUSTER_MAX
> > > pages, and it exits if the goal has been met. See shrink_lruvec(),
> > > shrink_zone() etc.
> >
> > Now I am confused. shrink_zone will bail out but shrink_lruvec will loop
> > over nr[...] until they are empty and only updates the numbers to be
> > roughly proportional once:
> >
> > if (nr_reclaimed < nr_to_reclaim || scan_adjusted)
> > continue;
> >
> > /*
> > * For kswapd and memcg, reclaim at least the number of
> > pages
> > * requested. Ensure that the anon and file LRUs are scanned
> > * proportionally what was requested by get_scan_count(). We
> > * stop reclaiming one LRU and reduce the amount scanning
> > * proportional to the original scan target.
> > */
> > [...]
> > scan_adjusted = true;
> >
> > Or do you rely on
> > /*
> > * It's just vindictive to attack the larger once the
> > smaller
> > * has gone to zero. And given the way we stop scanning the
> > * smaller below, this makes sure that we only make one
> > nudge
> > * towards proportionality once we've got nr_to_reclaim.
> > */
> > if (!nr_file || !nr_anon)
> > break;
> >
> > and SCAN_FILE because !inactive_file_is_low?
>
> That function is indeed quite confusing.
>
> Once nr_to_reclaim has been met, it looks at both LRUs and decides
> which one has the smaller scan target left, sets it to 0, and then
> scales the bigger target in proportion - that means if it scanned 10%
> of nr[file], it sets nr[anon] to 10% of its original size, minus the
> anon pages it already scanned. Based on that alone, overscanning is
> limited to twice the requested size, i.e. 4MB for a 2MB THP page,
> regardless of how low the priority drops.
Sorry, this conclusion is incorrect. The proportionality code can
indeed lead to more overreclaim than that, although I think this is
actually not intended: the comment says "this makes sure we only make
one nudge towards proportionality once we've got nr_to_reclaim," but
once scan_adjusted we never actually check anymore. We we can end up
making a lot more nudges toward proportionality.
However, the following still applies, so it shouldn't matter:
> In practice, the VM is heavily biased to avoid swapping. The forceful
> SCAN_FILE you point out is one condition that avoids the proportional
> scan most of the time. But even the proportional scan is heavily
> biased towards cache - every cache insertion decreases the file
> recent_rotated/recent_scanned ratio, whereas anon faults do not.
>
> On top of that, anon pages start out on the active list, whereas cache
> starts on the inactive, which means that the majority of the anon scan
> target - should there be one - usually translates to deactivation.
>
> So in most cases, I'd expect the scanner to bail after nr_to_reclaim
> cache pages, and in low cache situations it might scan up to 2MB worth
> of anon pages, a small amount of which it might swap.
>
> I don't particularly like the decisions the current code makes, but it
> should work. We have put in a lot of effort to prevent overreclaim in
> the last few years, and a big part of this was decoupling the priority
> level from the actual reclaim results. Nowadays, the priority level
> should merely dictate the scan window and have no impact on the number
> of pages actually reclaimed. I don't expect that it will, but if it
> does, that's a reclaim bug that needs to be addressed. If we ask for
> N pages, it should never reclaim significantly more than that,
> regardless of how aggressively it has to scan to accomplish that.
That being said, I don't get the rationale behind the proportionality
code in shrink_lruvec(). The patch that introduced it - e82e0561dae9
("mm: vmscan: obey proportional scanning requirements for kswapd") -
mentions respecting swappiness, but as per above we ignore swappiness
anyway until we run low on cache and into actual pressure. And under
pressure, once we struggle to reclaim nr_to_reclaim, proportionality
enforces itself when one LRU type target hits zero and we continue to
scan the one
Re: [bisected] e341694e3eb5 netlink_lookup() rcu conversion causes latencies
From: Thomas Graf Date: Sat, 11 Oct 2014 23:25:14 +0100 > I think the issue here is obvious and a fix is on the way to move > the insertion and removal to a worker to no longer require the > synchronize_rcu(). > > What bothers me is that the synchronize_rcu() should only occur > on expand/shrink and not for every table update. The default table > size is 64. Not true, every netlink socket release incurs a synchronize_net() now, because we added such a call to netlink_release(). I specifically brought this up to as a possible problem when the changes went in... -- 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 v3 2/2] DT: iio: vadc: document dt binding
Hi,
two small issues inline.
Stanimir Varbanov schrieb am 24.09.2014 14:56:
> Document DT binding for Qualcomm SPMI PMIC voltage ADC
> driver.
>
> Signed-off-by: Stanimir Varbanov
> Signed-off-by: Ivan T. Ivanov
> ---
> .../devicetree/bindings/iio/adc/qcom,spmi-vadc.txt | 130
>
> 1 files changed, 130 insertions(+), 0 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
> b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
> new file mode 100644
> index 000..fa30300
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
> @@ -0,0 +1,130 @@
> +Qualcomm's SPMI PMIC voltage ADC
> +
> +SPMI PMIC voltage ADC (VADC) provides interface to clients to read
> +voltage. A 15 bit ADC is used for voltage measurements. There are multiple
> +peripherals to the VADC and the scope of the driver is to provide interface
> +for the USR peripheral of the VADC.
> +
> +VADC node:
> +
> +- compatible:
> +Usage: required
> +Value type:
> +Definition: Should contain "qcom,spmi-vadc".
> +
> +- reg:
> +Usage: required
> +Value type:
> +Definition: Base address in the SPMI PMIC register map.
> +
> +- address-cells:
> +Usage: required
> +Value type:
> +Definition: Must be one.
> +
> +- size-cells:
> +Usage: required
> +Value type:
> +Definition: Must be zero.
> +
> +- interrupts:
> +Usage: optional
> +Value type:
> +Definition: End of conversion interrupt number. If this property does
> +not exist polling will be used instead.
> +
> +- interrupt-names:
> +Usage: optional
> +Value type:
> +Definition: Should contain the interrupt name "eoc" (end of conversion).
> +
> +Channel node properties:
> +
> +- reg:
> +Usage: required
> +Value type:
> +Definition: AMUX channel number.
> +See include/dt-bindings/iio/qcom,spmi-pmic-vadc.h
> +
> +- qcom,decimation:
> +Usage: optional
> +Value type:
> +Definition: Sampling rate to use for the individual channel measurement.
> +Quicker measurements can be made by reducing decimation ratio.
> +Valid values are 512, 1024, 2048, 4096.
> +If property is not found, default value of 512 will be used.
> +
> +- qcom,pre-scaling:
> +Usage: optional
> +Value type:
> +Definition: Used for scaling the channel input signal before the signal
> is
> +fed to VADC. The configuration for this node is to know the
> +pre-determined ratio and use it for post scaling. Select one from
> +the following options.
> +<1 1>, <1 3>, <1 4>, <1 6>, <1 20>, <1 8>, <10 81>, <1 10>
> +If property is not found default value depending of chip will be
> used.
> +
> +- qcom,ratiometric:
> +Usage: optional
> +Value type:
> +Definition: Channel calibration type. If this property is specified
> +VADC will use the VDD reference(1.8V) and GND for channel
Missing whitespace before opening parenthesis.
> +calibration. If property is not found, channel will be
> +calibrated with 625mV and 1.25V reference channels.
There is a slight majority in using V instead of mv (2 : 1), so why not express
everything in V?
> +Otherwise the absolute calibration will be used.
> +
> +- qcom,hw-settle-time:
> +Usage: optional
> +Value type:
> +Definition: Time between AMUX getting configured and the ADC starting
> +conversion. Delay = 100us * (value) for value < 11, and
> +2ms * (value - 10) otherwise.
> +Valid values are: 0, 100, 200, 300, 400, 500, 600, 700, 800,
> +900 us and 1, 2, 4, 6, 8, 10 ms
> +If property is not found, channel will use 0us.
> +
> +- qcom,avg-samples:
> +Usage: optional
> +Value type:
> +Definition: Number of samples to be used for measurement.
> +Fast averaging provides the option to obtain a single measurement
> +from the ADC that is an average of multiple samples. The value
> +selected is 2^(value).
> +Valid values are: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512
> +If property is not found, 1 sample will be used.
> +
> +NOTE: At least reference channel nodes are required. The reference channels
> + might be different depending on PMIC version.
> + Reference channels per type of calibration are:
> + - absolute
> + (VADC_REF_625MV or VADC_SPARE1) and VADC_REF_1250MV
> + - ratiomatric
> + VADC_GND_REF and VADC_VDD_VADC
> +
> +Example:
> + /* VADC node */
> + pmic_vadc: vadc@3100 {
> + compatible = "qcom,spmi-vadc";
> + reg = <0x3100 0x100>;
> + interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>;
> + #address-cells = <1>;
fs/namei.c: Misuse of sequence counts?
Hi, I've been reading through the path lookup code and I believe there may have
been bugs introduced by commit 4023bfc9 ("be careful with nd->inode in
path_init() and follow_dotdot_rcu()"). And I may have found a pre-existing bug
as well.
In follow_dotdot_rcu(), said commit moved loads of the inode to just before
read_seqcount_begin(), in several instances. I don't think this is correct,
because (as I understand it) read_seqcount_begin() is opening a seq-read
critical section on the new dentry. So the inode load should come *after* it,
as in the original, to ensure the inode pointer is correctly matched with the
sequence count.
In path_init(), said commit added a call to read_seqcount_retry() after loading
the inode. I see two problems with this:
- The read_seqcount_retry() isn't needed just to load the inode pointer, so
the change doesn't seem to accomplish anything.
- If the -ECHILD code path actually runs, the reference to the 'struct file'
can be leaked.
Also: if there were actual problems that were "fixed" by this commit, I wonder
if they were/are actually caused by the fd-relative case in path_init() using:
nd->seq = __read_seqcount_begin(>path.dentry->d_seq);
instead of
nd->seq = read_seqcount_begin(>path.dentry->d_seq);
since the former is missing a memory barrier before the starting inode is
loaded.
Eric
--
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 3/8] iio: Add support for DA9150 GPADC
Hi,
I have put a few comments inline.
Adam Thomson schrieb am 23.09.2014 12:53:
> This patch adds support for DA9150 Charger & Fuel-Gauge IC GPADC.
>
> Signed-off-by: Adam Thomson
> ---
> drivers/iio/adc/Kconfig| 9 +
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/da9150-gpadc.c | 406
> +
> 3 files changed, 416 insertions(+)
> create mode 100644 drivers/iio/adc/da9150-gpadc.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 11b048a..8041347 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -127,6 +127,15 @@ config AT91_ADC
> help
> Say yes here to build support for Atmel AT91 ADC.
>
> +config DA9150_GPADC
> + tristate "Dialog DA9150 GPADC driver support"
> + depends on MFD_DA9150
> + help
> + Say yes here to build support for Dialog DA9150 GPADC.
> +
> + This driver can also be built as a module. If chosen, the module name
> + will be da9150-gpadc.
> +
> config EXYNOS_ADC
> tristate "Exynos ADC driver support"
> depends on ARCH_EXYNOS || (OF && COMPILE_TEST)
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index ad81b51..48413d2 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_AD7793) += ad7793.o
> obj-$(CONFIG_AD7887) += ad7887.o
> obj-$(CONFIG_AD799X) += ad799x.o
> obj-$(CONFIG_AT91_ADC) += at91_adc.o
> +obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
> obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
> obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
> obj-$(CONFIG_MAX1027) += max1027.o
> diff --git a/drivers/iio/adc/da9150-gpadc.c b/drivers/iio/adc/da9150-gpadc.c
> new file mode 100644
> index 000..2b83ee0
> --- /dev/null
> +++ b/drivers/iio/adc/da9150-gpadc.c
> @@ -0,0 +1,406 @@
> +/*
> + * DA9150 GPADC Driver
> + *
> + * Copyright (c) 2014 Dialog Semiconductor
> + *
> + * Author: Adam Thomson
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* Channels */
> +enum da9150_gpadc_hw_channel {
> + DA9150_GPADC_HW_CHAN_GPIOA_2V = 0,
> + DA9150_GPADC_HW_CHAN_GPIOA_2V_,
> + DA9150_GPADC_HW_CHAN_GPIOB_2V,
> + DA9150_GPADC_HW_CHAN_GPIOB_2V_,
> + DA9150_GPADC_HW_CHAN_GPIOC_2V,
> + DA9150_GPADC_HW_CHAN_GPIOC_2V_,
> + DA9150_GPADC_HW_CHAN_GPIOD_2V,
> + DA9150_GPADC_HW_CHAN_GPIOD_2V_,
> + DA9150_GPADC_HW_CHAN_IBUS_SENSE,
> + DA9150_GPADC_HW_CHAN_IBUS_SENSE_,
> + DA9150_GPADC_HW_CHAN_VBUS_DIV,
> + DA9150_GPADC_HW_CHAN_VBUS_DIV_,
> + DA9150_GPADC_HW_CHAN_ID,
> + DA9150_GPADC_HW_CHAN_ID_,
> + DA9150_GPADC_HW_CHAN_VSYS,
> + DA9150_GPADC_HW_CHAN_VSYS_,
> + DA9150_GPADC_HW_CHAN_GPIOA_6V,
> + DA9150_GPADC_HW_CHAN_GPIOA_6V_,
> + DA9150_GPADC_HW_CHAN_GPIOB_6V,
> + DA9150_GPADC_HW_CHAN_GPIOB_6V_,
> + DA9150_GPADC_HW_CHAN_GPIOC_6V,
> + DA9150_GPADC_HW_CHAN_GPIOC_6V_,
> + DA9150_GPADC_HW_CHAN_GPIOD_6V,
> + DA9150_GPADC_HW_CHAN_GPIOD_6V_,
> + DA9150_GPADC_HW_CHAN_VBAT,
> + DA9150_GPADC_HW_CHAN_VBAT_,
> + DA9150_GPADC_HW_CHAN_TBAT,
> + DA9150_GPADC_HW_CHAN_TBAT_,
> + DA9150_GPADC_HW_CHAN_TJUNC_CORE,
> + DA9150_GPADC_HW_CHAN_TJUNC_CORE_,
> + DA9150_GPADC_HW_CHAN_TJUNC_OVP,
> + DA9150_GPADC_HW_CHAN_TJUNC_OVP_,
> +};
> +
> +enum da9150_gpadc_channel {
> + DA9150_GPADC_CHAN_GPIOA = 0,
> + DA9150_GPADC_CHAN_GPIOB,
> + DA9150_GPADC_CHAN_GPIOC,
> + DA9150_GPADC_CHAN_GPIOD,
> + DA9150_GPADC_CHAN_IBUS,
> + DA9150_GPADC_CHAN_VBUS,
> + DA9150_GPADC_CHAN_ID,
> + DA9150_GPADC_CHAN_VSYS,
> + DA9150_GPADC_CHAN_VBAT,
> + DA9150_GPADC_CHAN_TBAT,
> + DA9150_GPADC_CHAN_TJUNC_CORE,
> + DA9150_GPADC_CHAN_TJUNC_OVP,
> +};
> +
> +/* Private data */
> +struct da9150_gpadc {
> + struct da9150 *da9150;
> + struct device *dev;
> +
> + struct mutex lock;
> + struct completion complete;
> +};
> +
> +
> +static irqreturn_t da9150_gpadc_irq(int irq, void *data)
> +{
> +
> + struct da9150_gpadc *gpadc = data;
> +
> + complete(>complete);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int da9150_gpadc_read_adc(struct da9150_gpadc *gpadc, int hw_chan)
> +{
> + u8 result_regs[2];
> + int result;
> +
> + mutex_lock(>lock);
> +
> + /* Set channel & enable measurement */
> + da9150_reg_write(gpadc->da9150, DA9150_GPADC_MAN,
> + (DA9150_GPADC_EN_MASK |
> + hw_chan << DA9150_GPADC_MUX_SHIFT));
> +
> + /* Consume left-over completion from a previous timeout */
>
Re: [PATCH 1/1] drivers/staging: Fixed sparse error "directive in argument list"
Hi,
Oops.. sorry for the mess then. I am still trying to get to know the
codebase. I submitted a new patch where I removed the check.
Thanks for your patience :)
Best,
Filipe
On Sat, Oct 11, 2014 at 10:49 PM, Drokin, Oleg wrote:
>
> Hello!
>
>No, it's not the way to test the kernel version, it's the way to test
> internal
>lustre version.
>Either way maintaining compatibility with Lustre 1.8 and 2.0 servers
> should not
>be important anymore, so it's fine to drop this check indeed.
>
> Bye,
> Oleg
> On Oct 11, 2014, at 5:06 PM, Filipe Gonçalves wrote:
>
>> Ah .. right! I didn't know what OBD_OCD_VERSION() was. Now I see it's
>> a way to test kernel version. I am going to submit a new patch
>> shortly.
>>
>> Thanks,
>> Filipe
>>
>> On Sat, Oct 11, 2014 at 9:15 PM, Greg KH wrote:
>>>
>>> On Sat, Oct 11, 2014 at 08:13:42PM +0100, Filipe Gonçalves wrote:
This patch fixes a sparse warning on layout.c (ptlrpc) that was caused by
having preprocessor directives in the arguments to a macro.
Signed-off-by: Filipe Gonçalves
---
drivers/staging/lustre/lustre/ptlrpc/layout.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lustre/ptlrpc/layout.c
b/drivers/staging/lustre/lustre/ptlrpc/layout.c
index 5b83371..211df78 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/layout.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/layout.c
@@ -978,10 +978,11 @@ struct req_msg_field RMF_CONN =
EXPORT_SYMBOL(RMF_CONN);
struct req_msg_field RMF_CONNECT_DATA =
+#if LUSTRE_VERSION_CODE > OBD_OCD_VERSION(2, 7, 50, 0)
DEFINE_MSGF("cdata",
RMF_F_NO_SIZE_CHECK /* we allow extra space for interop
*/,
-#if LUSTRE_VERSION_CODE > OBD_OCD_VERSION(2, 7, 50, 0)
sizeof(struct obd_connect_data),
+ lustre_swab_connect, NULL);
>>>
>>> Ick ick ick.
>>>
>>> Yeah, sparse might complain about this, but how about just properly
>>> deleting the #ifdef entirely, and not perpetuate it even more?
>>>
>>> It shouldn't be needed anymore now that the code is in the kernel tree.
>>>
>>> greg k-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: [PATCH] usb: atm: fix codestyle issues in
On Sat, Oct 11, 2014 at 10:17 PM, Greg KH wrote: > On Sat, Oct 11, 2014 at 06:02:48PM +0200, Jonas Brunsgaard wrote: >> Signed-off-by: Jonas Brunsgaard >> --- >> drivers/usb/atm/ueagle-atm.c | 95 >> >> 1 file changed, 42 insertions(+), 53 deletions(-) > > Your Subject: doesn't seem to make sense, please fix up and resend. > New patch submitted. -- 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] char: hw_random: core.c: Changed from using strncpy to strlcpy
Changed from using strncpy to strlcpy to simplify the code
Signed-off-by: Rickard Strandqvist
---
drivers/char/hw_random/core.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index aa30a25..1500cfd 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -281,7 +281,6 @@ static ssize_t hwrng_attr_available_show(struct device *dev,
char *buf)
{
int err;
- ssize_t ret = 0;
struct hwrng *rng;
err = mutex_lock_interruptible(_mutex);
@@ -289,16 +288,13 @@ static ssize_t hwrng_attr_available_show(struct device
*dev,
return -ERESTARTSYS;
buf[0] = '\0';
list_for_each_entry(rng, _list, list) {
- strncat(buf, rng->name, PAGE_SIZE - ret - 1);
- ret += strlen(rng->name);
- strncat(buf, " ", PAGE_SIZE - ret - 1);
- ret++;
+ strlcat(buf, rng->name, PAGE_SIZE);
+ strlcat(buf, " ", PAGE_SIZE);
}
- strncat(buf, "\n", PAGE_SIZE - ret - 1);
- ret++;
+ strlcat(buf, "\n", PAGE_SIZE);
mutex_unlock(_mutex);
- return ret;
+ return strlen(buf);
}
static DEVICE_ATTR(rng_current, S_IRUGO | S_IWUSR,
--
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: Removing per-task TSD? (Re: Tightening up rdpmc permissions?)
On Fri, Oct 3, 2014 at 1:06 PM, Peter Zijlstra wrote: > On Fri, Oct 03, 2014 at 09:41:30AM -0700, Andy Lutomirski wrote: >> So this is a mess. I think that any reasonable implementation of >> rdpmc permissions should be per mm, since we perf_event maps are, of >> course, per mm. >> >> Similarly, any reasonable implementation of rdtsc permissions should >> be per mm, since doing it sensibly involves telling the vdso not to >> use rdtsc, and the vdso is per mm > > So far so good. > >> Unfortunately, PR_SET_TSC is a per-thread setting. Implementing this >> correctly looks like it'll require twiddling, or at least thinking >> about, cr4 at switch_mm time *and* when switching tasks, because the >> only sensible way of granting PMC access to a running mm is to >> broadcast a function call to the cpus running that mm. > > Confused... now though. > > Any cpu can only ever run one mm at the time, and the only way to change > mm on any one cpu is switch_mm(), so having a CR4 write in switch_mm() > will DTRT, no weird broadcasts or anything else required. I have it working, with no change to TIF_NOTSC. I'm not totally thrilled by the approach, but I think it's okay, it should have no effect on any visible ABI, and it's decently fast. > > Or were you talking about doing the per mm filter while maintaining the > old TIF_NOTSC thing? Then still no broadcasts would be required I think. > >> Nonetheless, this is doable. Either there can be separate context >> switching of CR4.PCE (in switch_mm) and CR4.TSD (in switch_to), or >> there can be some crazy optimization to make it faster. > > IFF you want to retain TIF_NOTSC then yes, we'll need both or crazy. I actually think that crazy isn't so bad. switch_mm knows the task it's switching to, so it can pre-load cr4. My patch works by creating a per-cpu cr4 shadow, so pre-loading cr4 for the next task a little bit early ought to work without any expensive microcoded operations. I'll send patches reasonably soon. --Andy > >> All of this sucks, so I'll ask a normally verboten question: can we >> just remove PR_SET_TSC entirely? > > Fine with me, see more in that thread, I'll try and reply to the right > copy. -- Andy Lutomirski AMA Capital Management, LLC -- 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: rhashtable: hang while running tests on boot
On 10/11/14 at 12:09pm, Sasha Levin wrote: > On 10/11/2014 11:50 AM, Paul E. McKenney wrote: > >>> > > I am guessing that this happens only when running the resizable > >>> > > hashtable > >>> > > tests -- if that guess is incorrect, please let me know. > >> > > >> > I've seen it a few times only with rhashtable related traces, if that > >> > ever > >> > changes I'll update - but for now I think it's safe to assume it's > >> > rhashtable > >> > specific. > > Ah, so this is intermittent. Joy. > > Yup, I'm seeing it in about 10% of boot attempts. Have you ever seen any traces outside of the test_rht code? I'm trying to figure out whether it's a bug in the test code or in the hash table itself. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [3.16.1 BISECTED REGRESSION]: Simtec Entropy Key (cdc-acm) broken in 3.16
On 11 Oct 2014, Paul Martin spake thusly: > Having been privy to the firmware of the eKey, it is very simplisting, > with no implementation whatsoever of any flow control. That's what I thought. (Why would something that just provides data at a constant rate way below that of even the slowest USB bus *need* flow control?) One presumes therefore that the kernel suddenly trying to do flow control on shutdown would fubar the firmware's internal state, leading to the symptoms I see. So, the question becomes, is there a way to spot this general 'no flow control on this device' thing from the kernel side, or do we need a blacklist? Or, perhaps, if this is commonplace for cdc-acm devices, a whitelist? I can't imagine it's *that* commonplace or someone would have spotted this already in the months and months it took me to do the bisection. Maybe all non-modem cdc-acm devices should eschew flow control, or something? (This is a genuine guess and is almost certainly wrong.) -- NULL && (void) -- 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: [bisected] e341694e3eb5 netlink_lookup() rcu conversion causes latencies
On 10/11/14 at 12:32pm, Eric Dumazet wrote: > On Sat, 2014-10-11 at 10:36 +0200, Heiko Carstens wrote: > > Hi all, > > > > it just came to my attention that commit e341694e3eb5 > > "netlink: Convert netlink_lookup() to use RCU protected hash table" > > causes network latencies for me on s390. > > > > The testcase is quite simple and 100% reproducible on s390: > > > > Simply login via ssh to a remote system which has the above mentioned > > patch applied. Any action like pressing return now has significant > > latencies. Or in other words, working via such a connection becomes > > a pain ;) > > > > I haven't debugged it, however I assume the problem is that a) the > > commit introduces a synchronize_net() call und b) s390 kernels > > usually get compiled with CONFIG_HZ_100 while most other architectures > > use CONFIG_HZ_1000. > > If I change the kernel config to CONFIG_HZ_1000 the problem goes away, > > however I don't consider this a fix... > > > > Another reason why this hasn't been observed on x86 may or may not be > > that we haven't implemented CONFIG_HAVE_CONTEXT_TRACKING on s390 (yet). > > But that's just guessing... > > CC Paul and Sasha I think the issue here is obvious and a fix is on the way to move the insertion and removal to a worker to no longer require the synchronize_rcu(). What bothers me is that the synchronize_rcu() should only occur on expand/shrink and not for every table update. The default table size is 64. -- 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] Networking
This set fixes a bunch of fallout from the changes that went in during this merge window, particularly: 1) Fix fsl_pq_mdio (Claudiu Manoil) and fm10k (Pranith Kumar) build failures. 2) Several networking drivers do atomic_set() on page counts where that's not exactly legal. From Eric Dumazet. 3) Make __skb_flow_get_ports() work cleanly with unaligned data, from Alexander Duyck. 4) Fix some kernel-doc buglets in rfkill and netlabel, from Fabian Frederick. 5) Unbalanced enable_irq_wake usage in bcmgenet and systemport drivers, from Florian Fainelli. 6) pxa168_eth needs to depend on HAS_DMA, from Geert Uytterhoeven. 7) Multi-dequeue in the qdisc layer severely bypasses the fairness limits the previous code used to enforce, reintroduce in a way that at the same time doesn't compromise bulk dequeue opportunities. From Jesper Dangaard Brouer. 8) macvlan receive path unnecessarily hops through a softirq by using netif_rx() instead of netif_receive_skb(). From Jason Baron. Please pull, thanks a lot! The following changes since commit 35a9ad8af0bb0fa3525e6d0d20e32551d226f38e: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next (2014-10-08 21:40:54 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master for you to fetch changes up to 01d2d484e49e9bc0ed9b5fdaf345a0e2bf35ffed: Merge branch 'bcmgenet_systemport' (2014-10-10 15:39:22 -0400) Alexander Duyck (1): flow-dissector: Fix alignment issue in __skb_flow_get_ports Alexei Starovoitov (1): net: bpf: fix bpf syscall dependence on anon_inodes Andrea Merello (1): rtl818x_pci: fix response rate may be incorrect. Claudiu Manoil (8): net/fsl_pq_mdio: Fix asm/ucc.h compile error for ARM net/fsl_pq_mdio: Use ioread/iowrite32be() portable accessors net/fsl_pq_mdio: Replace spin_event_timeout() with arch independent gianfar: Include missing headers for ARM builds gianfar: Exclude PPC specific errata handling from ARM builds gianfar: Make MAC addr setup endian safe, cleanup gianfar: Replace spin_event_timeout() with arch independent gianfar: Replace eieio with wmb for non-PPC archs David S. Miller (9): Merge branch 'gianfar' Merge branch 'cxgb4' Merge branch 'r8152' Merge tag 'master-2014-10-08' of git://git.kernel.org/.../linville/wireless-next Merge git://git.kernel.org/.../pablo/nf-next Merge branch 'xgene' Merge branch 'macvlan' Merge branch 'net-drivers-pgcnt' Merge branch 'bcmgenet_systemport' Eric Dumazet (5): fm10k: fix race accessing page->_count igb: fix race accessing page->_count ixgbe: fix race accessing page->_count mlx4: fix race accessing page->_count net: fix races in page->_count manipulation Fabian Frederick (2): net: rfkill: kernel-doc warning fixes netlabel: kernel-doc warning fix Florian Fainelli (3): net: bcmgenet: fix off-by-one in incrementing read pointer net: bcmgenet: avoid unbalanced enable_irq_wake calls net: systemport: avoid unbalanced enable_irq_wake calls Geert Uytterhoeven (1): net: pxa168_eth: PXA168_ETH should depend on HAS_DMA Hariprasad Shenai (3): cxgb4/cxgb4vf: Updated the LSO transfer length in CPL_TX_PKT_LSO for T5 cxgb4vf: Add 40G support for cxgb4vf driver cxgb4: Wait for device to get ready before reading any register Iyappan Subramanian (6): MAINTAINERS: Update APM X-Gene section Documentation: dts: Update section header for APM X-Gene dtb: Add 10GbE node to APM X-Gene SoC device tree drivers: net: xgene: Preparing for adding 10GbE support drivers: net: xgene: Add 10GbE support drivers: net: xgene: Add 10GbE ethtool support Jesper Dangaard Brouer (1): net_sched: restore qdisc quota fairness limits after bulk dequeue John W. Linville (1): Merge branch 'master' of git://git.kernel.org/.../linville/wireless LEROY Christophe (1): net: fs_enet: error: 'SCCE_ENET_TXF' undeclared Larry Finger (1): rtlwifi: Fix possible unaligned array in ether_addr_copy() Li RongQing (2): Documentation: replace __sk_run_filter with __bpf_prog_run net: filter: fix the comments Marek Puzyniak (1): ath9k_htc: avoid kernel panic in ath9k_hw_reset Masanari Iida (1): net: Missing @ before descriptions cause make xmldocs warning Pablo Neira Ayuso (2): netfilter: kill nf_send_reset6() from include/net/netfilter/ipv6/nf_reject.h netfilter: fix wrong arithmetics regarding NFT_REJECT_ICMPX_MAX Pranith Kumar (1): networking: fm10k: Fix build failure Sascha Hauer (1): net/phy: micrel: Add clock support for KSZ8021/KSZ8031 Sujith Manoharan (3): ath: Fix smatch warning ath9k: Fix crash in MCC mode ath9k: Fix sequence number
[PATCH v2] gpu: drm: drm_dp_mst_topology.c: Fix improper use of strncat
Fixed wrong usage of strncat, switched to strlcpy.
While sending the string size to function to reduce
the potential for misuse in future.
Signed-off-by: Rickard Strandqvist
---
drivers/gpu/drm/drm_dp_mst_topology.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index ac3c273..2a146d1 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -995,19 +995,20 @@ static void drm_dp_check_port_guid(struct
drm_dp_mst_branch *mstb,
static void build_mst_prop_path(struct drm_dp_mst_port *port,
struct drm_dp_mst_branch *mstb,
- char *proppath)
+ char *proppath,
+ size_t proppath_size)
{
int i;
char temp[8];
- snprintf(proppath, 255, "mst:%d", mstb->mgr->conn_base_id);
+ snprintf(proppath, proppath_size, "mst:%d", mstb->mgr->conn_base_id);
for (i = 0; i < (mstb->lct - 1); i++) {
int shift = (i % 2) ? 0 : 4;
int port_num = mstb->rad[i / 2] >> shift;
- snprintf(temp, 8, "-%d", port_num);
- strncat(proppath, temp, 255);
+ snprintf(temp, sizeof(temp), "-%d", port_num);
+ strlcat(proppath, temp, proppath_size);
}
- snprintf(temp, 8, "-%d", port->port_num);
- strncat(proppath, temp, 255);
+ snprintf(temp, sizeof(temp), "-%d", port->port_num);
+ strlcat(proppath, temp, proppath_size);
}
static void drm_dp_add_port(struct drm_dp_mst_branch *mstb,
@@ -1078,7 +1079,7 @@ static void drm_dp_add_port(struct drm_dp_mst_branch
*mstb,
if (created && !port->input) {
char proppath[255];
- build_mst_prop_path(port, mstb, proppath);
+ build_mst_prop_path(port, mstb, proppath, sizeof(proppath));
port->connector = (*mstb->mgr->cbs->add_connector)(mstb->mgr,
port, proppath);
}
--
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: [PATCH 1/1] drivers/staging: Fixed sparse error "directive in argument list"
Hello!
No, it's not the way to test the kernel version, it's the way to test
internal
lustre version.
Either way maintaining compatibility with Lustre 1.8 and 2.0 servers should
not
be important anymore, so it's fine to drop this check indeed.
Bye,
Oleg
On Oct 11, 2014, at 5:06 PM, Filipe Gonçalves wrote:
> Ah .. right! I didn't know what OBD_OCD_VERSION() was. Now I see it's
> a way to test kernel version. I am going to submit a new patch
> shortly.
>
> Thanks,
> Filipe
>
> On Sat, Oct 11, 2014 at 9:15 PM, Greg KH wrote:
>>
>> On Sat, Oct 11, 2014 at 08:13:42PM +0100, Filipe Gonçalves wrote:
>>> This patch fixes a sparse warning on layout.c (ptlrpc) that was caused by
>>> having preprocessor directives in the arguments to a macro.
>>>
>>> Signed-off-by: Filipe Gonçalves
>>> ---
>>> drivers/staging/lustre/lustre/ptlrpc/layout.c | 7 +--
>>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/staging/lustre/lustre/ptlrpc/layout.c
>>> b/drivers/staging/lustre/lustre/ptlrpc/layout.c
>>> index 5b83371..211df78 100644
>>> --- a/drivers/staging/lustre/lustre/ptlrpc/layout.c
>>> +++ b/drivers/staging/lustre/lustre/ptlrpc/layout.c
>>> @@ -978,10 +978,11 @@ struct req_msg_field RMF_CONN =
>>> EXPORT_SYMBOL(RMF_CONN);
>>>
>>> struct req_msg_field RMF_CONNECT_DATA =
>>> +#if LUSTRE_VERSION_CODE > OBD_OCD_VERSION(2, 7, 50, 0)
>>> DEFINE_MSGF("cdata",
>>> RMF_F_NO_SIZE_CHECK /* we allow extra space for interop */,
>>> -#if LUSTRE_VERSION_CODE > OBD_OCD_VERSION(2, 7, 50, 0)
>>> sizeof(struct obd_connect_data),
>>> + lustre_swab_connect, NULL);
>>
>> Ick ick ick.
>>
>> Yeah, sparse might complain about this, but how about just properly
>> deleting the #ifdef entirely, and not perpetuate it even more?
>>
>> It shouldn't be needed anymore now that the code is in the kernel tree.
>>
>> greg k-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/
[PATCH v2] usb: atm: fix style issues
Signed-off-by: Jonas Brunsgaard
---
drivers/usb/atm/ueagle-atm.c | 95
1 file changed, 42 insertions(+), 53 deletions(-)
diff --git a/drivers/usb/atm/ueagle-atm.c b/drivers/usb/atm/ueagle-atm.c
index 5a45937..eedb217 100644
--- a/drivers/usb/atm/ueagle-atm.c
+++ b/drivers/usb/atm/ueagle-atm.c
@@ -173,10 +173,10 @@ struct uea_softc {
const struct firmware *dsp_firm;
struct urb *urb_int;
- void (*dispatch_cmv) (struct uea_softc *, struct intr_pkt *);
- void (*schedule_load_page) (struct uea_softc *, struct intr_pkt *);
- int (*stat) (struct uea_softc *);
- int (*send_cmvs) (struct uea_softc *);
+ void (*dispatch_cmv)(struct uea_softc *, struct intr_pkt *);
+ void (*schedule_load_page)(struct uea_softc *, struct intr_pkt *);
+ int (*stat)(struct uea_softc *);
+ int (*send_cmvs)(struct uea_softc *);
/* keep in sync with eaglectl */
struct uea_stats {
@@ -576,8 +576,7 @@ static int annex[NB_MODEM];
module_param(debug, uint, 0644);
MODULE_PARM_DESC(debug, "module debug level (0=off,1=on,2=verbose)");
module_param_array(altsetting, uint, NULL, 0644);
-MODULE_PARM_DESC(altsetting, "alternate setting for incoming traffic: 0=bulk, "
-"1=isoc slowest, ... , 8=isoc fastest (default)");
+MODULE_PARM_DESC(altsetting, "alternate setting for incoming traffic: 0=bulk,
1=isoc slowest, ... , 8=isoc fastest (default)");
module_param_array(sync_wait, bool, NULL, 0644);
MODULE_PARM_DESC(sync_wait, "wait the synchronisation before starting ATM");
module_param_array(cmv_file, charp, NULL, 0644);
@@ -686,8 +685,7 @@ static void uea_upload_pre_firmware(const struct firmware
*fw_entry,
ret = uea_send_modem_cmd(usb, add, len, pfw + 3);
if (ret < 0) {
- uea_err(usb, "uploading firmware data failed "
- "with error %d\n", ret);
+ uea_err(usb, "uploading firmware data failed with error
%d\n", ret);
goto err;
}
pfw += len + 3;
@@ -829,6 +827,7 @@ static int check_dsp_e4(const u8 *dsp, int len)
for (i = 0; i < E4_MAX_PAGE_NUMBER; i++) {
struct block_index *blockidx;
u8 blockno = p->page_number_to_block_index[i];
+
if (blockno >= E4_NO_SWAPPAGE_HEADERS)
continue;
@@ -1040,10 +1039,9 @@ static void __uea_load_page_e4(struct uea_softc *sc, u8
pageno, int boot)
bi.dwAddress = cpu_to_be32(le32_to_cpu(blockidx->PageAddress));
uea_dbg(INS_TO_USBDEV(sc),
- "sending block %u for DSP page "
- "%u size %u address %x\n",
- blockno, pageno, blocksize,
- le32_to_cpu(blockidx->PageAddress));
+ "sending block %u for DSP page %u size %u
address %x\n",
+ blockno, pageno, blocksize,
+ le32_to_cpu(blockidx->PageAddress));
/* send block info through the IDMA pipe */
if (uea_idma_write(sc, , E4_BLOCK_INFO_SIZE))
@@ -1060,7 +1058,6 @@ static void __uea_load_page_e4(struct uea_softc *sc, u8
pageno, int boot)
bad:
uea_err(INS_TO_USBDEV(sc), "sending DSP block %u failed\n", blockno);
- return;
}
static void uea_load_page_e4(struct work_struct *work)
@@ -1084,8 +1081,7 @@ static void uea_load_page_e4(struct work_struct *work)
p = (struct l1_code *) sc->dsp_firm->data;
if (pageno >= le16_to_cpu(p->page_header[0].PageNumber)) {
- uea_err(INS_TO_USBDEV(sc), "invalid DSP "
- "page %u requested\n", pageno);
+ uea_err(INS_TO_USBDEV(sc), "invalid DSP page %u requested\n",
pageno);
return;
}
@@ -1180,8 +1176,8 @@ static int uea_cmv_e1(struct uea_softc *sc,
int ret;
uea_enters(INS_TO_USBDEV(sc));
- uea_vdbg(INS_TO_USBDEV(sc), "Function : %d-%d, Address : %c%c%c%c, "
- "offset : 0x%04x, data : 0x%08x\n",
+ uea_vdbg(INS_TO_USBDEV(sc),
+ "Function : %d-%d, Address : %c%c%c%c, offset : 0x%04x,
data : 0x%08x\n",
E1_FUNCTION_TYPE(function),
E1_FUNCTION_SUBTYPE(function),
E1_GETSA1(address), E1_GETSA2(address),
@@ -1220,10 +1216,10 @@ static int uea_cmv_e4(struct uea_softc *sc,
uea_enters(INS_TO_USBDEV(sc));
memset(, 0, sizeof(cmv));
- uea_vdbg(INS_TO_USBDEV(sc), "Function : %d-%d, Group : 0x%04x, "
-"Address : 0x%04x, offset : 0x%04x, data : 0x%08x\n",
-E4_FUNCTION_TYPE(function), E4_FUNCTION_SUBTYPE(function),
-group, address, offset, data);
+
[PATCH 1/1] drivers/staging: Removed unnecessary check for LUSTRE_VERSION_CODE
From: Filipe Gonçalves
Given that this code is now part of the kernel tree, the #ifdef directive
comparing LUSTRE_VERSION_CODE to the kernel version is no longer needed.
As a side effect, this will also remove the sparse error "directive in argument
list".
Signed-off-by: Filipe Gonçalves
---
drivers/staging/lustre/lustre/ptlrpc/layout.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/staging/lustre/lustre/ptlrpc/layout.c
b/drivers/staging/lustre/lustre/ptlrpc/layout.c
index 5b83371..78364ec 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/layout.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/layout.c
@@ -980,18 +980,7 @@ EXPORT_SYMBOL(RMF_CONN);
struct req_msg_field RMF_CONNECT_DATA =
DEFINE_MSGF("cdata",
RMF_F_NO_SIZE_CHECK /* we allow extra space for interop */,
-#if LUSTRE_VERSION_CODE > OBD_OCD_VERSION(2, 7, 50, 0)
sizeof(struct obd_connect_data),
-#else
-/* For interoperability with 1.8 and 2.0 clients/servers.
- * The RPC verification code allows larger RPC buffers, but not
- * smaller buffers. Until we no longer need to keep compatibility
- * with older servers/clients we can only check that the buffer
- * size is at least as large as obd_connect_data_v1. That is not
- * not in itself harmful, since the chance of just corrupting this
- * field is low. See JIRA LU-16 for details. */
- sizeof(struct obd_connect_data_v1),
-#endif
lustre_swab_connect, NULL);
EXPORT_SYMBOL(RMF_CONNECT_DATA);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 2/2] kernel: power: Drop pm_poweroff_prepare
The only user of pm_poweroff_prepare was acpi, which has been converted to use
a syscore callback. Drop pm_poweroff_prepare as it is no longer necessary.
Cc: Rafael J. Wysocki
Cc: Len Brown
Cc: Pavel Machek
Signed-off-by: Guenter Roeck
---
include/linux/pm.h | 1 -
kernel/reboot.c| 8
2 files changed, 9 deletions(-)
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 383fd68..333506e 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -32,7 +32,6 @@
* Callbacks for platform drivers to implement.
*/
extern void (*pm_power_off)(void);
-extern void (*pm_power_off_prepare)(void);
struct device; /* we have a circular dep with device.h */
#ifdef CONFIG_VT_CONSOLE_SLEEP
diff --git a/kernel/reboot.c b/kernel/reboot.c
index 5925f5a..5ad4f0b 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -44,12 +44,6 @@ int reboot_cpu;
enum reboot_type reboot_type = BOOT_ACPI;
int reboot_force;
-/*
- * If set, this is used for preparing the system to power off.
- */
-
-void (*pm_power_off_prepare)(void);
-
/**
* emergency_restart - reboot the system
*
@@ -257,8 +251,6 @@ EXPORT_SYMBOL_GPL(kernel_halt);
void kernel_power_off(void)
{
kernel_shutdown_prepare(SYSTEM_POWER_OFF);
- if (pm_power_off_prepare)
- pm_power_off_prepare();
migrate_to_reboot_cpu();
syscore_shutdown();
pr_emerg("Power down\n");
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 1/2] acpi: Use syscore instead of pm_power_off_prepare to prepare for poweroff
The syscore shutdown callback seems to be perfectly suited to prepare for system
poweroff. Use it instead of pm_power_off_prepare.
Cc: Rafael J. Wysocki
Cc: Len Brown
Signed-off-by: Guenter Roeck
---
drivers/acpi/sleep.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index 05a31b5..e03c74d 100644
--- a/drivers/acpi/sleep.c
+++ b/drivers/acpi/sleep.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -820,13 +821,23 @@ int acpi_suspend(u32 acpi_state)
return -EINVAL;
}
-static void acpi_power_off_prepare(void)
+static void acpi_shutdown(void)
{
- /* Prepare to power off the system */
- acpi_sleep_prepare(ACPI_STATE_S5);
- acpi_disable_all_gpes();
+ switch (system_state) {
+ case SYSTEM_POWER_OFF:
+ /* Prepare to power off the system */
+ acpi_sleep_prepare(ACPI_STATE_S5);
+ acpi_disable_all_gpes();
+ break;
+ default:
+ break;
+ }
}
+static struct syscore_ops acpi_syscore_ops = {
+ .shutdown = acpi_shutdown,
+};
+
static void acpi_power_off(void)
{
/* acpi_sleep_prepare(ACPI_STATE_S5) should have already been called */
@@ -850,7 +861,7 @@ int __init acpi_sleep_init(void)
if (acpi_sleep_state_supported(ACPI_STATE_S5)) {
sleep_states[ACPI_STATE_S5] = 1;
- pm_power_off_prepare = acpi_power_off_prepare;
+ register_syscore_ops(_syscore_ops);
pm_power_off = acpi_power_off;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 0/2] kernel: Drop pm_poweroff_prepare
While working on the poweroff handler implementation, I also started looking into pm_power_off_prepare. Ultimately, I concluded that it is not really necessary, and that it would be easy to remove. The first patch in this series converts acpi to use a syscore callback instead of setting pm_power_off_prepare. Since acpi is the only user of pm_power_off_prepare, it is no longer used and removed with the second patch. Removing pm_power_off_prepare streamlines poweroff handling and makes it more uniform, so I think its removal would be worthwhile to consider. I am sending the series as RFC since I am not sure if I may be missing something. Compile tested only at this time; I'll do more testing if this sounds like a reasonable thing to do. On a side note, I don't see any callers of acpi_suspend(). I actually removed it as an experiment, and at least x86_64:allmodconfig still compiles. Can it be removed ? -- 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] drop owner assignment from platform_drivers
On Sat, Oct 11, 2014 at 06:56:51PM +0200, Wolfram Sang wrote: > > > > You got me wondering, though, that it could not be correct to call > > > platform_driver_register() from the platform core instead of module > > > init. I will check tomorrow. Still, this would be a bug independent of > > > my series. Although I'd need to respin it if platform_driver_probe() > > > needed a fix. > > > > Right, this seems to be a preexisting bug. platform_create_bundle > > and platform_driver_probe will both overwrite the .owner field with > > NULL since they live in builtin code. They need to be replaced with > > __platform_driver_probe and __platform_driver_register that both > > take an extra owner argument passed down from the caller in the driver > > module. > > Yeah, that would be one solution. However, my personal favourite would > meanwhile be to revert the commit that Russell mentioned. I think it is > cleaner to have the owner explicitly set in the module rather than > hidden away by a function call. However, grepping through include/linux, > there are a few subsystems hiding it this way. So, it is a pattern > somewhow. Oh well... The pattern is to not have to manually set MODULE_OWNER, and have the pre-processor do it for you, otherwise you will forget or get it wrong. That is why I accepted this patch to the platform driver interface, as it is in line with many other bus driver apis (pci, usb, etc.). I missed the one code path you pointed out, and that should be fixed, but that doesn't mean that the original patch should be reverted, as it is the way we want things to be, let's just fix up the bug and move on. And again, may I just say how much I hate the platform driver code, one of these days I'm going to lock myself in a room for a week and figure out a way to just delete that stuff... greg k-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: [PATCH] ARM: keystone: add bus notifier to set dma_pfn_offset for pci devices
On Friday 10 October 2014 20:04:57 Santosh Shilimkar wrote: > On 10/10/14 5:37 PM, Murali Karicheri wrote: > > Based on this, dma configuration parameters get set for the device which > > is probed through DT. > > > > As PCI devices are attached to the PCI bus during scan, and we don't > > have DT nodes, we could use similar mechanism to pass the dma-range info > > from parent host platform device to the PCI devices by adding an > > of_pci_dma_configure() API and hook it to the PCI probe path some where? > > Please comment on this so that I can work on the right solution to > > address this issue for Keystone. > > > Adding the DT node parsing code in PCI bus probe path is the right way > to go about it. You could re-use some of the helpers from dma parsing > code. > > I let Arnd comment if he disagrees, otherwise I suggest to create an > RFC patch and post it on the list. We can take it from there. Yes, I think that is the correct way forward, we need this anyway to handle IOMMUs correctly, following the patches that Will Deacon did for platform device IOMMU configuration. > That also reminded me xhci host code issue with dma-ranges since the > devices are manually created there. I will review that thread as > well after this merge window. Right, manually created devices are always problematic, you should try to avoid those. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/3] scsi: Add Hyper-V logical block provisioning quirks
> On the current release of Windows (windows 10), we are advertising SPC3
> compliance.
> We are ok with declaring compliance to SPC3 in our drivers.
If you are going to declare SPC3 compliance in the drivers, are you going to
put in
checks to ensure that SPC-3 compliance doesn't get accidentally enabled for
hypervisors below
Win10?
I do know for a fact that Ubuntu's kernels already force SPC3 compliance to
enable specific
features such as TRIM on earlier versions of Hyper-V (Namely Hyper-V 2012 and
2012 R2).
--Jeff
> Regards,
>
> K. Y
>
>
> NryزXvؖ){nlj{zX}zj:v zZzf~zwڢ)jyA
>
> i
Re: [PATCH 10/12] usb: musb: ux500_dma: use dmaengine_xxx() APIs
On Sat, Oct 11, 2014 at 09:10:38PM +0530, Vinod Koul wrote: > The drivers should use dmaengine_terminate_all() or dmaengine_slave_config() > API instead of accessing the device_control which will be deprecated soon > > Signed-off-by: Vinod Koul Acked-by: Greg Kroah-Hartman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/12] serial: sh-sci: use dmaengine_terminate_all() API
On Sat, Oct 11, 2014 at 09:10:37PM +0530, Vinod Koul wrote: > The drivers should use dmaengine_terminate_all() API instead of > accessing the device_control which will be deprecated soon > > Signed-off-by: Vinod Koul Acked-by: Greg Kroah-Hartman -- 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] usb: serial: Fix indentation style issue
On Sat, Oct 11, 2014 at 08:36:33AM -0700, Joe Perches wrote:
> On Sat, 2014-10-11 at 07:20 -0700, Greg KH wrote:
> > On Sat, Oct 11, 2014 at 03:49:43PM +0200, Philip Munksgaard wrote:
> > > Fix a style issue
> []
> > > diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
> []
> > > @@ -1616,7 +1616,7 @@ static const struct usb_device_id option_ids[] = {
> > > { USB_DEVICE(TLAYTECH_VENDOR_ID, TLAYTECH_PRODUCT_TEU800) },
> > > { USB_DEVICE(LONGCHEER_VENDOR_ID, FOUR_G_SYSTEMS_PRODUCT_W14),
> > > .driver_info = (kernel_ulong_t)_g_w14_blacklist
> > > - },
> > > + },
> >
> > Why not fix the same 'space' issue on the line before this at the same
> > time?
>
> I think there is no space issue on the previous line.
> What do you see Greg?
I see 'space space tab', just like this line that is being changed.
/me hands Joe a real editor.
--
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] debugfs: add helper function to create device related seq_file
On Sat, Oct 11, 2014 at 06:09:47PM +0200, Arend van Spriel wrote: > On 10/11/14 18:01, Arend van Spriel wrote: > >This patch adds a helper function that simplifies adding a > >sequence file for device drivers. The calling device driver > >needs to provide a read function and a device pointer. The > >field struct seq_file::private will reference the device > >pointer upon call to the read function so the driver can > >obtain his data from it and do its seq_printf() calls. > > Maybe should have made this RFC first. Anyways, it is intended for 3.19, > although I don't mind if it would end up in 3.18 :-p It's too late for 3.18, sorry. -- 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] usb: atm: fix codestyle issues in
On Sat, Oct 11, 2014 at 06:02:48PM +0200, Jonas Brunsgaard wrote: > Signed-off-by: Jonas Brunsgaard > --- > drivers/usb/atm/ueagle-atm.c | 95 > > 1 file changed, 42 insertions(+), 53 deletions(-) Your Subject: doesn't seem to make sense, please fix up and resend. -- 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] debugfs: add helper function to create device related seq_file
On Sat, Oct 11, 2014 at 06:01:55PM +0200, Arend van Spriel wrote: > This patch adds a helper function that simplifies adding a > sequence file for device drivers. The calling device driver > needs to provide a read function and a device pointer. The > field struct seq_file::private will reference the device > pointer upon call to the read function so the driver can > obtain his data from it and do its seq_printf() calls. > > Signed-off-by: Arend van Spriel > --- > fs/debugfs/file.c | 54 > + > include/linux/debugfs.h | 16 ++- > 2 files changed, 69 insertions(+), 1 deletion(-) Do you have some kernel code pending that needs this change? Or can existing users be moved to it, saving them code? -- 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/1] drivers/staging: Fixed sparse error "directive in argument list"
On Sat, Oct 11, 2014 at 08:13:42PM +0100, Filipe Gonçalves wrote:
> This patch fixes a sparse warning on layout.c (ptlrpc) that was caused by
> having preprocessor directives in the arguments to a macro.
>
> Signed-off-by: Filipe Gonçalves
> ---
> drivers/staging/lustre/lustre/ptlrpc/layout.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/lustre/lustre/ptlrpc/layout.c
> b/drivers/staging/lustre/lustre/ptlrpc/layout.c
> index 5b83371..211df78 100644
> --- a/drivers/staging/lustre/lustre/ptlrpc/layout.c
> +++ b/drivers/staging/lustre/lustre/ptlrpc/layout.c
> @@ -978,10 +978,11 @@ struct req_msg_field RMF_CONN =
> EXPORT_SYMBOL(RMF_CONN);
>
> struct req_msg_field RMF_CONNECT_DATA =
> +#if LUSTRE_VERSION_CODE > OBD_OCD_VERSION(2, 7, 50, 0)
> DEFINE_MSGF("cdata",
> RMF_F_NO_SIZE_CHECK /* we allow extra space for interop */,
> -#if LUSTRE_VERSION_CODE > OBD_OCD_VERSION(2, 7, 50, 0)
> sizeof(struct obd_connect_data),
> + lustre_swab_connect, NULL);
Ick ick ick.
Yeah, sparse might complain about this, but how about just properly
deleting the #ifdef entirely, and not perpetuate it even more?
It shouldn't be needed anymore now that the code is in the kernel tree.
greg k-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: [3.16.1 BISECTED REGRESSION]: Simtec Entropy Key (cdc-acm) broken in 3.16
Having been privy to the firmware of the eKey, it is very simplisting, with no implementation whatsoever of any flow control. -- Paul Martin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/3] scsi: Add Hyper-V logical block provisioning quirks
> -Original Message- > From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] > Sent: Saturday, October 11, 2014 10:42 AM > To: Christoph Hellwig > Cc: Sitsofe Wheeler; KY Srinivasan; Haiyang Zhang; Christoph Hellwig; Hannes > Reinecke; linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org; > de...@linuxdriverproject.org > Subject: Re: [PATCH 0/3] scsi: Add Hyper-V logical block provisioning quirks > > On Sat, 2014-10-11 at 10:39 -0700, Christoph Hellwig wrote: > > On Fri, Oct 10, 2014 at 08:49:01AM +0100, Sitsofe Wheeler wrote: > > > Microsoft Hyper-V virtual disks currently only claim SPC-2 > > > compliance even though they implement post SPC-2 features (such as > > > thin > > > provisioning) which means the Linux kernel does not go on to test > > > for those features even though they are advertised. > > > > > > A previous patch attempted to add a quirk to workaround this but the > > > quirk was only enabled after the features had been scanned for, > > > wouldn't work for "small" disks and would quirk on all Hyper-V SCSI > > > devices (e.g. passthrough disks). > > > > > > The new patches partially revert the previous effort, add the quirk > > > in a more traditional manner to only Hyper-V virtual disks and work > > > on small virtual disks. > > > > This seems like might want a quirk to simply "force" a SPC3 compliance > > level? > > This was initially suggested, but rejected by Microsoft because of other > problems advertising SPC-3 compliance brings. Perhaps the hyper-v > emulator has matured sufficiently that it will now work OK? James, On the current release of Windows (windows 10), we are advertising SPC3 compliance. We are ok with declaring compliance to SPC3 in our drivers. Regards, K. Y
Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket
On Saturday, October 11, 2014 11:42:06 AM Steve Grubb wrote: > On Tue, 07 Oct 2014 18:06:51 -0400 > > Paul Moore wrote: > > On Tuesday, October 07, 2014 03:39:51 PM Richard Guy Briggs wrote: > > > I also thought of moving audit_log_task() from auditsc.c to audit.c > > > and using that. For that matter, both audit_log_task() and > > > audit_log_task_info() could use audit_log_session_info(), but they > > > are in slightly different order of keywords which will upset > > > sgrubb's parser. > > > > A bit of an aside from the patch, but in my opinion the parser should > > be made a bit more robust so that it can handle fields in any > > particular order. I agree that having fields in a "canonical > > ordering" is helpful, both for tools and people, but the tools > > shouldn't require it in my opinion. > > > > Steve, why exactly can't the userspace parser handle fields in any > > order? How difficult would it be to fix? > > The issue is that people that really use audit, really get vast > quanities of logs. The tools expect things in a specific order so that > it can pick things out of events as quickly as possible. IOW, it > knows when it can discard the line because its grabbed everything it > needs. A casual audit user would never see this. I'm really optimizing > for the people whose use ausearch and it takes 10 minutes to run. I understand you are catering to the "power user" here, but I don't see that as an excuse for not being able to parse well formed name/value audit record string if the order isn't exactly what you expect. I believe this will only become more and more of a problem as things move forward. I think this is something we need to fix soon. Steve, would you be willing to fix the audit userspace parser so it can handle fields in an arbitrary order? If not, would you be willing to accept patches for the userspace that would accomplish this? -- paul moore security and virtualization @ redhat -- 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: [Bulk] Re: [3.16-rcX][pciehp][radeon] PCIe HotPlug conflicts with radeon GPU
On September 11, 2014 04:26:21 PM Bjorn Helgaas wrote: > [+cc linux-pci] > > On Sat, Aug 2, 2014 at 10:02 AM, Shawn Starr wrote: > > Hello devs, > > > > There are two issues I am encountering with the PCIe Hotplug driver on my > > Lenovo Laptop (W500). I note this goes back further than 3.15. > > > > It is noted here: > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id= > > f244d8b623dae7a7bc695b0336f67729b95a9736 > > https://bugzilla.kernel.org/show_bug.cgi?id=79701 > > > > And my open bug here: > > https://bugzilla.kernel.org/show_bug.cgi?id=77261 > > > > 1) If I enable the device to use both the integrated and discrete GPU, > > pciehp will decide to force unload radeon because it puts itself into a > > power saving state, fails back to the Intel integrated GPU in this case > > unless I tell radeon.ko to runpm=0 (no power management, then pciehp wont > > touch it). > > > > 2) If the Radeon GPU resets and you use pci_reset=1 for kernel module > > option, pciehp decides to force unload radeon even though the GPU is > > trying to setup after failing. > > > > Kernel I am using right now: 3.16.0-0.rc7.git3.1.fc21.x86_64 (about to > > boot into snapshot kernel-core-3.16.0-0.rc7.git4.1.fc21.x86_64) > Hi Shawn, > > Thanks for the report and sorry that it got dropped. But I see you're > cc'd on https://bugzilla.kernel.org/show_bug.cgi?id=79701, so you've > probably seen the work there. If you can try out the patches I just > posted, that would be great. > > Bjorn Hi Bjorn, For #1) This is fixed in linux-next (tracking 3.18.0-0.rc0.git1.2.fc22.1.x86_64 nondebug kernel for Fedora). PCIe HotPlug no longer unloads radeon. For this bugzilla report we can close it. #2) This still has weird results however, radeon.hard_reset=1 is experimental and while it attempts to reset GPU, PCIe HotPlug seems to interact in this. This can be tested by adding to grub command line radeon.hard_reset=1. When X has started up, trigger a reset by cat /sys/kernel/debug/dri/#/radeon_gpu_reset. It will output 0, cat it again will show 1. Attempt to drag a window. The this will trigger a GPU reset, but fail to recover, its unknown if PCIe HotPlug is preventing a proper reset or not but there is pciehp calls in the stack trace. Thanks, Shawn -- 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/
Please reply
Dear Sir/Madam, Here is a pdf attachment of my proposal to you. Please read and reply I would be grateful. Jose Calvache -- 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: [bisected] e341694e3eb5 netlink_lookup() rcu conversion causes latencies
On Sat, 2014-10-11 at 10:36 +0200, Heiko Carstens wrote: > Hi all, > > it just came to my attention that commit e341694e3eb5 > "netlink: Convert netlink_lookup() to use RCU protected hash table" > causes network latencies for me on s390. > > The testcase is quite simple and 100% reproducible on s390: > > Simply login via ssh to a remote system which has the above mentioned > patch applied. Any action like pressing return now has significant > latencies. Or in other words, working via such a connection becomes > a pain ;) > > I haven't debugged it, however I assume the problem is that a) the > commit introduces a synchronize_net() call und b) s390 kernels > usually get compiled with CONFIG_HZ_100 while most other architectures > use CONFIG_HZ_1000. > If I change the kernel config to CONFIG_HZ_1000 the problem goes away, > however I don't consider this a fix... > > Another reason why this hasn't been observed on x86 may or may not be > that we haven't implemented CONFIG_HAVE_CONTEXT_TRACKING on s390 (yet). > But that's just guessing... CC Paul and Sasha -- 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: RCU bug with v3.17-rc3 ?
On 10/10/2014 08:44 PM, Nathan Lynch wrote:
> On 10/10/2014 11:25 AM, Russell King - ARM Linux wrote:
>>
>> Right, so GCC 4.8.{1,2} are totally unsuitable for kernel building (and
>> it seems that this has been known about for some time.)
>
> Looking at http://gcc.gnu.org/PR58854 it seems that all 4.8.x for x < 3
> are affected, as well as 4.9.0.
Correction -- 4.9.0 has this fixed, even though the GCC PR shows it as a
"known to fail" version.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] drivers/staging: Fixed sparse error "directive in argument list"
This patch fixes a sparse warning on layout.c (ptlrpc) that was caused by
having preprocessor directives in the arguments to a macro.
Signed-off-by: Filipe Gonçalves
---
drivers/staging/lustre/lustre/ptlrpc/layout.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lustre/ptlrpc/layout.c
b/drivers/staging/lustre/lustre/ptlrpc/layout.c
index 5b83371..211df78 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/layout.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/layout.c
@@ -978,10 +978,11 @@ struct req_msg_field RMF_CONN =
EXPORT_SYMBOL(RMF_CONN);
struct req_msg_field RMF_CONNECT_DATA =
+#if LUSTRE_VERSION_CODE > OBD_OCD_VERSION(2, 7, 50, 0)
DEFINE_MSGF("cdata",
RMF_F_NO_SIZE_CHECK /* we allow extra space for interop */,
-#if LUSTRE_VERSION_CODE > OBD_OCD_VERSION(2, 7, 50, 0)
sizeof(struct obd_connect_data),
+ lustre_swab_connect, NULL);
#else
/* For interoperability with 1.8 and 2.0 clients/servers.
* The RPC verification code allows larger RPC buffers, but not
@@ -990,9 +991,11 @@ struct req_msg_field RMF_CONNECT_DATA =
* size is at least as large as obd_connect_data_v1. That is not
* not in itself harmful, since the chance of just corrupting this
* field is low. See JIRA LU-16 for details. */
+ DEFINE_MSGF("cdata",
+ RMF_F_NO_SIZE_CHECK /* we allow extra space for interop */,
sizeof(struct obd_connect_data_v1),
-#endif
lustre_swab_connect, NULL);
+#endif
EXPORT_SYMBOL(RMF_CONNECT_DATA);
struct req_msg_field RMF_DLM_REQ =
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/12] rtc: omap: fixes and power-off feature
* Johan Hovold [141011 02:42]: > On Fri, Oct 10, 2014 at 12:54:22PM -0500, Felipe Balbi wrote: > > > > is this power-off feature "RTC-only mode" ? > > Yes, I believe so, at least as long as RTC power is maintained. The > pmic_power_en pin can otherwise still be used to power off. > > On the BeagleBone the PMIC can be configured to enter OFF or SLEEP mode > on power off, where the latter (and default) mode keeps the RTC power > supply enabled. > > Thanks for the fast review, Felipe. Great :) I assume adding the regulator support to this driver should also help in the 35xx case? That is assuming that RTC power can be configured as a Linux regulator on 35xx. Regards, Tony -- 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 1/2] kconfig: fix bad syntactic transformation in expr.c
On Mon, 2014-09-22 at 19:13 +0200, Martin Walch wrote:
> Fix it by removing expr_eliminate_dups2() and the functions that have no use
> anywhere else: expr_extract_eq_and(), expr_extract_eq_or(),
> and expr_extract_eq() from scripts/kconfig/expr.[ch]
>
> Currently the bug is not triggered in mainline, so this patch does not modify
> the configuration space there.
Would I be whining if I'd complained about the lack of documentation for
expr_eliminate_dups(), expr_eliminate_dups1(), and
expr_eliminate_dups2()?
So, I've put in these two calls of fprintf():
@@ -579,6 +606,7 @@ static void expr_eliminate_dups2(enum expr_type type,
struct expr **ep1, struct
tmp2 = expr_copy(e2);
tmp = expr_extract_eq_and(, );
if (expr_is_yes(tmp1)) {
+ fprintf(stderr, "%s:%d:\n", __func__, __LINE__);
expr_free(e1);
e1 = expr_alloc_symbol(_no);
trans_count++;
@@ -594,6 +622,7 @@ static void expr_eliminate_dups2(enum expr_type type,
struct expr **ep1, struct
tmp2 = expr_copy(e2);
tmp = expr_extract_eq_or(, );
if (expr_is_no(tmp1)) {
+ fprintf(stderr, "%s:%d:\n", __func__, __LINE__);
expr_free(e1);
e1 = expr_alloc_symbol(_yes);
trans_count++;
None of the 500+ defconfig files in next-20141010 triggered those
fprintf's.
Does that means it's likely that nothing in next-20141010 actually uses
the functionality expr_eliminate_dups2() provides?
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: [3.16.1 BISECTED REGRESSION]: Simtec Entropy Key (cdc-acm) broken in 3.16
[Cc:ed someone who knows the people behind the Entropy Key: they're not being manufactured at the moment, but he might want to know anyway] On 5 Sep 2014, n...@esperi.org.uk stated: > On 1 Sep 2014, Oliver Neukum stated: > >>> I'll do a bisection of the cdc-acm changes since 3.15 tomorrow night and >>> see if I can find the commit at fault. >> >> Thank you for the report. Please let me know the results of your >> bisection. > > Bisection underway (fifth attempt -- I *may* have characterized it well > enough after a few hours of thrashing at it to bisect accurately this > time). [...] > More generally, the problem may be at *shutdown* -- something goes wrong > during link suspension or something, such that the link never comes up > again until physically reconnected. So a straight bisect is misleading > -- the error may have been in the *last* kernel tested -- and even then, > some kernels (e.g. the 3.15.0 merge base) appear capable of making it > work fine. But even this is not consistent: sometimes a kernel that > works fine if you repeatedly reboot it (such as 3.15) malfunctions when > you reboot into 3.16 -- but sometimes a newly plugged USB key on a 3.16 > kernel malfunctions upon reboot, even if you reboot into a working > kernel such as 3.15 (and it then proceeds to work indefinitely if you > unplug and replug it and stick with 3.15.x, but upon rebooting into > 3.16.x it goes wrong again). *Finally* bisected, not helped by the fact that I sometimes needed up to five reboots (!) to see a failure. The guilty commit is this one: commit 0943d8ead30e9474034cc5e92225ab0fd29fd0d4 Author: Johan Hovold Date: Mon May 26 19:23:51 2014 +0200 USB: cdc-acm: use tty-port dtr_rts Add dtr_rts tty-port operation which implements proper DTR/RTS handling (e.g. only lower DTR/RTS during shutdown if HUPCL is set). Note that modem-control locking still needs to be added throughout the driver. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman To re-describe this failure for the people who weren't in the thread: in 3.16.x I often see this output when asking the ekey daemon for the state of my Simtec Entropy Key (a cdc-acm-based random number generator) after rebooting my ohci-based Soekris net5501: fold:~# ekeydctl stats 1 BytesRead=0 BytesWritten=0 ConnectionNonces=0 ConnectionPackets=0 ConnectionRekeys=0 ConnectionResets=0 ConnectionTime=65 EntropyRate=0 FipsFrameRate=0 FrameByteLast=0 FramesOk=0 FramingErrors=0 KeyDbsdShannonPerByteL=0 KeyDbsdShannonPerByteR=0 KeyEnglishBadness=No failure KeyRawBadness=0 KeyRawShannonPerByteL=0 KeyRawShannonPerByteR=0 KeyRawShannonPerByteX=0 KeyShortBadness=efm_ok KeyTemperatureC=-273.15 KeyTemperatureF=-459.67 KeyTemperatureK=0 KeyVoltage=0 PacketErrors=0 PacketOK=0 ReadRate=0 TotalEntropy=0 WriteRate=0 This device streams data continuously at at rate of several KiB/s, so normally we would never expect to see a report of zero bytes read or written if the key were functional (nor, indeed, a key temperature of absolute zero!). This failure never occurred in 3.15.x nor any earlier kernel. (Note: the 'no failure' message above is sent *from the key* to indicate that the random numbers can be trusted: it is a bit unfortunate that the code for 'No failure' is 0, which is also the default value before anything is received from the key. In this case, we're just seeing the daemon's initialization-time default. As BytesRead indicates, the key is not talking to us.) The symptoms are such that it is the kernel you reboot *from* that causes the failure, not the one you reboot into: once the key fails it never recovers without physical removal and reinsertion (or, one presumes, a poweroff of the whole machine, but I haven't tried that) This is not a consistent failure: sometimes it can take up to four reboots for the key to fail. As a result, the bisection took forever (I had to wait until I had a spare weekend day to devote to it). Despite the errative nature, I'm fairly confident this commit is at fault: with it reverted, I have restarted a couple of dozen times without failure symptoms. (I speculate that the device's firmware may be terminally confused by having something try to hang it up, since it's not a modem nor anything like one, as the boot messages correctly proclaim. The firmware isn't open, so I can't check.) -- 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] clk: rockchip: rk3288: i2s_frac adds flag to set parent's rate
Hi Jianqun,
Am Dienstag, 30. September 2014, 11:12:04 schrieb Jianqun:
> The relation of i2s nodes as follows:
> i2s_src 0 059400 0
> i2s_frac 0 011289600 0
> i2s_pre 0 011289600 0
>sclk_i2s00 011289600 0
>i2s0_clkout 0 011289600 0
> hclk_i2s0 1 19900 0
>
> sclk_i2s0 is the master clock, when to set rate of sclk_i2s0, should
> allow to set its parent's rate, by add flag CLK_SET_RATE_PARENT for
> "i2s_frac", "i2s_pre", "i2s0_clkout" and "sclk_i2s0".
>
> Tested on rk3288 board using max98090, with command "aplay "
>
> Change-Id: I12faad082566532b65a7de8c0a6845e1c17870e6
Please no "Change-Id"s in upstream patches.
> Signed-off-by: Jianqun
> ---
> drivers/clk/rockchip/clk-rk3288.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clk/rockchip/clk-rk3288.c
> b/drivers/clk/rockchip/clk-rk3288.c index c770de0..baf19b4 100644
> --- a/drivers/clk/rockchip/clk-rk3288.c
> +++ b/drivers/clk/rockchip/clk-rk3288.c
> @@ -301,15 +301,15 @@ static struct rockchip_clk_branch
> rk3288_clk_branches[] __initdata = { COMPOSITE(0, "i2s_src",
> mux_pll_src_cpll_gpll_p, 0,
> RK3288_CLKSEL_CON(4), 15, 1, MFLAGS, 0, 7, DFLAGS,
> RK3288_CLKGATE_CON(4), 1, GFLAGS),
> - COMPOSITE_FRAC(0, "i2s_frac", "i2s_src", 0,
> + COMPOSITE_FRAC(0, "i2s_frac", "i2s_src", CLK_SET_RATE_PARENT,
> RK3288_CLKSEL_CON(8), 0,
> RK3288_CLKGATE_CON(4), 2, GFLAGS),
> - MUX(0, "i2s_pre", mux_i2s_pre_p, 0,
> + MUX(0, "i2s_pre", mux_i2s_pre_p, CLK_SET_RATE_PARENT,
> RK3288_CLKSEL_CON(4), 8, 2, MFLAGS),
> - COMPOSITE_NODIV(0, "i2s0_clkout", mux_i2s_clkout_p, 0,
> + COMPOSITE_NODIV(0, "i2s0_clkout", mux_i2s_clkout_p, CLK_SET_RATE_PARENT,
are you sure it is correct that i2s0_clkout should also be able to set the
core i2s clock?
I.e. as it is now, the i2s controller could set one frequency through
sclk_i2s0 and whatever uses i2s0_clkout would be able to set it to something
completely different, which may call for trouble.
So in my mind, it might be better to limit i2s0_clkout to select between its
two parent without being able influence the core i2s clock?
Heiko
> RK3288_CLKSEL_CON(4), 12, 1, MFLAGS,
> RK3288_CLKGATE_CON(4), 0, GFLAGS),
> - GATE(SCLK_I2S0, "sclk_i2s0", "i2s_pre", 0,
> + GATE(SCLK_I2S0, "sclk_i2s0", "i2s_pre", CLK_SET_RATE_PARENT,
> RK3288_CLKGATE_CON(4), 3, GFLAGS),
>
> MUX(0, "spdif_src", mux_pll_src_cpll_gpll_p, 0,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/4] dma-buf: Add constraints sharing information
On Sat, Oct 11, 2014 at 01:37:55AM +0530, Sumit Semwal wrote:
> At present, struct device lacks a mechanism of exposing memory
> access constraints for the device.
>
> Consequently, there is also no mechanism to share these constraints
> while sharing buffers using dma-buf.
>
> If we add support for sharing such constraints, we could use that
> to try to collect requirements of different buffer-sharing devices
> to allocate buffers from a pool that satisfies requirements of all
> such devices.
>
> This is an attempt to add this support; at the moment, only a bitmask
> is added, but if post discussion, we realise we need more information,
> we could always extend the definition of constraint.
>
> A new dma-buf op is also added, to allow exporters to interpret or decide
> on constraint-masks on their own. A default implementation is provided to
> just AND (&) all the constraint-masks.
>
> What constitutes a constraint-mask could be left for interpretation on a
> per-platform basis, while defining some common masks.
>
> Signed-off-by: Sumit Semwal
> Cc: linux-kernel@vger.kernel.org
> Cc: Greg Kroah-Hartman
> Cc: linux-me...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
Just a few high-level comments, I'm between conference travel but
hopefully I can discuss this a bit at plumbers next week.
- I agree that for the insane specific cases we need something opaque like
the access constraints mask you propose here. But for the normal case I
think the existing dma constraints in dma_params would go a long way,
and I think we should look at Rob's RFC from aeons ago to solve those:
https://lkml.org/lkml/2012/7/19/285
With this we should be able to cover the allocation constraints of 90%
of all cases hopefully.
- I'm not sure whether an opaque bitmask is good enough really, I suspect
that we also need various priorities between different allocators. With
the option that some allocators are flat-out incompatible.
- The big bummer imo with ION is that it fully side-steps, but this
proposal here also seems to add entirely new allocators. My rough idea
was that at allocate/attach time we iterate over all attached devices
like in Rob's patch and compute the most constrained allocation
requirements. Then we pick the underlying dma api allocator for these
constraints. That probably means that we need to open up the dma api a
bit. But I guess for a start we could simply try to allocate from the
most constrained device. Together with the opaque bits you propose here
we could even map additional crazy requirements like that an allocation
must come from a specific memory bank (provided by a special-purpose CMA
region). That might also mean that requirements are exclusive and no
allocation is possible.
- I'm not sure we should allow drivers to override the access constraint
checks really - the dma_buf interfaces already provide this possibility
through the ->attach callback. In there exporters are allowed to reject
the attachment for any reason whatsover.
- I think we should at least provide a helper implementation to allocate
dma-buffers for multiple devices using the dma constraints logic we
implement here. I think we should even go as far as providing a default
implementation for dma-bufs which uses dma_alloc_coherent and this new
dma contstraints computation code internally. This should be good enough
for almost all devices, except those that do crazy stuff like swap
support of buffer objects (gem/ttm), virtual hardware buffers (vmwgfx)
or have other special needs (e.g. non-coherent buffers as speed
optimization).
Cheers, Daniel
> ---
> drivers/dma-buf/dma-buf.c | 50
> ++-
> include/linux/device.h| 7 ++-
> include/linux/dma-buf.h | 14 +
> 3 files changed, 65 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index f3014c4..33bdb6a 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -264,6 +264,30 @@ static inline int is_dma_buf_file(struct file *file)
> return file->f_op == _buf_fops;
> }
>
> +/*
> + * def_calc_access_constraints - default implementation of constraint
> checking
> + */
> +static int def_calc_access_constraints(struct dma_buf *dmabuf,
> + struct dma_buf_attachment *attach)
> +{
> + unsigned long access_mask;
> +
> + access_mask = attach->dev->dma_parms->access_constraints_mask;
> +
> + if (!access_mask) {
> + pr_warn("%s dev has no access_constraints_mask; using
> default\n",
> + dev_name(attach->dev));
> + access_mask = DMA_BUF_ALL_MEMORY_ACCESS_MASK;
> + }
> +
> + dmabuf->access_constraints_mask &= access_mask;
> +
> + if (!dmabuf->access_constraints_mask)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> /**
> *
Re: [PATCH v2 0/5] pinctrl: samsung: Data structure clean-up
On 08.10.2014 12:23, Linus Walleij wrote: > On Thu, Oct 2, 2014 at 8:52 PM, Tomasz Figa wrote: > >> This series intends to clean up data structures used by pinctrl-samsung >> driver. >> More specifically, it separates initial compile time constants from data used >> at runtime, allowing unused variant data to be dropped and selected >> structures >> constified to improve safety. > > Thanks! > > The patches missed the v3.18 merge window, but I have queued them up as > the first thing to go into v3.19. OK, thanks. > > Now I need you to help me check the patch set from Abhilash so I know > what to do about that, whenever you have some time... I've already acked previous version of that series, only with some minor nitpicks pointed, but let me take a look at last version. Best regards, Tomasz -- 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] x86, kexec: Add .gitignore file
On 10/10/2014 07:47 PM, Shuah Khan wrote: > On Fri, Oct 10, 2014 at 4:55 PM, Prarit Bhargava wrote: >> When doing git-status there are two untracked files: >> >> \# Untracked files: >> \# (use "git add ..." to include in what will be committed) >> \# >> \# arch/x86/purgatory/kexec-purgatory.c >> \# arch/x86/purgatory/purgatory.ro >> >> Add a .gitignore to block these files. > > I sent patch for this couple of weeks ago. It is pulled in looks like, > I got tipbot > for that patch. > > http://marc.info/?l=linux-kernel=141201613309178 Thanks Shuah. P. > > -- Shuah > -- 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 2/4] cenalloc: Constraint-Enabled Allocation helpers for dma-buf
On Fri, Oct 10, 2014 at 04:09:00PM -0700, Greg Kroah-Hartman wrote: > On Sat, Oct 11, 2014 at 01:37:56AM +0530, Sumit Semwal wrote: > > Devices sharing buffers using dma-buf could benefit from sharing their > > constraints via struct device, and dma-buf framework would manage the > > common constraints for all attached devices per buffer. > > > > With that information, we could have a 'generic' allocator helper in > > the form of a central dma-buf exporter, which can create dma-bufs, and > > allocate backing storage at the time of first call to > > dma_buf_map_attachment. > > > > This allocation would utilise the constraint-mask by matching it to > > the right allocator from a pool of allocators, and then allocating > > buffer backing storage from this allocator. > > > > The pool of allocators could be platform-dependent, allowing for > > platforms to hide the specifics of these allocators from the devices > > that access the dma-buf buffers. > > > > A sample sequence could be: > > - get handle to cenalloc_device, > > - create a dmabuf using cenalloc_buffer_create; > > - use this dmabuf to attach each device, which has its constraints > >set in the constraints mask (dev->dma_params->access_constraints_mask) > > - at each dma_buf_attach() call, dma-buf will check to see if the > > constraint > > mask for the device requesting attachment is compatible with the > > constraints > > of devices already attached to the dma-buf; returns an error if it > > isn't. > > - after all devices have attached, the first call to > > dma_buf_map_attachment() > > will allocate the backing storage for the buffer. > > - follow the dma-buf api for map / unmap etc usage. > > - detach all attachments, > > - call cenalloc_buffer_free to free the buffer if refcount reaches zero; > > > > ** IMPORTANT** > > This mechanism of delayed allocation based on constraint-enablement will > > work > > *ONLY IF* the first map_attachment() call is made AFTER all attach() calls > > are > > done. > > > > Signed-off-by: Sumit Semwal > > Cc: linux-kernel@vger.kernel.org > > Cc: Greg Kroah-Hartman > > Cc: linux-me...@vger.kernel.org > > Cc: dri-de...@lists.freedesktop.org > > Cc: linaro-mm-...@lists.linaro.org > > --- > > MAINTAINERS | 1 + > > drivers/cenalloc/cenalloc.c | 597 > > +++ > > drivers/cenalloc/cenalloc.h | 99 +++ > > drivers/cenalloc/cenalloc_priv.h | 188 > > 4 files changed, 885 insertions(+) > > create mode 100644 drivers/cenalloc/cenalloc.c > > create mode 100644 drivers/cenalloc/cenalloc.h > > create mode 100644 drivers/cenalloc/cenalloc_priv.h > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 40d4796..e88ac81 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -3039,6 +3039,7 @@ L:linux-me...@vger.kernel.org > > L: dri-de...@lists.freedesktop.org > > L: linaro-mm-...@lists.linaro.org > > F: drivers/dma-buf/ > > +F: drivers/cenalloc/ > > F: include/linux/dma-buf* > > F: include/linux/reservation.h > > F: include/linux/*fence.h > > diff --git a/drivers/cenalloc/cenalloc.c b/drivers/cenalloc/cenalloc.c > > new file mode 100644 > > index 000..f278056 > > --- /dev/null > > +++ b/drivers/cenalloc/cenalloc.c > > @@ -0,0 +1,597 @@ > > +/* > > + * Allocator helper framework for constraints-aware dma-buf backing storage > > + * allocation. > > + * This allows constraint-sharing devices to deferred-allocate buffers > > shared > > + * via dma-buf. > > + * > > + * Copyright(C) 2014 Linaro Limited. All rights reserved. > > + * Author: Sumit Semwal > > + * > > + * Structure for management of clients, buffers etc heavily derived from > > + * Android's ION framework. > > Does that mean we can drop ION after this gets merged? Yeah, I hope so. Not sure whetether this hope is shared by google android people ... > /me dreams I guess we can collectively dream about this next week at plumbers ;-) I'll try to squeeze in some light review of Sumit's patches between conference travels ... Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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] clk: rockchip: Add CLK_SET_RATE_PARENT to aclk_cpu_pre
Hi Doug,
Am Montag, 6. Oktober 2014, 10:15:27 schrieb Doug Anderson:
> We'd like to be able to call clk_set_rate() on aclk_cpu (a gate) at
> bootup. In order for this to have any effect we need its parent
> (aclk_cpu_pre) to percolate the rate change to _its_ parent
> (aclk_cpu_src). Add CLK_SET_RATE_PARENT to make this happen.
added this to a branch for 3.19
Thanks
Heiko
>
> Signed-off-by: Doug Anderson
> ---
> drivers/clk/rockchip/clk-rk3288.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/rockchip/clk-rk3288.c
> b/drivers/clk/rockchip/clk-rk3288.c index d053529..4d98f53 100644
> --- a/drivers/clk/rockchip/clk-rk3288.c
> +++ b/drivers/clk/rockchip/clk-rk3288.c
> @@ -279,7 +279,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
> __initdata = { RK3288_CLKGATE_CON(0), 11, GFLAGS),
> COMPOSITE_NOGATE(0, "aclk_cpu_src", mux_aclk_cpu_src_p, 0,
> RK3288_CLKSEL_CON(1), 15, 1, MFLAGS, 3, 5, DFLAGS),
> - DIV(0, "aclk_cpu_pre", "aclk_cpu_src", 0,
> + DIV(0, "aclk_cpu_pre", "aclk_cpu_src", CLK_SET_RATE_PARENT,
> RK3288_CLKSEL_CON(1), 0, 3, DFLAGS),
> GATE(ACLK_CPU, "aclk_cpu", "aclk_cpu_pre", 0,
> RK3288_CLKGATE_CON(0), 3, GFLAGS),
--
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] char: misc: use pr_err instead of printk
On Sun, 2014-10-12 at 00:01 +0530, Rahul Bedarkar wrote:
[]
> diff --git a/drivers/char/misc.c b/drivers/char/misc.c
[]
> @@ -280,12 +280,12 @@ static int __init misc_init(void)
>
> err = -EIO;
> if (register_chrdev(MISC_MAJOR,"misc",_fops))
> - goto fail_printk;
> + goto fail_pr_err;
> misc_class->devnode = misc_devnode;
> return 0;
>
> -fail_printk:
> - printk("unable to get major %d for misc devices\n", MISC_MAJOR);
> +fail_pr_err:
> + pr_err("unable to get major %d for misc devices\n", MISC_MAJOR);
> class_destroy(misc_class);
> fail_remove:
> remove_proc_entry("misc", NULL);
The printk is not relevant.
Maybe the label should be "fail_destroy:"
--
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 3/4] drm/exynos: enable vblank after DPMS on
On Fri, Oct 10, 2014 at 02:31:55PM +0200, Andrzej Hajda wrote: > Before DPMS off driver disables vblank. > It should be balanced by vblank enable after DPMS on. > The patch fixes issue with page_flip ioctl not being able > to acquire vblank counter introduced by patch: > drm: Always reject drm_vblank_get() after drm_vblank_off() > > Signed-off-by: Andrzej Hajda Yeah, you should always call vblank_on again when you (re)enable a crtc, whether this is through a set_config call or through dpms. This is Reviewed-by: Daniel Vetter Sorry that we didn't catch the impact of this additional check on existing drivers, I've thought I've reviewed them and checked that they all call vblank_on. But I didn't take into account that the codepaths might differ for dpms and set_config paths. Otoh most drivers really should implement one in terms of the other. Cheers, Daniel > --- > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c > b/drivers/gpu/drm/exynos/exynos_drm_crtc.c > index 8e38e9f..45026e6 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c > @@ -71,13 +71,16 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, > int mode) > !atomic_read(_crtc->pending_flip), > HZ/20)) > atomic_set(_crtc->pending_flip, 0); > - drm_vblank_off(crtc->dev, exynos_crtc->pipe); > + drm_crtc_vblank_off(crtc); > } > > if (manager->ops->dpms) > manager->ops->dpms(manager, mode); > > exynos_crtc->dpms = mode; > + > + if (mode == DRM_MODE_DPMS_ON) > + drm_crtc_vblank_on(crtc); > } > > static void exynos_drm_crtc_prepare(struct drm_crtc *crtc) > -- > 1.9.1 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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] char: misc: fix coding style issues
This patch fixes checkpatch.pl error
ERROR: space required after that ',' (ctx:VxV)
Signed-off-by: Rahul Bedarkar
---
drivers/char/misc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/misc.c b/drivers/char/misc.c
index a6b96b1..47c9b04 100644
--- a/drivers/char/misc.c
+++ b/drivers/char/misc.c
@@ -144,7 +144,7 @@ static int misc_open(struct inode *inode, struct file *file)
replace_fops(file, new_fops);
if (file->f_op->open) {
file->private_data = c;
- err = file->f_op->open(inode,file);
+ err = file->f_op->open(inode, file);
}
fail:
mutex_unlock(_mtx);
@@ -279,7 +279,7 @@ static int __init misc_init(void)
goto fail_remove;
err = -EIO;
- if (register_chrdev(MISC_MAJOR,"misc",_fops))
+ if (register_chrdev(MISC_MAJOR, "misc", _fops))
goto fail_pr_err;
misc_class->devnode = misc_devnode;
return 0;
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: rockchip: fix parent for spdif_8ch_frac on rk3288
Hi Sonny,
Am Mittwoch, 8. Oktober 2014, 01:55:16 schrieb Sonny Rao:
> The parent should be spdif_8ch_pre not spdif_8ch_src, which doesn't
> exist and looks to be a typo. The TRM also confirms this.
thanks for the catch. I've added the patch to a temporary branch for 3.19 till
we have a stable 3.18-rc1.
As nothing uses the spdif so far I don't think we'll need the fix for 3.18
itself. Please holler if you think otherwise :-)
Heiko
>
> Signed-off-by: Sonny Rao
> ---
> drivers/clk/rockchip/clk-rk3288.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/rockchip/clk-rk3288.c
> b/drivers/clk/rockchip/clk-rk3288.c index 2327829..e41ae1f 100644
> --- a/drivers/clk/rockchip/clk-rk3288.c
> +++ b/drivers/clk/rockchip/clk-rk3288.c
> @@ -325,7 +325,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
> __initdata = { COMPOSITE_NOMUX(0, "spdif_8ch_pre", "spdif_src", 0,
> RK3288_CLKSEL_CON(40), 0, 7, DFLAGS,
> RK3288_CLKGATE_CON(4), 7, GFLAGS),
> - COMPOSITE_FRAC(0, "spdif_8ch_frac", "spdif_8ch_src", 0,
> + COMPOSITE_FRAC(0, "spdif_8ch_frac", "spdif_8ch_pre", 0,
> RK3288_CLKSEL_CON(41), 0,
> RK3288_CLKGATE_CON(4), 8, GFLAGS),
> COMPOSITE_NODIV(SCLK_SPDIF8CH, "sclk_spdif_8ch", mux_spdif_8ch_p, 0,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] char: misc: use pr_err instead of printk
Signed-off-by: Rahul Bedarkar
---
drivers/char/misc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/misc.c b/drivers/char/misc.c
index 75b6de9..a6b96b1 100644
--- a/drivers/char/misc.c
+++ b/drivers/char/misc.c
@@ -280,12 +280,12 @@ static int __init misc_init(void)
err = -EIO;
if (register_chrdev(MISC_MAJOR,"misc",_fops))
- goto fail_printk;
+ goto fail_pr_err;
misc_class->devnode = misc_devnode;
return 0;
-fail_printk:
- printk("unable to get major %d for misc devices\n", MISC_MAJOR);
+fail_pr_err:
+ pr_err("unable to get major %d for misc devices\n", MISC_MAJOR);
class_destroy(misc_class);
fail_remove:
remove_proc_entry("misc", NULL);
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] char: misc: EXPORT_SYMBOL should immediately follow its function
This patch fixes checkpatch.pl warning WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable Signed-off-by: Rahul Bedarkar --- drivers/char/misc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/char/misc.c b/drivers/char/misc.c index 3111e86..75b6de9 100644 --- a/drivers/char/misc.c +++ b/drivers/char/misc.c @@ -226,6 +226,7 @@ int misc_register(struct miscdevice *misc) mutex_unlock(_mtx); return err; } +EXPORT_SYMBOL(misc_register); /** * misc_deregister - unregister a miscellaneous device @@ -252,8 +253,6 @@ int misc_deregister(struct miscdevice *misc) mutex_unlock(_mtx); return 0; } - -EXPORT_SYMBOL(misc_register); EXPORT_SYMBOL(misc_deregister); static char *misc_devnode(struct device *dev, umode_t *mode) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] char: misc: add missing blank line after declarations
Signed-off-by: Rahul Bedarkar
---
drivers/char/misc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/char/misc.c b/drivers/char/misc.c
index cb32ea9..3111e86 100644
--- a/drivers/char/misc.c
+++ b/drivers/char/misc.c
@@ -186,6 +186,7 @@ int misc_register(struct miscdevice *misc)
if (misc->minor == MISC_DYNAMIC_MINOR) {
int i = find_first_zero_bit(misc_minors, DYNAMIC_MINORS);
+
if (i >= DYNAMIC_MINORS) {
err = -EBUSY;
goto out;
@@ -209,6 +210,7 @@ int misc_register(struct miscdevice *misc)
misc, "%s", misc->name);
if (IS_ERR(misc->this_device)) {
int i = DYNAMIC_MINORS - misc->minor - 1;
+
if (i < DYNAMIC_MINORS && i >= 0)
clear_bit(i, misc_minors);
err = PTR_ERR(misc->this_device);
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] char: misc: remove trailing whitespaces
Signed-off-by: Rahul Bedarkar
---
drivers/char/misc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/char/misc.c b/drivers/char/misc.c
index b4cf821..cb32ea9 100644
--- a/drivers/char/misc.c
+++ b/drivers/char/misc.c
@@ -117,14 +117,14 @@ static int misc_open(struct inode *inode, struct file
*file)
const struct file_operations *new_fops = NULL;
mutex_lock(_mtx);
-
+
list_for_each_entry(c, _list, list) {
if (c->minor == minor) {
- new_fops = fops_get(c->fops);
+ new_fops = fops_get(c->fops);
break;
}
}
-
+
if (!new_fops) {
mutex_unlock(_mtx);
request_module("char-major-%d-%d", MISC_MAJOR, minor);
@@ -162,7 +162,7 @@ static const struct file_operations misc_fops = {
/**
* misc_register - register a miscellaneous device
* @misc: device structure
- *
+ *
* Register a miscellaneous device with the kernel. If the minor
* number is set to %MISC_DYNAMIC_MINOR a minor number is assigned
* and placed in the minor field of the structure. For other cases
@@ -174,7 +174,7 @@ static const struct file_operations misc_fops = {
* A zero is returned on success and a negative errno code for
* failure.
*/
-
+
int misc_register(struct miscdevice *misc)
{
dev_t dev;
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] char: misc: fix coding style issues
This patch fixes checkpatch.pl error
ERROR: "foo * bar" should be "foo *bar"
Signed-off-by: Rahul Bedarkar
---
drivers/char/misc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/misc.c b/drivers/char/misc.c
index ffa97d2..b4cf821 100644
--- a/drivers/char/misc.c
+++ b/drivers/char/misc.c
@@ -109,7 +109,7 @@ static const struct file_operations misc_proc_fops = {
};
#endif
-static int misc_open(struct inode * inode, struct file * file)
+static int misc_open(struct inode *inode, struct file *file)
{
int minor = iminor(inode);
struct miscdevice *c;
@@ -175,7 +175,7 @@ static const struct file_operations misc_fops = {
* failure.
*/
-int misc_register(struct miscdevice * misc)
+int misc_register(struct miscdevice *misc)
{
dev_t dev;
int err = 0;
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH v2 2/2] ALSA: au88x0: pr_* replaced with dev_*
On Sat, Oct 11, 2014 at 08:32:49AM -0700, Joe Perches wrote:
> On Sat, 2014-10-11 at 17:03 +0530, Sudip Mukherjee wrote:
> > On Sat, Oct 11, 2014 at 03:48:11AM -0700, Joe Perches wrote:
> > > On Sat, 2014-10-11 at 14:39 +0530, Sudip Mukherjee wrote:
> > > > On Sat, Oct 11, 2014 at 03:20:56PM +0800, Raymond Yau wrote:
> > > > > >
> >
> > > > > > ---
> > > > > >
> > > > >
> > > > > > static int vortex_core_init(vortex_t *vortex)
> > > > > > {
> > > > > >
> > > > > > - pr_info( "Vortex: init ");
> > > > > > + dev_info(vortex->card->dev, "init ");
> > > > >
> > > > > Is it possible to add linefeed since "done/n" won't appear in the
> > > > > same
> > > > > line with init nor shutdown?
> > > > >
> > > > should we add linefeed ?
> > > > as of now it will print init then it will print done as the init is
> > > > complete.
> > > > so dmesg will show us:
> > > >
> > > > initdone.
> > > >
> > > > same for shutdown.
> > > > but if we give linefeed , then it will become :
> > > >
> > > > init
> > > > done.
> > > >
> > > > the meaning will be lost. and many user might just wonder what is done
> > > > ?
> > > []
> > > > > > @@ -2738,7 +2744,7 @@ static int vortex_core_init(vortex_t *vortex)
> > > > > > static int vortex_core_shutdown(vortex_t * vortex)
> > > > > > {
> > > > > >
> > > > > > - pr_info( "Vortex: shutdown...");
> > > > > > + dev_info(vortex->card->dev, "shutdown...");
> > > > > > #ifndef CHIP_AU8820
> > > > > > vortex_eq_free(vortex);
> > > > > > vortex_Vort3D_disable(vortex);
> > > > > > @@ -2760,7 +2766,7 @@ static int vortex_core_shutdown(vortex_t *
> > > > > > vortex)
> > > > > > msleep(5);
> > > > > > hwwrite(vortex->mmio, VORTEX_IRQ_SOURCE, 0x);
> > > > > >
> > > > > > - pr_info( "done.\n");
> > > > > > + dev_info(vortex->card->dev, "done.\n");
> > > > > > return 0;
> > > > > > }
> > >
> > > It's actually on 2 lines before your patch.
> > >
> > > pr_info("a");
> > > pr_info("b\n");
> > >
> > > already emits 2 separate lines.
> > >
> > > pr_info("a");
> > > pr_cont("b\n");
> > >
> > > emits a single line "ab"
> > > (unless some other thread emits something in-between)
> > >
> > > pr_cont or a bare printk can be used after a dev_info
> > > without a newline to avoid unwanted newlines.
> >
> > i think i was not thinking while writing the previous mail.
>
> It seems you were thinking then and now,
> but unfortunately, you are assuming a bit
> more than you have actual experience or
> knowledge of printk inner workings.
>
> > pr_info("a");
> > pr_info("b\n");
> > should print as "ab" ,
>
> This is not true.
>
> All pr_ uses but pr_cont always
> start on a new line by emitting a newline
> if the last line did not have one.
>
oops... i have never tried with pr_* without a \n. I was thinking it will
work like printf. sorry for the noise i created.
and thanks for the information about those 2 commits.
so, now in this case what will you suggest - shutdown and done both
terminated by \n or some thing like : "shutdown process started" and then
"shutdown done"
thanks
sudip
> The difference between using:
>
> pr_info("a")
> pr_info("b\n")
>
> and
>
> pr_info("a\n")
> pr_info("b\n")
>
> is not emitted line count.
>
> The first may unintentionally be continued
> by another thread using a printk that does
> not start with a KERN_.
>
> printk has had this behavior for ~5 years
> since these 2 commits:
>
> commit e28d713704117bca0820c732210df6075b09f13b
> Author: Linus Torvalds
> Date: Tue Jun 16 11:02:28 2009 -0700
>
> printk: Add KERN_DEFAULT printk log-level
>
> This adds a KERN_DEFAULT loglevel marker, for when you cannot decide
> which loglevel you want, and just want to keep an existing printk
> with the default loglevel.
>
> The difference between having KERN_DEFAULT and having no log-level
> marker at all is two-fold:
>
> - having the log-level marker will now force a new-line if the
>previous printout had not added one (perhaps because it forgot,
>but perhaps because it expected a continuation)
>
> - having a log-level marker is required if you are printing out a
>message that otherwise itself could perhaps otherwise be mistaken
>for a log-level.
>
> and
>
> commit 5fd29d6ccbc98884569d6f3105aeca70858b3e0f
> Author: Linus Torvalds
> Date: Tue Jun 16 10:57:02 2009 -0700
>
> printk: clean up handling of log-levels and newlines
>
> It used to be that we would only look at the log-level in a printk()
> after explicit newlines, which can cause annoying problems when the
> previous printk() did not end with a '\n'. In that case, the log-level
> marker would be just printed out in the middle of the line, and be
> seen as just noise rather than change the logging level.
>
> This changes things to always look at the log-level in
Re: [PATCH] ARM: dts: rockchip: enable DMA on SPI for rk3066 and rk3188
Hi Julien, Am Freitag, 10. Oktober 2014, 10:04:13 schrieb Julien CHAUVEAU: > According to the RK3066 and RK3188 TRM, the two SPI controllers support DMA > handshake interface. Add the DMA properties so they can be used when needed. > > Signed-off-by: Julien CHAUVEAU added the patch to a temporary branch for 3.19 (on github and will move to kernel.org once 3.18-rc1 is released) Heiko > --- > arch/arm/boot/dts/rk3xxx.dtsi | 4 > 1 file changed, 4 insertions(+) > > diff --git a/arch/arm/boot/dts/rk3xxx.dtsi b/arch/arm/boot/dts/rk3xxx.dtsi > index 499468d..9ba92de 100644 > --- a/arch/arm/boot/dts/rk3xxx.dtsi > +++ b/arch/arm/boot/dts/rk3xxx.dtsi > @@ -367,6 +367,8 @@ > reg = <0x2007 0x1000>; > #address-cells = <1>; > #size-cells = <0>; > + dmas = < 10>, < 11>; > + dma-names = "tx", "rx"; > status = "disabled"; > }; > > @@ -378,6 +380,8 @@ > reg = <0x20074000 0x1000>; > #address-cells = <1>; > #size-cells = <0>; > + dmas = < 12>, < 13>; > + dma-names = "tx", "rx"; > status = "disabled"; > }; > }; -- 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/
