[PATCH 1/2] Staging: wlan-ng: Fix sparse warnings by using appropriate endian types
Fix some sparse warning by using correct endian types in structs and
local variables.
This patch only fix sparse warnings and do not change the logic.
Signed-off-by: Adrien Descamps
---
Compile tested only
drivers/staging/wlan-ng/hfa384x.h | 58 +--
drivers/staging/wlan-ng/hfa384x_usb.c | 2 +-
drivers/staging/wlan-ng/p80211conv.h | 28 -
3 files changed, 44 insertions(+), 44 deletions(-)
diff --git a/drivers/staging/wlan-ng/hfa384x.h
b/drivers/staging/wlan-ng/hfa384x.h
index 60caf9c..7bcc0db 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -482,7 +482,7 @@ struct hfa384x_tx_frame {
u8 address3[6];
u16 sequence_control;
u8 address4[6];
- u16 data_len; /* little endian format */
+ __le16 data_len;/* little endian format */
/*-- 802.3 Header Information --*/
@@ -801,41 +801,41 @@ struct hfa384x_usb_txfrm {
} __packed;
struct hfa384x_usb_cmdreq {
- u16 type;
- u16 cmd;
- u16 parm0;
- u16 parm1;
- u16 parm2;
+ __le16 type;
+ __le16 cmd;
+ __le16 parm0;
+ __le16 parm1;
+ __le16 parm2;
u8 pad[54];
} __packed;
struct hfa384x_usb_wridreq {
- u16 type;
- u16 frmlen;
- u16 rid;
+ __le16 type;
+ __le16 frmlen;
+ __le16 rid;
u8 data[HFA384x_RIDDATA_MAXLEN];
} __packed;
struct hfa384x_usb_rridreq {
- u16 type;
- u16 frmlen;
- u16 rid;
+ __le16 type;
+ __le16 frmlen;
+ __le16 rid;
u8 pad[58];
} __packed;
struct hfa384x_usb_wmemreq {
- u16 type;
- u16 frmlen;
- u16 offset;
- u16 page;
+ __le16 type;
+ __le16 frmlen;
+ __le16 offset;
+ __le16 page;
u8 data[HFA384x_USB_RWMEM_MAXLEN];
} __packed;
struct hfa384x_usb_rmemreq {
- u16 type;
- u16 frmlen;
- u16 offset;
- u16 page;
+ __le16 type;
+ __le16 frmlen;
+ __le16 offset;
+ __le16 page;
u8 pad[56];
} __packed;
@@ -854,16 +854,16 @@ struct hfa384x_usb_infofrm {
struct hfa384x_usb_statusresp {
u16 type;
- u16 status;
- u16 resp0;
- u16 resp1;
- u16 resp2;
+ __le16 status;
+ __le16 resp0;
+ __le16 resp1;
+ __le16 resp2;
} __packed;
struct hfa384x_usb_rridresp {
u16 type;
- u16 frmlen;
- u16 rid;
+ __le16 frmlen;
+ __le16 rid;
u8 data[HFA384x_RIDDATA_MAXLEN];
} __packed;
@@ -1388,13 +1388,13 @@ static inline int hfa384x_drvr_getconfig16(struct
hfa384x *hw, u16 rid, void *va
result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
if (result == 0)
- *((u16 *)val) = le16_to_cpu(*((u16 *)val));
+ *((u16 *)val) = le16_to_cpu(*((__le16 *)val));
return result;
}
static inline int hfa384x_drvr_setconfig16(struct hfa384x *hw, u16 rid, u16
val)
{
- u16 value = cpu_to_le16(val);
+ __le16 value = cpu_to_le16(val);
return hfa384x_drvr_setconfig(hw, rid, &value, sizeof(value));
}
@@ -1408,7 +1408,7 @@ hfa384x_drvr_setconfig_async(struct hfa384x *hw,
static inline int
hfa384x_drvr_setconfig16_async(struct hfa384x *hw, u16 rid, u16 val)
{
- u16 value = cpu_to_le16(val);
+ __le16 value = cpu_to_le16(val);
return hfa384x_drvr_setconfig_async(hw, rid, &value, sizeof(value),
NULL, NULL);
diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
b/drivers/staging/wlan-ng/hfa384x_usb.c
index 4fe037a..f26cc19 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -2316,7 +2316,7 @@ int hfa384x_drvr_ramdl_write(struct hfa384x *hw, u32
daddr, void *buf, u32 len)
int hfa384x_drvr_readpda(struct hfa384x *hw, void *buf, unsigned int len)
{
int result = 0;
- u16 *pda = buf;
+ __le16 *pda = buf;
int pdaok = 0;
int morepdrs = 1;
int currpdr = 0;/* word offset of the current pdr */
diff --git a/drivers/staging/wlan-ng/p80211conv.h
b/drivers/staging/wlan-ng/p80211conv.h
index ed70d98..bd66826 100644
--- a/drivers/staging/wlan-ng/p80211conv.h
+++ b/drivers/staging/wlan-ng/p80211conv.h
@@ -101,20 +101,20 @@ void p80211skb_rxmeta_detach(struct sk_buff *skb);
* Frame capture header. (See doc/capturefrm.txt)
*/
struct p80211_caphdr {
- u32 version;
- u32 length;
- u64 mactime;
- u64 hosttime;
- u32 phytype;
- u32 channel;
- u32 datarate;
- u32 antenna;
- u32 priority;
- u32 ssi_type;
- s32 ssi_signal;
- s32 ssi_noise;
- u32 preamble;
- u32 encoding;
+ __be32 version;
+ __be32 length;
+ __be64 mactime;
+ __be64 hosttime;
+ __be32 phytype;
+ __be32 channel;
+ __be32 datarate;
+
[PATCH 2/2] Staging: wlan-ng: Fix endian error
sparse report fixed: drivers/staging//wlan-ng//hfa384x_usb.c:3517:35: warning: restricted __be64 degrades to integer drivers/staging//wlan-ng//hfa384x_usb.c:3517:33: warning: incorrect type in assignment (different base types) drivers/staging//wlan-ng//hfa384x_usb.c:3517:33:expected restricted __be64 [usertype] mactime drivers/staging//wlan-ng//hfa384x_usb.c:3517:33:got unsigned long long Computation on the value should be done when in machine format, not in big endian format. Signed-off-by: Adrien Descamps --- Compile tested only drivers/staging/wlan-ng/hfa384x_usb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c b/drivers/staging/wlan-ng/hfa384x_usb.c index f26cc19..29b059f 100644 --- a/drivers/staging/wlan-ng/hfa384x_usb.c +++ b/drivers/staging/wlan-ng/hfa384x_usb.c @@ -3514,7 +3514,7 @@ static void hfa384x_int_rxmonitor(struct wlandevice *wlandev, caphdr->version = htonl(P80211CAPTURE_VERSION); caphdr->length = htonl(sizeof(struct p80211_caphdr)); - caphdr->mactime = __cpu_to_be64(rxdesc->time) * 1000; + caphdr->mactime = __cpu_to_be64(rxdesc->time * 1000); caphdr->hosttime = __cpu_to_be64(jiffies); caphdr->phytype = htonl(4); /* dss_dot11_b */ caphdr->channel = htonl(hw->sniff_channel); -- 2.1.4
Re: [PATCH 4/4] tty/serial: sh-sci: remove uneeded IS_ERR_OR_NULL calls
Hi Richard,
On Fri, Mar 3, 2017 at 3:22 PM, Richard Genoud wrote:
> Since commit 1d267ea6539f ("serial: mctrl-gpio: simplify init routine"),
> the mctrl_gpio_to_gpiod() function can't return an error anymore.
> So, just testing for a NULL pointer is ok.
If CONFIG_GPIOLIB=n, mctrl_gpio_to_gpiod() always returns ERR_PTR(-ENOSYS).
That case should be handled correctly, too.
Perhaps mctrl_gpio_to_gpiod() should always return NULL if !CONFIG_GPIOLIB?
This may apply to the other 2 patches, too:
[PATCH 2/4] tty/serial: atmel: remove uneeded IS_ERR_OR_NULL calls
[PATCH 3/4] tty/serial: mxs-auart: remove uneeded IS_ERR_OR_NULL calls
> Signed-off-by: Richard Genoud
> ---
> drivers/tty/serial/sh-sci.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
> index 9a47cc4f16a2..36fde6f24040 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -1934,12 +1934,12 @@ static unsigned int sci_get_mctrl(struct uart_port
> *port)
> if (s->autorts) {
> if (sci_get_cts(port))
> mctrl |= TIOCM_CTS;
> - } else if (IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(gpios, UART_GPIO_CTS)))
> {
> + } else if (!mctrl_gpio_to_gpiod(gpios, UART_GPIO_CTS)) {
> mctrl |= TIOCM_CTS;
> }
> - if (IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(gpios, UART_GPIO_DSR)))
> + if (!mctrl_gpio_to_gpiod(gpios, UART_GPIO_DSR))
> mctrl |= TIOCM_DSR;
> - if (IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(gpios, UART_GPIO_DCD)))
> + if (!mctrl_gpio_to_gpiod(gpios, UART_GPIO_DCD))
> mctrl |= TIOCM_CAR;
>
> return mctrl;
> @@ -3072,10 +3072,8 @@ static int sci_probe_single(struct platform_device
> *dev,
> return PTR_ERR(sciport->gpios);
>
> if (sciport->has_rtscts) {
> - if (!IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(sciport->gpios,
> - UART_GPIO_CTS)) ||
> - !IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(sciport->gpios,
> - UART_GPIO_RTS))) {
> + if (mctrl_gpio_to_gpiod(sciport->gpios, UART_GPIO_CTS) ||
> + mctrl_gpio_to_gpiod(sciport->gpios, UART_GPIO_RTS)) {
> dev_err(&dev->dev, "Conflicting RTS/CTS config\n");
> return -EINVAL;
> }
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [RFC PATCH 10/12] staging: android: ion: Use CMA APIs directly
On 03/03/2017 08:41 AM, Laurent Pinchart wrote: > Hi Laura, > > Thank you for the patch. > > On Thursday 02 Mar 2017 13:44:42 Laura Abbott wrote: >> When CMA was first introduced, its primary use was for DMA allocation >> and the only way to get CMA memory was to call dma_alloc_coherent. This >> put Ion in an awkward position since there was no device structure >> readily available and setting one up messed up the coherency model. >> These days, CMA can be allocated directly from the APIs. Switch to using >> this model to avoid needing a dummy device. This also avoids awkward >> caching questions. > > If the DMA mapping API isn't suitable for today's requirements anymore, I > believe that's what needs to be fixed, instead of working around the problem > by introducing another use-case-specific API. > I don't think this is a usecase specific API. CMA has been decoupled from DMA already because it's used in other places. The trying to go through DMA was just another layer of abstraction, especially since there isn't a device available for allocation. Thanks, Laura
Re: net/ipv4: deadlock in ip_ra_control
On Thu, Mar 2, 2017 at 10:40 AM, Dmitry Vyukov wrote:
> On Wed, Mar 1, 2017 at 6:18 PM, Cong Wang wrote:
>> On Wed, Mar 1, 2017 at 2:44 AM, Dmitry Vyukov wrote:
>>> Hello,
>>>
>>> I've got the following deadlock report while running syzkaller fuzzer
>>> on linux-next/51788aebe7cae79cb334ad50641347465fc188fd:
>>>
>>> ==
>>> [ INFO: possible circular locking dependency detected ]
>>> 4.10.0-next-20170301+ #1 Not tainted
>>> ---
>>> syz-executor1/3394 is trying to acquire lock:
>>> (sk_lock-AF_INET){+.+.+.}, at: [] lock_sock
>>> include/net/sock.h:1460 [inline]
>>> (sk_lock-AF_INET){+.+.+.}, at: []
>>> do_ip_setsockopt.isra.12+0x21c/0x3540 net/ipv4/ip_sockglue.c:652
>>>
>>> but task is already holding lock:
>>> (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x17/0x20
>>> net/core/rtnetlink.c:70
>>>
>>> which lock already depends on the new lock.
>>>
>>>
>>> the existing dependency chain (in reverse order) is:
>>>
>>> -> #1 (rtnl_mutex){+.+.+.}:
>>>validate_chain kernel/locking/lockdep.c:2265 [inline]
>>>__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338
>>>lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3753
>>>__mutex_lock_common kernel/locking/mutex.c:754 [inline]
>>>__mutex_lock+0x172/0x1730 kernel/locking/mutex.c:891
>>>mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:906
>>>rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70
>>>mrtsock_destruct+0x86/0x2c0 net/ipv4/ipmr.c:1281
>>>ip_ra_control+0x459/0x600 net/ipv4/ip_sockglue.c:372
>>>do_ip_setsockopt.isra.12+0x1064/0x3540 net/ipv4/ip_sockglue.c:1161
>>>ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264
>>>raw_setsockopt+0xb7/0xd0 net/ipv4/raw.c:839
>>>sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2725
>>>SYSC_setsockopt net/socket.c:1786 [inline]
>>>SyS_setsockopt+0x25c/0x390 net/socket.c:1765
>>>entry_SYSCALL_64_fastpath+0x1f/0xc2
>>>
>>> -> #0 (sk_lock-AF_INET){+.+.+.}:
>>>check_prev_add kernel/locking/lockdep.c:1828 [inline]
>>>check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1938
>>>validate_chain kernel/locking/lockdep.c:2265 [inline]
>>>__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338
>>>lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3753
>>>lock_sock_nested+0xcb/0x120 net/core/sock.c:2530
>>>lock_sock include/net/sock.h:1460 [inline]
>>>do_ip_setsockopt.isra.12+0x21c/0x3540 net/ipv4/ip_sockglue.c:652
>>>ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264
>>>tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2721
>>>sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2725
>>>SYSC_setsockopt net/socket.c:1786 [inline]
>>>SyS_setsockopt+0x25c/0x390 net/socket.c:1765
>>>entry_SYSCALL_64_fastpath+0x1f/0xc2
>>>
>>
>> Please try the attached patch (compile only).
>
>
> Pushed the patch to the bots.
> Thanks
This patch triggers:
[ 57.748990] RTNL: assertion failed at net/ipv4/ipmr.c (1236)
[ 57.749022] CPU: 1 PID: 5301 Comm: syz-executor2 Not tainted 4.10.0+ #15
[ 57.749026] Hardware name: Google Google Compute Engine/Google
Compute Engine, BIOS Google 01/01/2011
[ 57.749028] Call Trace:
[ 57.749042] dump_stack+0x2ee/0x3ef
[ 57.749219] mrtsock_destruct+0x27e/0x2f0
[ 57.749241] ip_ra_control+0x459/0x600
[ 57.749287] raw_close+0x19/0x30
[ 57.749295] inet_release+0xed/0x1c0
[ 57.749303] sock_release+0x8d/0x1e0
[ 57.749316] sock_close+0x16/0x20
[ 57.749323] __fput+0x332/0x7f0
[ 57.749340] fput+0x15/0x20
[ 57.749347] task_work_run+0x18a/0x260
[ 57.749372] do_exit+0x18ef/0x28b0
[ 57.749641] do_group_exit+0x149/0x420
[ 57.749656] get_signal+0x7e0/0x1820
[ 57.749697] do_signal+0xd2/0x2190
[ 57.749746] exit_to_usermode_loop+0x200/0x2a0
[ 57.749758] syscall_return_slowpath+0x4d3/0x570
[ 57.749835] entry_SYSCALL_64_fastpath+0xc0/0xc2
[ 57.749840] RIP: 0033:0x44fb79
[ 57.749843] RSP: 002b:7fbba84d9cf8 EFLAGS: 0246 ORIG_RAX:
00ca
[ 57.749850] RAX: fe00 RBX: 00708218 RCX: 0044fb79
[ 57.749854] RDX: RSI: RDI: 00708218
[ 57.749857] RBP: 007081f8 R08: R09:
[ 57.749860] R10: R11: 0246 R12:
[ 57.749864] R13: 00a5fc57 R14: 7fbba84da9c0 R15: 000c
[ 57.749964]
[ 57.749966] ===
[ 57.749967] [ INFO: suspicious RCU usage. ]
[ 57.749971] 4.10.0+ #15 Not tainted
[ 57.749972] ---
[ 57.749975] net/ipv4/ipmr.c:1238 suspicious
rcu_dereference_protected() usage!
[ 57.749977]
[ 57.749977] other info that might help us debug this:
[ 57.749977]
[ 57.749980]
[ 57.749980] rcu_scheduler_activ
Re: [Outreachy kernel] [PATCH 2/6] staging: speakup: simple_strtoul is replaced with kstrtoul
On Sat, 4 Mar 2017, Arushi Singhal wrote:
> This patch fixes "simple_strtoul is obsolete, use kstrtoul instead"
> warning.
>
> Signed-off-by: Arushi Singhal
> ---
> drivers/staging/speakup/kobjects.c| 4 ++--
> drivers/staging/speakup/main.c| 2 +-
> drivers/staging/speakup/varhandlers.c | 2 +-
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/speakup/kobjects.c
> b/drivers/staging/speakup/kobjects.c
> index edde9e68779e..a82698c66568 100644
> --- a/drivers/staging/speakup/kobjects.c
> +++ b/drivers/staging/speakup/kobjects.c
> @@ -152,7 +152,7 @@ static ssize_t chars_chartab_store(struct kobject *kobj,
> continue;
> }
>
> - index = simple_strtoul(cp, &temp, 10);
> + index = kstrtoul(cp, &temp, 10);
It seems unlikely that you actually compiled this code. The argument list
for kstrtoul has a completely different set of types.
julia
> if (index > 255) {
> rejected++;
> cp = linefeed + 1;
> @@ -785,7 +785,7 @@ static ssize_t message_store_helper(const char *buf,
> size_t count,
> continue;
> }
>
> - index = simple_strtoul(cp, &temp, 10);
> + index = kstrtoul(cp, &temp, 10);
>
> while ((temp < linefeed) && (*temp == ' ' || *temp == '\t'))
> temp++;
> diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
> index 17df20ec94be..b43e2e156602 100644
> --- a/drivers/staging/speakup/main.c
> +++ b/drivers/staging/speakup/main.c
> @@ -1945,7 +1945,7 @@ static int handle_goto(struct vc_data *vc, u_char type,
> u_char ch, u_short key)
> return 1;
> }
>
> - goto_pos = simple_strtoul(goto_buf, &cp, 10);
> + goto_pos = kstrtoul(goto_buf, &cp, 10);
>
> if (*cp == 'x') {
> if (*goto_buf < '0')
> diff --git a/drivers/staging/speakup/varhandlers.c
> b/drivers/staging/speakup/varhandlers.c
> index cc984196020f..5107533bb45a 100644
> --- a/drivers/staging/speakup/varhandlers.c
> +++ b/drivers/staging/speakup/varhandlers.c
> @@ -325,7 +325,7 @@ char *spk_s2uchar(char *start, char *dest)
> {
> int val;
>
> - val = simple_strtoul(skip_spaces(start), &start, 10);
> + val = kstrtoul(skip_spaces(start), &start, 10);
> if (*start == ',')
> start++;
> *dest = (u_char)val;
> --
> 2.11.0
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/outreachy-kernel/20170303183707.14830-3-arushisinghal19971997%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
[PATCH 5/6] staging: speakup: Avoid multiple assignments on same line
This patch fixes the checkpatch.pl warning "multiple assignments
should be avoided."
Signed-off-by: Arushi Singhal
---
drivers/staging/speakup/main.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index 4c3b5c627718..7915e75664f4 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -269,9 +269,12 @@ static unsigned char get_attributes(struct vc_data *vc,
u16 *pos)
static void speakup_date(struct vc_data *vc)
{
- spk_x = spk_cx = vc->vc_x;
- spk_y = spk_cy = vc->vc_y;
- spk_pos = spk_cp = vc->vc_pos;
+ spk_x = vc->vc_x;
+ spk_cx = vc->vc_x;
+ spk_y = vc->vc_y;
+ spk_cy = vc->vc_y;
+ spk_pos = vc->vc_pos;
+ spk_cp = vc->vc_pos;
spk_old_attr = spk_attr;
spk_attr = get_attributes(vc, (u_short *)spk_pos);
}
@@ -1643,9 +1646,12 @@ static int speak_highlight(struct vc_data *vc)
spk_do_flush();
spkup_write(speakup_console[vc_num]->ht.highbuf[hc],
speakup_console[vc_num]->ht.highsize[hc]);
- spk_pos = spk_cp = speakup_console[vc_num]->ht.rpos[hc];
- spk_x = spk_cx = speakup_console[vc_num]->ht.rx[hc];
- spk_y = spk_cy = speakup_console[vc_num]->ht.ry[hc];
+ spk_pos = speakup_console[vc_num]->ht.rpos[hc];
+ spk_cp = speakup_console[vc_num]->ht.rpos[hc];
+ spk_x = speakup_console[vc_num]->ht.rx[hc];
+ spk_cx = speakup_console[vc_num]->ht.rx[hc];
+ spk_y = speakup_console[vc_num]->ht.ry[hc];
+ spk_cy = speakup_console[vc_num]->ht.ry[hc];
return 1;
}
return 0;
--
2.11.0
Re: [Outreachy kernel] [PATCH] staging: speakup: else is not generally useful after a break or return
On Fri, 3 Mar 2017, Arushi Singhal wrote:
> fixed checkpatch.pl warning: else is not generally useful after a break
> or return.
> Removed the else without affecting the logic.
> Dead code is also eliminated.
The chhange is not correct. There is a big chain of if/else if. The if
(type == KT_LATIN) can reach the code at the end of the file.
julia
>
> Signed-off-by: Arushi Singhal
> ---
> drivers/staging/speakup/keyhelp.c | 53
> ++-
> 1 file changed, 19 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/staging/speakup/keyhelp.c
> b/drivers/staging/speakup/keyhelp.c
> index 4e6e5daba50c..ad3efded37c1 100644
> --- a/drivers/staging/speakup/keyhelp.c
> +++ b/drivers/staging/speakup/keyhelp.c
> @@ -176,43 +176,28 @@ int spk_handle_help(struct vc_data *vc, u_char type,
> u_char ch, u_short key)
> synth_printf("%s\n", spk_msg_get(MSG_HELP_INFO));
> build_key_data(); /* rebuild each time in case new mapping */
> return 1;
> - } else {
> - name = NULL;
> - if ((type != KT_SPKUP) && (key > 0) && (key <= num_key_names)) {
> - synth_printf("%s\n",
> - spk_msg_get(MSG_KEYNAMES_START + key - 1));
> - return 1;
> - }
> - for (i = 0; funcvals[i] != 0 && !name; i++) {
> - if (ch == funcvals[i])
> - name = spk_msg_get(MSG_FUNCNAMES_START + i);
> - }
> - if (!name)
> - return -1;
> - kp = spk_our_keys[key] + 1;
> - for (i = 0; i < nstates; i++) {
> - if (ch == kp[i])
> - break;
> - }
> - key += (state_tbl[i] << 8);
> - say_key(key);
> - synth_printf(spk_msg_get(MSG_KEYDESC), name);
> - synth_printf("\n");
> - return 1;
> }
> - name = spk_msg_get(MSG_FUNCNAMES_START + cur_item);
> - func = funcvals[cur_item];
> - synth_printf("%s", name);
> - if (key_offsets[func] == 0) {
> - synth_printf(" %s\n", spk_msg_get(MSG_IS_UNASSIGNED));
> +
> + name = NULL;
> + if ((type != KT_SPKUP) && (key > 0) && (key <= num_key_names)) {
> + synth_printf("%s\n",
> + spk_msg_get(MSG_KEYNAMES_START + key - 1));
> return 1;
> }
> - p_keys = key_data + key_offsets[func];
> - for (n = 0; p_keys[n]; n++) {
> - val = p_keys[n];
> - if (n > 0)
> - synth_printf("%s ", spk_msg_get(MSG_DISJUNCTION));
> - say_key(val);
> + for (i = 0; funcvals[i] != 0 && !name; i++) {
> + if (ch == funcvals[i])
> + name = spk_msg_get(MSG_FUNCNAMES_START + i);
> + }
> + if (!name)
> + return -1;
> + kp = spk_our_keys[key] + 1;
> + for (i = 0; i < nstates; i++) {
> + if (ch == kp[i])
> + break;
> }
> + key += (state_tbl[i] << 8);
> + say_key(key);
> + synth_printf(spk_msg_get(MSG_KEYDESC), name);
> + synth_printf("\n");
> return 1;
> }
> --
> 2.11.0
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/outreachy-kernel/2017030317.GA23744%40arushi-HP-Pavilion-Notebook.
> For more options, visit https://groups.google.com/d/optout.
>
Re: net/ipv4: deadlock in ip_ra_control
On Fri, Mar 3, 2017 at 7:43 PM, Dmitry Vyukov wrote:
> On Thu, Mar 2, 2017 at 10:40 AM, Dmitry Vyukov wrote:
>> On Wed, Mar 1, 2017 at 6:18 PM, Cong Wang wrote:
>>> On Wed, Mar 1, 2017 at 2:44 AM, Dmitry Vyukov wrote:
Hello,
I've got the following deadlock report while running syzkaller fuzzer
on linux-next/51788aebe7cae79cb334ad50641347465fc188fd:
==
[ INFO: possible circular locking dependency detected ]
4.10.0-next-20170301+ #1 Not tainted
---
syz-executor1/3394 is trying to acquire lock:
(sk_lock-AF_INET){+.+.+.}, at: [] lock_sock
include/net/sock.h:1460 [inline]
(sk_lock-AF_INET){+.+.+.}, at: []
do_ip_setsockopt.isra.12+0x21c/0x3540 net/ipv4/ip_sockglue.c:652
but task is already holding lock:
(rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x17/0x20
net/core/rtnetlink.c:70
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (rtnl_mutex){+.+.+.}:
validate_chain kernel/locking/lockdep.c:2265 [inline]
__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338
lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3753
__mutex_lock_common kernel/locking/mutex.c:754 [inline]
__mutex_lock+0x172/0x1730 kernel/locking/mutex.c:891
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:906
rtnl_lock+0x17/0x20 net/core/rtnetlink.c:70
mrtsock_destruct+0x86/0x2c0 net/ipv4/ipmr.c:1281
ip_ra_control+0x459/0x600 net/ipv4/ip_sockglue.c:372
do_ip_setsockopt.isra.12+0x1064/0x3540 net/ipv4/ip_sockglue.c:1161
ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264
raw_setsockopt+0xb7/0xd0 net/ipv4/raw.c:839
sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2725
SYSC_setsockopt net/socket.c:1786 [inline]
SyS_setsockopt+0x25c/0x390 net/socket.c:1765
entry_SYSCALL_64_fastpath+0x1f/0xc2
-> #0 (sk_lock-AF_INET){+.+.+.}:
check_prev_add kernel/locking/lockdep.c:1828 [inline]
check_prevs_add+0xa8f/0x19f0 kernel/locking/lockdep.c:1938
validate_chain kernel/locking/lockdep.c:2265 [inline]
__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338
lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3753
lock_sock_nested+0xcb/0x120 net/core/sock.c:2530
lock_sock include/net/sock.h:1460 [inline]
do_ip_setsockopt.isra.12+0x21c/0x3540 net/ipv4/ip_sockglue.c:652
ip_setsockopt+0x3a/0xb0 net/ipv4/ip_sockglue.c:1264
tcp_setsockopt+0x82/0xd0 net/ipv4/tcp.c:2721
sock_common_setsockopt+0x95/0xd0 net/core/sock.c:2725
SYSC_setsockopt net/socket.c:1786 [inline]
SyS_setsockopt+0x25c/0x390 net/socket.c:1765
entry_SYSCALL_64_fastpath+0x1f/0xc2
>>>
>>> Please try the attached patch (compile only).
>>
>>
>> Pushed the patch to the bots.
>> Thanks
>
>
> This patch triggers:
>
> [ 57.748990] RTNL: assertion failed at net/ipv4/ipmr.c (1236)
> [ 57.749022] CPU: 1 PID: 5301 Comm: syz-executor2 Not tainted 4.10.0+ #15
> [ 57.749026] Hardware name: Google Google Compute Engine/Google
> Compute Engine, BIOS Google 01/01/2011
> [ 57.749028] Call Trace:
> [ 57.749042] dump_stack+0x2ee/0x3ef
> [ 57.749219] mrtsock_destruct+0x27e/0x2f0
> [ 57.749241] ip_ra_control+0x459/0x600
> [ 57.749287] raw_close+0x19/0x30
> [ 57.749295] inet_release+0xed/0x1c0
> [ 57.749303] sock_release+0x8d/0x1e0
> [ 57.749316] sock_close+0x16/0x20
> [ 57.749323] __fput+0x332/0x7f0
> [ 57.749340] fput+0x15/0x20
> [ 57.749347] task_work_run+0x18a/0x260
> [ 57.749372] do_exit+0x18ef/0x28b0
> [ 57.749641] do_group_exit+0x149/0x420
> [ 57.749656] get_signal+0x7e0/0x1820
> [ 57.749697] do_signal+0xd2/0x2190
> [ 57.749746] exit_to_usermode_loop+0x200/0x2a0
> [ 57.749758] syscall_return_slowpath+0x4d3/0x570
> [ 57.749835] entry_SYSCALL_64_fastpath+0xc0/0xc2
> [ 57.749840] RIP: 0033:0x44fb79
> [ 57.749843] RSP: 002b:7fbba84d9cf8 EFLAGS: 0246 ORIG_RAX:
> 00ca
> [ 57.749850] RAX: fe00 RBX: 00708218 RCX:
> 0044fb79
> [ 57.749854] RDX: RSI: RDI:
> 00708218
> [ 57.749857] RBP: 007081f8 R08: R09:
>
> [ 57.749860] R10: R11: 0246 R12:
>
> [ 57.749864] R13: 00a5fc57 R14: 7fbba84da9c0 R15:
> 000c
> [ 57.749964]
> [ 57.749966] ===
> [ 57.749967] [ INFO: suspicious RCU usage. ]
> [ 57.749971] 4.10.0+ #15 Not tainted
> [ 57.749972] ---
> [
Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support
On 03/03/2017 08:39 AM, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Friday 03 Mar 2017 10:56:54 Daniel Vetter wrote:
>> On Thu, Mar 02, 2017 at 01:44:38PM -0800, Laura Abbott wrote:
>>> Now that we call dma_map in the dma_buf API callbacks there is no need
>>> to use the existing cache APIs. Remove the sync ioctl and the existing
>>> bad dma_sync calls. Explicit caching can be handled with the dma_buf
>>> sync API.
>>>
>>> Signed-off-by: Laura Abbott
>>> ---
>>>
>>> drivers/staging/android/ion/ion-ioctl.c | 5
>>> drivers/staging/android/ion/ion.c | 40
>>> drivers/staging/android/ion/ion_carveout_heap.c | 6
>>> drivers/staging/android/ion/ion_chunk_heap.c| 6
>>> drivers/staging/android/ion/ion_page_pool.c | 3 --
>>> drivers/staging/android/ion/ion_system_heap.c | 5
>>> 6 files changed, 65 deletions(-)
>>>
>>> diff --git a/drivers/staging/android/ion/ion-ioctl.c
>>> b/drivers/staging/android/ion/ion-ioctl.c index 5b2e93f..f820d77 100644
>>> --- a/drivers/staging/android/ion/ion-ioctl.c
>>> +++ b/drivers/staging/android/ion/ion-ioctl.c
>>> @@ -146,11 +146,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd,
>>> unsigned long arg)>
>>> data.handle.handle = handle->id;
>>>
>>> break;
>>>
>>> }
>>>
>>> - case ION_IOC_SYNC:
>>> - {
>>> - ret = ion_sync_for_device(client, data.fd.fd);
>>> - break;
>>> - }
>>
>> You missed the case ION_IOC_SYNC: in compat_ion.c.
>>
>> While at it: Should we also remove the entire custom_ioctl infrastructure?
>> It's entirely unused afaict, and for a pure buffer allocator I don't see
>> any need to have custom ioctl.
>
> I second that, if you want to make ion a standard API, then we certainly
> don't
> want any custom ioctl.
>
>> More code to remove potentially:
>> - The entire compat ioctl stuff - would be an abi break, but I guess if we
>> pick the 32bit abi and clean up the uapi headers we'll be mostly fine.
>> would allow us to remove compat_ion.c entirely.
>>
>> - ION_IOC_IMPORT: With this ion is purely an allocator, so not sure we
>> still need to be able to import anything. All the cache flushing/mapping
>> is done through dma-buf ops/ioctls.
>>
>>
Good point to all of the above. I was considering keeping the import around
for backwards compatibility reasons but given how much other stuff is being
potentially broken, everything should just get ripped out.
Thanks,
Laura
Re: [patch 3/3] speakup: add unicode variant of /dev/softsynth
Samuel Thibault writes: > This adds /dev/softsynthu, along /dev/softsynth, which emits output in > UTF-8 encoding, thus allowing to support 16bit characters. Most of the > code is shared, only the read function has to behave differently in > latin1 and in unicode mode. Since Linux only supports 16bit characters, > we can just hardcode the UTF-8 encoding. > > Signed-off-by: Samuel Thibault Reviewed-by: Chris Brannon Looks good to me.
[PATCH 4/6] staging: speakup: Blank lines removed after an open brace '{'
Blank lines aren't necessary after an open brace '{' as reported by
Checkpatch.pl.
Signed-off-by: Arushi Singhal
---
drivers/staging/speakup/kobjects.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/speakup/kobjects.c
b/drivers/staging/speakup/kobjects.c
index a82698c66568..16c4d3d1e873 100644
--- a/drivers/staging/speakup/kobjects.c
+++ b/drivers/staging/speakup/kobjects.c
@@ -761,7 +761,6 @@ static ssize_t message_store_helper(const char *buf, size_t
count,
enum msg_index_t curmessage;
while (cp < end) {
-
while ((cp < end) && (*cp == ' ' || *cp == '\t'))
cp++;
--
2.11.0
Re: [patch 1/3] speakup: extend synth buffer to 16bit unicode characters
Samuel Thibault writes: > This extends the synth buffer slots to 16bit, so as to hold 16bit > unicode characters. > > synth_buffer_getc and synth_buffer_peek now return 16bit characters. > Speech synthesizers which do not support characters beyond latin1 can > use the synth_buffer_skip_nonlatin1() helper to skip the non-latin1 > characters before getting or peeking. All synthesizers are made to use > it for now. > > This makes synth_buffer_add take a 16bit character. For simplicity for > now, synth_printf is left to using latin1 formats and strings. > synth_putwc, synth_putwc_s, synth_putws and synth_putws_s helpers are > however added to put 16bit characters and strings. > > Signed-off-by: Samuel Thibault Reviewed-by: Chris Brannon Looks good to me.
[PATCH 0/6] multiple checkpatch issues
Improve readability by fixing multiple checkpatch.pl
issues in speakup driver.
Arushi Singhal (6):
staging: speakup: Add blank line after function/struct/union/enum
declarations
staging: speakup: simple_strtoul is replaced with kstrtoul
staging: speakup: Logical continuations should be on the previous line
staging: speakup: Blank lines removed after an open brace '{'
staging: speakup: Avoid multiple assignments on same line
staging: speakup: fixes braces {} should be used on all arms of this
statement
drivers/staging/speakup/kobjects.c | 5 +-
drivers/staging/speakup/main.c | 84 --
drivers/staging/speakup/serialio.c | 1 +
drivers/staging/speakup/speakup_dtlk.c | 1 +
drivers/staging/speakup/varhandlers.c | 2 +-
5 files changed, 55 insertions(+), 38 deletions(-)
--
2.11.0
Re: [Outreachy kernel] [PATCH 5/6] staging: speakup: Avoid multiple assignments on same line
On Sat, 4 Mar 2017, Arushi Singhal wrote:
> This patch fixes the checkpatch.pl warning "multiple assignments
> should be avoided."
>
> Signed-off-by: Arushi Singhal
> ---
> drivers/staging/speakup/main.c | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
> index 4c3b5c627718..7915e75664f4 100644
> --- a/drivers/staging/speakup/main.c
> +++ b/drivers/staging/speakup/main.c
> @@ -269,9 +269,12 @@ static unsigned char get_attributes(struct vc_data *vc,
> u16 *pos)
>
> static void speakup_date(struct vc_data *vc)
> {
> - spk_x = spk_cx = vc->vc_x;
> - spk_y = spk_cy = vc->vc_y;
> - spk_pos = spk_cp = vc->vc_pos;
> + spk_x = vc->vc_x;
> + spk_cx = vc->vc_x;
> + spk_y = vc->vc_y;
> + spk_cy = vc->vc_y;
> + spk_pos = vc->vc_pos;
> + spk_cp = vc->vc_pos;
> spk_old_attr = spk_attr;
> spk_attr = get_attributes(vc, (u_short *)spk_pos);
> }
> @@ -1643,9 +1646,12 @@ static int speak_highlight(struct vc_data *vc)
> spk_do_flush();
> spkup_write(speakup_console[vc_num]->ht.highbuf[hc],
> speakup_console[vc_num]->ht.highsize[hc]);
> - spk_pos = spk_cp = speakup_console[vc_num]->ht.rpos[hc];
> - spk_x = spk_cx = speakup_console[vc_num]->ht.rx[hc];
> - spk_y = spk_cy = speakup_console[vc_num]->ht.ry[hc];
> + spk_pos = speakup_console[vc_num]->ht.rpos[hc];
> + spk_cp = speakup_console[vc_num]->ht.rpos[hc];
> + spk_x = speakup_console[vc_num]->ht.rx[hc];
> + spk_cx = speakup_console[vc_num]->ht.rx[hc];
> + spk_y = speakup_console[vc_num]->ht.ry[hc];
> + spk_cy = speakup_console[vc_num]->ht.ry[hc];
It could be better to put eg spk_cp = spk_pos;. Repeating th big
expression on the right hand side could be error prone in the long term.
julia
> return 1;
> }
> return 0;
> --
> 2.11.0
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/outreachy-kernel/20170303183707.14830-6-arushisinghal19971997%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
Re: net/ipv4: division by 0 in tcp_select_window
On Fri, Mar 3, 2017 at 10:24 AM, Dmitry Vyukov wrote:
> On Fri, Mar 3, 2017 at 7:10 PM, Dmitry Vyukov wrote:
>> Hello,
>>
> Wonder if this has been causing other crashes like this one?
>
> [ cut here ]
> kernel BUG at net/ipv4/tcp_output.c:2748!
> Call Trace:
>
> tcp_retransmit_skb+0x2e/0x230 net/ipv4/tcp_output.c:2822
> tcp_retransmit_timer+0x104c/0x2d50 net/ipv4/tcp_timer.c:491
> tcp_write_timer_handler+0x334/0x9d0 net/ipv4/tcp_timer.c:574
> tcp_write_timer+0x164/0x180 net/ipv4/tcp_timer.c:592
> call_timer_fn+0x241/0x820 kernel/time/timer.c:1266
> expire_timers kernel/time/timer.c:1305 [inline]
> __run_timers+0x960/0xcf0 kernel/time/timer.c:1599
> run_timer_softirq+0x21/0x80 kernel/time/timer.c:1612
> __do_softirq+0x31f/0xbe7 kernel/softirq.c:284
> invoke_softirq kernel/softirq.c:364 [inline]
> irq_exit+0x1cc/0x200 kernel/softirq.c:405
> exiting_irq arch/x86/include/asm/apic.h:658 [inline]
> smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:962
> apic_timer_interrupt+0x93/0xa0 arch/x86/entry/entry_64.S:487
>
> if (before(TCP_SKB_CB(skb)->seq, tp->snd_una)) {
> if (before(TCP_SKB_CB(skb)->end_seq, tp->snd_una))
> BUG();
This path uses a socket lock. Probably different problem.
[PATCH 3/6] staging: speakup: Logical continuations should be on the previous line
This patch fixes the checkpatch issue:
CHECK: Logical continuations should be on the previous line.
Signed-off-by: Arushi Singhal
---
drivers/staging/speakup/main.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index b43e2e156602..4c3b5c627718 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -564,18 +564,18 @@ static u_long get_word(struct vc_data *vc)
*buf = '\0';
synth_printf("%s\n", spk_msg_get(MSG_SPACE));
return 0;
- } else if ((tmpx < vc->vc_cols - 2)
- && (ch == SPACE || ch == 0 || IS_WDLM(ch))
- && ((char)get_char(vc, (u_short *)&tmp_pos + 1, &temp) >
- SPACE)) {
+ } else if ((tmpx < vc->vc_cols - 2) &&
+ (ch == SPACE || ch == 0 || IS_WDLM(ch)) &&
+ ((char)get_char(vc, (u_short *)&tmp_pos + 1, &temp) >
+ SPACE)) {
tmp_pos += 2;
tmpx++;
} else
while (tmpx > 0) {
ch = (char)get_char(vc, (u_short *)tmp_pos - 1, &temp);
- if ((ch == SPACE || ch == 0 || IS_WDLM(ch))
- && ((char)get_char(vc, (u_short *)tmp_pos, &temp) >
- SPACE))
+ if ((ch == SPACE || ch == 0 || IS_WDLM(ch)) &&
+ ((char)get_char(vc, (u_short *)tmp_pos, &temp) >
+SPACE))
break;
tmp_pos -= 2;
tmpx--;
@@ -586,8 +586,8 @@ static u_long get_word(struct vc_data *vc)
tmp_pos += 2;
tmpx++;
ch = (char)get_char(vc, (u_short *)tmp_pos, &temp);
- if ((ch == SPACE) || ch == 0
- || (IS_WDLM(buf[cnt - 1]) && (ch > SPACE)))
+ if ((ch == SPACE) || ch == 0 ||
+ (IS_WDLM(buf[cnt - 1]) && (ch > SPACE)))
break;
buf[cnt++] = ch;
}
@@ -725,8 +725,8 @@ static void spell_word(struct vc_data *vc)
synth_printf("%s", str_cap);
last_cap = str_cap;
}
- if (this_speakup_key == SPELL_PHONETIC
- && (isascii(ch) && isalpha(ch))) {
+ if (this_speakup_key == SPELL_PHONETIC &&
+ (isascii(ch) && isalpha(ch))) {
ch &= 31;
cp1 = phonetic[--ch];
} else {
@@ -895,8 +895,8 @@ static int get_sentence_buf(struct vc_data *vc, int
read_punc)
while (start < end) {
sentbuf[bn][i] = (char)get_char(vc, (u_short *)start, &tmp);
if (i > 0) {
- if (sentbuf[bn][i] == SPACE && sentbuf[bn][i - 1] == '.'
- && numsentences[bn] < 9) {
+ if (sentbuf[bn][i] == SPACE && sentbuf[bn][i - 1] ==
'.' &&
+ numsentences[bn] < 9) {
/* Sentence Marker */
numsentences[bn]++;
sentmarks[bn][numsentences[bn]] =
@@ -1280,8 +1280,8 @@ void spk_reset_default_chars(void)
/* First, free any non-default */
for (i = 0; i < 256; i++) {
- if (spk_characters[i]
- && (spk_characters[i] != spk_default_chars[i]))
+ if (spk_characters[i] &&
+ (spk_characters[i] != spk_default_chars[i]))
kfree(spk_characters[i]);
}
@@ -2073,8 +2073,8 @@ speakup_key(struct vc_data *vc, int shift_state, int
keycode, u_short keysym,
tty = vc->port.tty;
if (type >= 0xf0)
type -= 0xf0;
- if (type == KT_PAD
- && (vt_get_leds(fg_console, VC_NUMLOCK))) {
+ if (type == KT_PAD &&
+ (vt_get_leds(fg_console, VC_NUMLOCK))) {
if (up_flag) {
spk_keydown = 0;
goto out;
--
2.11.0
[PATCH] staging: speakup: else is not generally useful after a break or return
fixed checkpatch.pl warning: else is not generally useful after a break
or return.
Removed the else without affecting the logic.
Dead code is also eliminated.
Signed-off-by: Arushi Singhal
---
drivers/staging/speakup/keyhelp.c | 53 ++-
1 file changed, 19 insertions(+), 34 deletions(-)
diff --git a/drivers/staging/speakup/keyhelp.c
b/drivers/staging/speakup/keyhelp.c
index 4e6e5daba50c..ad3efded37c1 100644
--- a/drivers/staging/speakup/keyhelp.c
+++ b/drivers/staging/speakup/keyhelp.c
@@ -176,43 +176,28 @@ int spk_handle_help(struct vc_data *vc, u_char type,
u_char ch, u_short key)
synth_printf("%s\n", spk_msg_get(MSG_HELP_INFO));
build_key_data(); /* rebuild each time in case new mapping */
return 1;
- } else {
- name = NULL;
- if ((type != KT_SPKUP) && (key > 0) && (key <= num_key_names)) {
- synth_printf("%s\n",
-spk_msg_get(MSG_KEYNAMES_START + key - 1));
- return 1;
- }
- for (i = 0; funcvals[i] != 0 && !name; i++) {
- if (ch == funcvals[i])
- name = spk_msg_get(MSG_FUNCNAMES_START + i);
- }
- if (!name)
- return -1;
- kp = spk_our_keys[key] + 1;
- for (i = 0; i < nstates; i++) {
- if (ch == kp[i])
- break;
- }
- key += (state_tbl[i] << 8);
- say_key(key);
- synth_printf(spk_msg_get(MSG_KEYDESC), name);
- synth_printf("\n");
- return 1;
}
- name = spk_msg_get(MSG_FUNCNAMES_START + cur_item);
- func = funcvals[cur_item];
- synth_printf("%s", name);
- if (key_offsets[func] == 0) {
- synth_printf(" %s\n", spk_msg_get(MSG_IS_UNASSIGNED));
+
+ name = NULL;
+ if ((type != KT_SPKUP) && (key > 0) && (key <= num_key_names)) {
+ synth_printf("%s\n",
+spk_msg_get(MSG_KEYNAMES_START + key - 1));
return 1;
}
- p_keys = key_data + key_offsets[func];
- for (n = 0; p_keys[n]; n++) {
- val = p_keys[n];
- if (n > 0)
- synth_printf("%s ", spk_msg_get(MSG_DISJUNCTION));
- say_key(val);
+ for (i = 0; funcvals[i] != 0 && !name; i++) {
+ if (ch == funcvals[i])
+ name = spk_msg_get(MSG_FUNCNAMES_START + i);
+ }
+ if (!name)
+ return -1;
+ kp = spk_our_keys[key] + 1;
+ for (i = 0; i < nstates; i++) {
+ if (ch == kp[i])
+ break;
}
+ key += (state_tbl[i] << 8);
+ say_key(key);
+ synth_printf(spk_msg_get(MSG_KEYDESC), name);
+ synth_printf("\n");
return 1;
}
--
2.11.0
[PATCH v3 1/5] coresight: bindings for debug module
According to ARMv8 architecture reference manual (ARM DDI 0487A.k)
Chapter 'Part H: External debug', the CPU can integrate debug module
and it can support self-hosted debug and external debug. Especially
for supporting self-hosted debug, this means the program can access
the debug module from mmio region; and usually the mmio region is
integrated with coresight.
So add document for binding debug component, includes binding to APB
clock; and also need specify the CPU node which the debug module is
dedicated to specific CPU.
Suggested-by: Mike Leach
Reviewed-by: Mathieu Poirier
Signed-off-by: Leo Yan
---
.../devicetree/bindings/arm/coresight-debug.txt| 40 ++
1 file changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/coresight-debug.txt
diff --git a/Documentation/devicetree/bindings/arm/coresight-debug.txt
b/Documentation/devicetree/bindings/arm/coresight-debug.txt
new file mode 100644
index 000..92e5003
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/coresight-debug.txt
@@ -0,0 +1,40 @@
+* CoreSight Debug Component:
+
+CoreSight debug component are compliant with the ARMv8 architecture reference
+manual (ARM DDI 0487A.k) Chapter 'Part H: External debug'. The external debug
+module is mainly used for two modes: self-hosted debug and external debug, and
+it can be accessed from mmio region from Coresight and eventually the debug
+module connects with CPU for debugging. And the debug module provides
+sample-based profiling extension, which can be used to sample CPU program
+counter, secure state and exception level, etc; usually every CPU has one
+dedicated debug module to be connected.
+
+Required properties:
+
+- compatible : should be
+* "arm,coresight-debug"; supplemented with "arm,primecell" since
+ this driver is using the AMBA bus interface.
+
+- reg : physical base address and length of the register set.
+
+- clocks : the clock associated to this component.
+
+- clock-names : the name of the clock referenced by the code. Since we are
+using the AMBA framework, the name of the clock providing
+ the interconnect should be "apb_pclk" and the clock is
+ mandatory. The interface between the debug logic and the
+ processor core is clocked by the internal CPU clock, so it
+ is enabled with CPU clock by default.
+
+- cpu : the cpu phandle the debug module is affined to. When omitted
+ the module is considered to belong to CPU0.
+
+Example:
+
+ debug@f659 {
+ compatible = "arm,coresight-debug","arm,primecell";
+ reg = <0 0xf659 0 0x1000>;
+ clocks = <&sys_ctrl HI6220_DAPB_CLK>;
+ clock-names = "apb_pclk";
+ cpu = <&cpu0>;
+ };
--
2.7.4
Re: [RFC PATCH 04/12] staging: android: ion: Call dma_map_sg for syncing and mapping
On 03/03/2017 08:37 AM, Laurent Pinchart wrote:
> Hi Laura,
>
> Thank you for the patch.
>
> On Thursday 02 Mar 2017 13:44:36 Laura Abbott wrote:
>> Technically, calling dma_buf_map_attachment should return a buffer
>> properly dma_mapped. Add calls to dma_map_sg to begin_cpu_access to
>> ensure this happens. As a side effect, this lets Ion buffers take
>> advantage of the dma_buf sync ioctls.
>>
>> Signed-off-by: Laura Abbott
>> ---
>> drivers/staging/android/ion/ion.c | 101 +--
>> 1 file changed, 50 insertions(+), 51 deletions(-)
>>
>> diff --git a/drivers/staging/android/ion/ion.c
>> b/drivers/staging/android/ion/ion.c index ce4adac..a931b30 100644
>> --- a/drivers/staging/android/ion/ion.c
>> +++ b/drivers/staging/android/ion/ion.c
>> @@ -795,10 +795,6 @@ void ion_client_destroy(struct ion_client *client)
>> }
>> EXPORT_SYMBOL(ion_client_destroy);
>>
>> -static void ion_buffer_sync_for_device(struct ion_buffer *buffer,
>> - struct device *dev,
>> - enum dma_data_direction direction);
>> -
>> static struct sg_table *dup_sg_table(struct sg_table *table)
>> {
>> struct sg_table *new_table;
>> @@ -825,22 +821,43 @@ static struct sg_table *dup_sg_table(struct sg_table
>> *table) return new_table;
>> }
>>
>> +static void free_duped_table(struct sg_table *table)
>> +{
>> +sg_free_table(table);
>> +kfree(table);
>> +}
>> +
>> static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment
>> *attachment, enum dma_data_direction direction)
>> {
>> struct dma_buf *dmabuf = attachment->dmabuf;
>> struct ion_buffer *buffer = dmabuf->priv;
>> +struct sg_table *table;
>> +int ret;
>> +
>> +/*
>> + * TODO: Need to sync wrt CPU or device completely owning?
>> + */
>> +
>> +table = dup_sg_table(buffer->sg_table);
>>
>> -ion_buffer_sync_for_device(buffer, attachment->dev, direction);
>> -return dup_sg_table(buffer->sg_table);
>> +if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
>> +direction)){
>> +ret = -ENOMEM;
>> +goto err;
>> +}
>> +
>> +err:
>> +free_duped_table(table);
>> +return ERR_PTR(ret);
>> }
>>
>> static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
>>struct sg_table *table,
>>enum dma_data_direction direction)
>> {
>> -sg_free_table(table);
>> -kfree(table);
>> +dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
>> +free_duped_table(table);
>> }
>>
>> void ion_pages_sync_for_device(struct device *dev, struct page *page,
>> @@ -864,38 +881,6 @@ struct ion_vma_list {
>> struct vm_area_struct *vma;
>> };
>>
>> -static void ion_buffer_sync_for_device(struct ion_buffer *buffer,
>> - struct device *dev,
>> - enum dma_data_direction dir)
>> -{
>> -struct ion_vma_list *vma_list;
>> -int pages = PAGE_ALIGN(buffer->size) / PAGE_SIZE;
>> -int i;
>> -
>> -pr_debug("%s: syncing for device %s\n", __func__,
>> - dev ? dev_name(dev) : "null");
>> -
>> -if (!ion_buffer_fault_user_mappings(buffer))
>> -return;
>> -
>> -mutex_lock(&buffer->lock);
>> -for (i = 0; i < pages; i++) {
>> -struct page *page = buffer->pages[i];
>> -
>> -if (ion_buffer_page_is_dirty(page))
>> -ion_pages_sync_for_device(dev, ion_buffer_page(page),
>> - PAGE_SIZE, dir);
>> -
>> -ion_buffer_page_clean(buffer->pages + i);
>> -}
>> -list_for_each_entry(vma_list, &buffer->vmas, list) {
>> -struct vm_area_struct *vma = vma_list->vma;
>> -
>> -zap_page_range(vma, vma->vm_start, vma->vm_end - vma-
>> vm_start);
>> -}
>> -mutex_unlock(&buffer->lock);
>> -}
>> -
>> static int ion_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
>> {
>> struct ion_buffer *buffer = vma->vm_private_data;
>> @@ -1014,16 +999,24 @@ static int ion_dma_buf_begin_cpu_access(struct
>> dma_buf *dmabuf, struct ion_buffer *buffer = dmabuf->priv;
>> void *vaddr;
>>
>> -if (!buffer->heap->ops->map_kernel) {
>> -pr_err("%s: map kernel is not implemented by this heap.\n",
>> - __func__);
>> -return -ENODEV;
>> +/*
>> + * TODO: Move this elsewhere because we don't always need a vaddr
>> + */
>> +if (buffer->heap->ops->map_kernel) {
>> +mutex_lock(&buffer->lock);
>> +vaddr = ion_buffer_kmap_get(buffer);
>> +mutex_unlock(&buffer->lock);
>> }
>>
>> -mutex_lock(&buffer->lock);
>> -vaddr = ion_buffer_kmap_get(buffer);
>> -mutex_unlock(&buffer->lock);
>> -return PTR_ERR_OR_ZERO(vaddr);
>> +/*
>> + * Close enough right now? Flag to skip sync?
>> +
Re: [PATCH v17 2/3] usb: USB Type-C connector class
On Tue, Feb 21, 2017 at 05:24:04PM +0300, Heikki Krogerus wrote:
> +/* --- */
> +/* Driver callbacks to report role updates */
> +
> +/**
> + * typec_set_data_role - Report data role change
> + * @port: The USB Type-C Port where the role was changed
> + * @role: The new data role
> + *
> + * This routine is used by the port drivers to report data role changes.
> + */
> +void typec_set_data_role(struct typec_port *port, enum typec_data_role role)
> +{
> + if (port->data_role == role)
> + return;
> +
> + port->data_role = role;
> + sysfs_notify(&port->dev.kobj, NULL, "data_role");
> + kobject_uevent(&port->dev.kobj, KOBJ_CHANGE);
> +}
> +EXPORT_SYMBOL_GPL(typec_set_data_role);
> +
Hi Keikki,
Have you tested this interface with real dual-role controller/board?
What interface you use when you receive this event to handle
dual-role switch? I am wonder if a common dual-role class is
needed, then we can have a common user utility.
Eg, if "data_role" has changed, the udev can echo "data_role" to
/sys/class/usb-dual-role/role
Maybe we can enhance Roger's drd framework [1] to fulfill that.
[1] https://lwn.net/Articles/682531/
--
Best Regards,
Peter Chen
Re: [RFC PATCH 03/12] staging: android: ion: Duplicate sg_table
On 03/03/2017 12:18 AM, Hillf Danton wrote:
>
> On March 03, 2017 5:45 AM Laura Abbott wrote:
>>
>> +static struct sg_table *dup_sg_table(struct sg_table *table)
>> +{
>> +struct sg_table *new_table;
>> +int ret, i;
>> +struct scatterlist *sg, *new_sg;
>> +
>> +new_table = kzalloc(sizeof(*new_table), GFP_KERNEL);
>> +if (!new_table)
>> +return ERR_PTR(-ENOMEM);
>> +
>> +ret = sg_alloc_table(new_table, table->nents, GFP_KERNEL);
>> +if (ret) {
>> +kfree(table);
>
> Free new table?
>
>> +return ERR_PTR(-ENOMEM);
>> +}
>> +
>> +new_sg = new_table->sgl;
>> +for_each_sg(table->sgl, sg, table->nents, i) {
>> +memcpy(new_sg, sg, sizeof(*sg));
>> +sg->dma_address = 0;
>> +new_sg = sg_next(new_sg);
>> +}
>> +
>
> Do we need a helper, sg_copy_table(dst_table, src_table)?
>
>> +return new_table;
>> +}
>> +
Yes, that would probably be good since I've seen this
code elsewhere.
Thanks,
Laura
Re: [Outreachy kernel] [PATCH 6/6] staging: speakup: fixes braces {} should be used on all arms of this statement
On Sat, 4 Mar 2017, Arushi Singhal wrote:
> This patch fixes the checks reported by checkpatch.pl
> for braces {} should be used on all arms of this statement.
>
> Signed-off-by: Arushi Singhal
> ---
> drivers/staging/speakup/main.c | 29 +++--
> 1 file changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
> index 7915e75664f4..6179e0aafa25 100644
> --- a/drivers/staging/speakup/main.c
> +++ b/drivers/staging/speakup/main.c
> @@ -640,8 +640,9 @@ static void say_prev_word(struct vc_data *vc)
> break;
> spk_y--;
> spk_x = vc->vc_cols - 1;
> - } else
> + } else{
else needs a space after it.
julia
> spk_x--;
> + }
> spk_pos -= 2;
> ch = (char)get_char(vc, (u_short *)spk_pos, &temp);
> if (ch == SPACE || ch == 0)
> @@ -694,8 +695,9 @@ static void say_next_word(struct vc_data *vc)
> spk_y++;
> spk_x = 0;
> edge_said = edge_right;
> - } else
> + } else {
> spk_x++;
> + }
> spk_pos += 2;
> last_state = state;
> }
> @@ -722,8 +724,9 @@ static void spell_word(struct vc_data *vc)
> spk_pitch_shift++;
> else/* synth has no pitch */
> last_cap = spk_str_caps_stop;
> - } else
> + } else {
> str_cap = spk_str_caps_stop;
> + }
> if (str_cap != last_cap) {
> synth_printf("%s", str_cap);
> last_cap = str_cap;
> @@ -1331,8 +1334,9 @@ static int speakup_allocate(struct vc_data *vc)
> if (!speakup_console[vc_num])
> return -ENOMEM;
> speakup_date(vc);
> - } else if (!spk_parked)
> + } else if (!spk_parked) {
> speakup_date(vc);
> + }
>
> return 0;
> }
> @@ -1385,8 +1389,9 @@ static void read_all_doc(struct vc_data *vc)
> prev_cursor_track = cursor_track;
> cursor_track = read_all_mode;
> spk_reset_index_count(0);
> - if (get_sentence_buf(vc, 0) == -1)
> + if (get_sentence_buf(vc, 0) == -1) {
> kbd_fakekey2(vc, RA_DOWN_ARROW);
> + }
> else {
> say_sentence_num(0, 0);
> synth_insert_next_index(0);
> @@ -1434,8 +1439,9 @@ static void handle_cursor_read_all(struct vc_data *vc,
> int command)
> if (!say_sentence_num(sentcount + 1, 1)) {
> sn = 1;
> spk_reset_index_count(sn);
> - } else
> + } else {
> synth_insert_next_index(0);
> + }
> if (!say_sentence_num(sn, 0)) {
> kbd_fakekey2(vc, RA_FIND_NEXT_SENT);
> return;
> @@ -1464,8 +1470,9 @@ static void handle_cursor_read_all(struct vc_data *vc,
> int command)
> rv = get_sentence_buf(vc, 0);
> if (rv == -1)
> read_all_doc(vc);
> - if (rv == 0)
> + if (rv == 0) {
> kbd_fakekey2(vc, RA_FIND_NEXT_SENT);
> + }
> else {
> say_sentence_num(1, 0);
> synth_insert_next_index(0);
> @@ -2162,10 +2169,11 @@ speakup_key(struct vc_data *vc, int shift_state, int
> keycode, u_short keysym,
> if (type == KT_SPEC && value == 1) {
> value = '\n';
> type = KT_LATIN;
> - } else if (type == KT_LETTER)
> + } else if (type == KT_LETTER) {
> type = KT_LATIN;
> - else if (value == 0x7f)
> + } else if (value == 0x7f) {
> value = 8; /* make del = backspace */
> + }
> ret = (*spk_special_handler) (vc, type, value, keycode);
> spk_close_press = 0;
> if (ret < 0)
> @@ -2259,8 +2267,9 @@ static int vt_notifier_call(struct notifier_block *nb,
> speakup_deallocate(vc);
> break;
> case VT_WRITE:
> - if (param->c == '\b')
> + if (param->c == '\b') {
> speakup_bs(vc);
> + }
> else if (param->c < 0x100) {
> char d = param->c;
>
> --
> 2.11.0
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> T
Re: [Outreachy kernel] Re: [PATCH 1/7] staging: media: Remove unnecessary typecast of c90 int constant
On Fri, 3 Mar 2017, SIMRAN SINGHAL wrote: > On Fri, Mar 3, 2017 at 11:15 PM, Sakari Ailus wrote: > > Hi Simran, > > > > On Fri, Mar 03, 2017 at 01:21:56AM +0530, simran singhal wrote: > >> This patch removes unnecessary typecast of c90 int constant. > >> > >> WARNING: Unnecessary typecast of c90 int constant > >> > >> Signed-off-by: simran singhal > > > > Which tree are these patches based on? > Can you please explain what's the problem with this patch. And > please elaborate your question. It is probably staging-testing. julia > > > > > -- > > Regards, > > > > Sakari Ailus > > e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk > > -- > You received this message because you are subscribed to the Google Groups > "outreachy-kernel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to outreachy-kernel+unsubscr...@googlegroups.com. > To post to this group, send email to outreachy-ker...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/outreachy-kernel/CALrZqyOeOK2k1K8Z2Yt3SmvJQ8A%2BvigNBsd39-paPwkRAY6CVQ%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. >
Re: [PATCH] ARM: DTS armada: Add support for 2 more mvebu model
On Fri, Mar 03, 2017 at 06:07:35PM +0100, Ansuel Smith wrote: > This patch add support for 2 Linksys router model > (shelby and rango). With this we now support all > the mvebu board on the market. > > Signed-off-by: Imre Kaloz > Signed-off-by: Álvaro Fernández Rojas > Signed-off-by: Ansuel Smith > --- > arch/arm/boot/dts/armada-385-linksys-rango.dts | 443 > > arch/arm/boot/dts/armada-385-linksys-shelby.dts | 115 ++ > 2 files changed, 558 insertions(+) > create mode 100644 arch/arm/boot/dts/armada-385-linksys-rango.dts > create mode 100644 arch/arm/boot/dts/armada-385-linksys-shelby.dts > > diff --git a/arch/arm/boot/dts/armada-385-linksys-rango.dts > b/arch/arm/boot/dts/armada-385-linksys-rango.dts > new file mode 100644 > index 000..61f4592 > --- /dev/null > +++ b/arch/arm/boot/dts/armada-385-linksys-rango.dts > @@ -0,0 +1,443 @@ > +/* > + * Device Tree file for the Linksys WRT3200ACM (Rango) > + * > + * Copyright (C) 2016 Imre Kaloz > + * > + * > + * This file is dual-licensed: you can use it either under the terms > + * of the GPL or the X11 license, at your option. Note that this dual > + * licensing only applies to this file, and not this project as a > + * whole. > + * > + * a) This file is licensed under the terms of the GNU General Public > + * License version 2. This program is licensed "as is" without > + * any warranty of any kind, whether express or implied. > + * > + * Or, alternatively, > + * > + * b) Permission is hereby granted, free of charge, to any person > + * obtaining a copy of this software and associated documentation > + * files (the "Software"), to deal in the Software without > + * restriction, including without limitation the rights to use, > + * copy, modify, merge, publish, distribute, sublicense, and/or > + * sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following > + * conditions: > + * > + * The above copyright notice and this permission notice shall be > + * included in all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, > + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > + * OTHER DEALINGS IN THE SOFTWARE. > + */ > + > +/dts-v1/; > +#include > +#include > +#include "armada-385.dtsi" Hi Ansuel Please could you explain why you did not use armada-385-linksys.dtsi Thanks Andrew
Re: [PATCH 0/4] Improve intel-hid's self-consistency
On Thu, Mar 2, 2017 at 12:17 PM, Alex Hung wrote:
> On Thu, Mar 2, 2017 at 7:03 AM, Andy Shevchenko
> wrote:
>> On Fri, Feb 24, 2017 at 12:33 PM, Michał Kępień wrote:
>>> Commit 2cfa4b311acc ("platform/x86: intel-hid: Support 5 button array")
>>> contains some coding style cleanups compared to the code it was based
>>> on. This patch series "backports" these cleanups to the rest of the
>>> driver in order to make it more self-consistent and removes a redundant
>>> set_bit() call as a bonus.
>>>
>>> This series was not tested on hardware supported by intel-hid.
>>
>> Alex, do you have an access to hardware to test? I wouldn't going to
>> apply this until I get your tag(s) (in the best case
>> Reviewed-and-tested-by).
>
> The patches look good and tested on Latitude 7480
>
> Reviewed-and-tested-by: Alex Hung
Pushed to testing.
Thanks.
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v3 0/3] Add support for MyGica T230C DVB-T2 stick
On Fr, 2017-02-17 at 01:55 +0100, Stefan Brüns wrote: > The required command sequence for the new tuner (Si2141) was traced > from the > current Windows driver and verified with a small python > script/libusb. > The changes to the Si2168 and dvbsky driver are mostly additions of > the > required IDs and some glue code. > > Stefan Brüns (3): > [media] si2157: Add support for Si2141-A10 > [media] si2168: add support for Si2168-D60 > [media] dvbsky: MyGica T230C support > > drivers/media/dvb-core/dvb-usb-ids.h | 1 + > drivers/media/dvb-frontends/si2168.c | 4 ++ > drivers/media/dvb-frontends/si2168_priv.h | 2 + > drivers/media/tuners/si2157.c | 23 +++- > drivers/media/tuners/si2157_priv.h| 2 + > drivers/media/usb/dvb-usb-v2/dvbsky.c | 88 > +++ > 6 files changed, 118 insertions(+), 2 deletions(-) Instead of this series, a different patchset was accepted, although Antti raised concerns about at least 2 of the 3 patches accpeted, more specifically the si2157 patch contains some bogus initialization code, and the T230C support were better added to the dvbsky driver instead of cxusb. Kind regards, Stefan
Re: [PATCH v2 1/3] soc: qcom: Add scm call to protect modem mem in qcom scm driver.
On 2/28/2017 4:25 AM, Stephen Boyd wrote:
On 01/30, Avaneesh Kumar Dwivedi wrote:
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 893f953ea..f476803 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -292,6 +292,20 @@ int qcom_scm_pas_shutdown(u32 peripheral)
}
EXPORT_SYMBOL(qcom_scm_pas_shutdown);
+/**
+ * qcom_scm_assign_mem() - Apply new access permission of DDR
+ * region passed via descriptor and does second stage
+ * translation of intermediate physical address.
+ * @desc: descriptor to send to hypervisor
+ *
+ * Return 0 on success.
+ */
+int qcom_scm_assign_mem(void *desc)
Please don't pass a void pointer here. Driver authors shouldn't
need to know about qcom_scm_desc. This should be an API that the
driver can use without knowing intimate firmware details.
OK, so i will try to move hyp_mem_assign() to qcom_scm driver, as suggested.
this way the above issue will also get resolved.
+{
+ return __qcom_scm_assign_mem(__scm->dev, desc);
+}
+EXPORT_SYMBOL(qcom_scm_assign_mem);
+
static int qcom_scm_pas_reset_assert(struct reset_controller_dev *rcdev,
unsigned long idx)
{
diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
index 3584b00..d88fd4b 100644
--- a/drivers/firmware/qcom_scm.h
+++ b/drivers/firmware/qcom_scm.h
@@ -47,6 +47,8 @@ extern int __qcom_scm_hdcp_req(struct device *dev,
#define QCOM_SCM_PAS_SHUTDOWN_CMD 0x6
#define QCOM_SCM_PAS_IS_SUPPORTED_CMD 0x7
#define QCOM_SCM_PAS_MSS_RESET0xa
+#define QCOM_SCM_SVC_MP0xc
+#define QCOM_MEM_PROT_ASSIGN_ID0x16
Presumably these should go near the newly introduced functions
like how the rest of this file is organized.
OK.
extern bool __qcom_scm_pas_supported(struct device *dev, u32 peripheral);
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
Re: [PATCH 0/2] fs, ceph filesystem refcount conversions
On Fri, Mar 3, 2017 at 10:15 AM, Elena Reshetova wrote: > Now when new refcount_t type and API are finally merged > (see include/linux/refcount.h), the following > patches convert various refcounters in the ceph filesystem from atomic_t > to refcount_t. By doing this we prevent intentional or accidental > underflows or overflows that can led to use-after-free vulnerabilities. > > The below patches are fully independent and can be cherry-picked separately. > Since we convert all kernel subsystems in the same fashion, resulting > in about 300 patches, we have to group them for sending at least in some > fashion to be manageable. Please excuse the long cc list. > > Not runtime tested, since I am not sure how to do it for ceph. > However changes are pretty trivial in this case. > > Elena Reshetova (2): > fs, ceph: convert ceph_mds_session.s_ref from atomic_t to refcount_t > fs, ceph: convert ceph_cap_snap.nref from atomic_t to refcount_t > > fs/ceph/caps.c | 4 ++-- > fs/ceph/mds_client.c | 18 +- > fs/ceph/mds_client.h | 5 +++-- > fs/ceph/snap.c | 2 +- > fs/ceph/super.h | 5 +++-- > 5 files changed, 18 insertions(+), 16 deletions(-) I'll pull these into testing. Thanks, Ilya
Re: [PATCH v2 2/3] remoteproc: qcom: Add scm call to protect modem mem in mss rproc drv.
On 2/28/2017 12:46 PM, Stephen Boyd wrote:
On 01/30, Avaneesh Kumar Dwivedi wrote:
This patch add hypervisor call support for second stage translation from
mss remoteproc driver, this is required so that modem on msm8996 which is
based on armv8 architecture can access DDR region where modem firmware
are loaded.
Signed-off-by: Avaneesh Kumar Dwivedi
---
Most of this should be combined with patch 1 from this series.
OK.
drivers/remoteproc/qcom_q6v5_pil.c | 202 -
1 file changed, 198 insertions(+), 4 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5_pil.c
b/drivers/remoteproc/qcom_q6v5_pil.c
index e5edefa..35eee68 100644
--- a/drivers/remoteproc/qcom_q6v5_pil.c
+++ b/drivers/remoteproc/qcom_q6v5_pil.c
@@ -93,6 +93,23 @@
#define QDSS_BHS_ON BIT(21)
#define QDSS_LDO_BYP BIT(22)
+struct dest_vm_and_perm_info {
+ __le32 vm;
+ __le32 perm;
+ __le32 *ctx;
+ __le32 ctx_size;
+};
+
+struct mem_prot_info {
+ __le64 addr;
+ __le64 size;
+};
+
+struct scm_desc {
+ __le32 arginfo;
+ __le64 args[10];
+};
These are all firmware specific things that should live in scm
code, not PIL code.
OK.
+
struct reg_info {
struct regulator *reg;
int uV;
@@ -111,6 +128,7 @@ struct rproc_hexagon_res {
struct qcom_mss_reg_res active_supply[2];
char **proxy_clk_names;
char **active_clk_names;
+ int version;
};
struct q6v5 {
@@ -152,8 +170,29 @@ struct q6v5 {
phys_addr_t mpss_reloc;
void *mpss_region;
size_t mpss_size;
+ int version;
+ int protection_cmd;
+};
+
+enum {
+ MSS_MSM8916,
+ MSS_MSM8974,
+ MSS_MSM8996,
};
+enum {
+ ASSIG_ACCESS_MSA,
+ REMOV_ACCESS_MSA,
+ SHARE_ACCESS_MSA,
+ REMOV_SHARE_MSA,
+};
+
+#define VMID_HLOS 0x3
+#define VMID_MSS_MSA 0xF
+#define PERM_READ 0x4
+#define PERM_WRITE 0x2
+#define PERM_EXEC 0x1
+#define PERM_RW(0x4 | 0x2)
Please USE PERM_READ | PERM_WRITE here instead.
OK.
static int q6v5_regulator_init(struct device *dev, struct reg_info *regs,
const struct qcom_mss_reg_res *reg_res)
{
@@ -273,12 +312,123 @@ static void q6v5_clk_disable(struct device *dev,
clk_disable_unprepare(clks[i]);
}
+int hyp_mem_access(struct q6v5 *qproc, phys_addr_t addr, size_t size)
This could be the scm API for now. But instead of taking qproc,
it would take the protection_cmd variable (which looks sort of
like a state machine BTW). To be more generic, perhaps it should
take the src vmids + num src vmids, dst vmids + num dst vmids,
and protection flags (which looks to be same size as dst vmid
array). If we can get the right SCM API here everything else
should fall into place.
Will analyses and modify as per suggestion.
+{
+ unsigned long dma_attrs = DMA_ATTR_FORCE_CONTIGUOUS;
+ struct dest_vm_and_perm_info *dest_info;
+ struct mem_prot_info *mem_prot_info;
+ struct scm_desc desc = {0};
+ __le32 *source_vm_copy;
+ __le64 mem_prot_phy;
+ int dest_count = 1;
+ int src_count = 1;
+ __le32 *perm = {0};
+ __le32 *dest = {0};
+ __le32 *src = {0};
src/dst seem like pretty confusing names. It makes it sound like
a memcpy operation. Perhaps from/to is better? Or current/next.
OK
+ __le64 phys_src;
+ __le64 phy_dest;
+ int ret;
+ int i;
+
+ if (qproc->version != MSS_MSM8996)
+ return 0;
+
+ switch (qproc->protection_cmd) {
+ case ASSIG_ACCESS_MSA: {
+ src = (int[2]) {VMID_HLOS, 0};
+ dest = (int[2]) {VMID_MSS_MSA, 0};
+ perm = (int[2]) {PERM_READ | PERM_WRITE, 0};
Why have two element arrays when we're only using the first
element? Relying on default src_count of 1 is very confusing.
in some cases we initialize two elements.
+ break;
+ }
+ case REMOV_ACCESS_MSA: {
+ src = (int[2]) {VMID_MSS_MSA, 0};
+ dest = (int[2]) {VMID_HLOS, 0};
+ perm = (int[2]) {PERM_READ | PERM_WRITE | PERM_EXEC, 0};
Same here.
OK.
+ break;
+ }
+ case SHARE_ACCESS_MSA: {
+ src = (int[2]) {VMID_HLOS, 0};
+ dest = (int[2]) {VMID_HLOS, VMID_MSS_MSA};
+ perm = (int[2]) {PERM_RW, PERM_RW};
Please add spaces around curly braces like { this }
OK.
+ dest_count = 2;
+ break;
+ }
+ case REMOV_SHARE_MSA: {
And write REMOVE_SHARE_MSA, ASSIGN_ACCESS_MSA, etc. instead of
dropping letters.
OK.
+ src = (int[2]) {VMID_HLOS, VMID_MSS_MSA};
+ dest
Re: net/ipv4: division by 0 in tcp_select_window
On Fri, Mar 3, 2017 at 10:10 AM, Dmitry Vyukov wrote: > Hello, > > The following program triggers division by 0 in tcp_select_window: > > https://gist.githubusercontent.com/dvyukov/ef28c0fd2ab57a655508ef7621b12e6c/raw/079011e2a9523a390b0621cbc1e5d9d5e637fd6d/gistfile1.txt Yeah, tcp_disconnect() should never have existed in the first place. We'll send a patch, unless you take care of this before us . Thanks.
Re: net/ipv4: division by 0 in tcp_select_window
On Fri, Mar 3, 2017 at 7:10 PM, Dmitry Vyukov wrote:
> Hello,
>
> The following program triggers division by 0 in tcp_select_window:
>
> https://gist.githubusercontent.com/dvyukov/ef28c0fd2ab57a655508ef7621b12e6c/raw/079011e2a9523a390b0621cbc1e5d9d5e637fd6d/gistfile1.txt
>
> divide error: [#1] SMP KASAN
> Modules linked in:
> CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.10.0+ #270
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: 88006c236340 task.stack: 88006c248000
> RIP: 0010:__tcp_select_window+0x6db/0x920 net/ipv4/tcp_output.c:2585
> RSP: 0018:88006cf86b40 EFLAGS: 00010206
> RAX: 00c4 RBX: 88006cf86cd8 RCX: dc00
> RDX: RSI: RDI: 8800686228bd
> RBP: 88006cf86d00 R08: R09:
> R10: 0004 R11: ed000d9f0e18 R12: 00c4
> R13: a700 R14: 880068622040 R15:
> FS: () GS:88006cf8() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 20e5cff8 CR3: 05021000 CR4: 001406e0
> Call Trace:
>
> tcp_select_window net/ipv4/tcp_output.c:270 [inline]
> tcp_transmit_skb+0xc35/0x3460 net/ipv4/tcp_output.c:1014
> tcp_xmit_probe_skb+0x36d/0x440 net/ipv4/tcp_output.c:3528
> tcp_write_wakeup+0x23b/0x6d0 net/ipv4/tcp_output.c:3577
> tcp_send_probe0+0xbf/0x5d0 net/ipv4/tcp_output.c:3593
> tcp_probe_timer net/ipv4/tcp_timer.c:362 [inline]
> tcp_write_timer_handler+0x849/0x9d0 net/ipv4/tcp_timer.c:578
> tcp_write_timer+0x164/0x180 net/ipv4/tcp_timer.c:592
> call_timer_fn+0x241/0x820 kernel/time/timer.c:1266
> expire_timers kernel/time/timer.c:1305 [inline]
> __run_timers+0x960/0xcf0 kernel/time/timer.c:1599
> run_timer_softirq+0x21/0x80 kernel/time/timer.c:1612
> __do_softirq+0x31f/0xbe7 kernel/softirq.c:284
> invoke_softirq kernel/softirq.c:364 [inline]
> irq_exit+0x1cc/0x200 kernel/softirq.c:405
> exiting_irq arch/x86/include/asm/apic.h:658 [inline]
> smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:962
> apic_timer_interrupt+0x93/0xa0 arch/x86/entry/entry_64.S:487
> RIP: 0010:native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:53
> RSP: 0018:88006c24fc10 EFLAGS: 0282 ORIG_RAX: ff10
> RAX: dc00 RBX: 11000d849f85 RCX:
> RDX: 10a18ebc RSI: 0001 RDI: 850c75e0
> RBP: 88006c24fc10 R08: 88007fff70dc R09:
> R10: R11: R12: 11000d849fa9
> R13: 88006c24fcc8 R14: 856972b8 R15: 88006c24fe68
>
> arch_safe_halt arch/x86/include/asm/paravirt.h:98 [inline]
> default_idle+0xbf/0x440 arch/x86/kernel/process.c:271
> arch_cpu_idle+0xa/0x10 arch/x86/kernel/process.c:262
> default_idle_call+0x36/0x90 kernel/sched/idle.c:96
> cpuidle_idle_call kernel/sched/idle.c:154 [inline]
> do_idle+0x373/0x520 kernel/sched/idle.c:243
> cpu_startup_entry+0x18/0x20 kernel/sched/idle.c:345
> start_secondary+0x36c/0x460 arch/x86/kernel/smpboot.c:272
> start_cpu+0x14/0x14 arch/x86/kernel/head_64.S:306
> Code: 5d c3 e8 99 0d e5 fd 45 85 ff 44 89 bd 74 fe ff ff 0f 8f 14 fc
> ff ff 45 31 e4 eb 93 e8 7f 0d e5 fd 8b b5 74 fe ff ff 44 89 e0 99
> fe 41 89 c4 44 0f af e6 e9 71 ff ff ff e8 62 0d e5 fd 4c 89
> RIP: __tcp_select_window+0x6db/0x920 net/ipv4/tcp_output.c:2585 RSP:
> 88006cf86b40
> ---[ end trace 5efcbe8231e36800 ]---
>
> On commit c82be9d2244aacea9851c86f4fb74694c99cd874.
>
> The guy that resets mss seems to be
> inet_csk_listen_start->inet_csk_delack_init. After that the timer
> fires and divides by icsk->icsk_ack.rcv_mss==0.
Wonder if this has been causing other crashes like this one?
[ cut here ]
kernel BUG at net/ipv4/tcp_output.c:2748!
Call Trace:
tcp_retransmit_skb+0x2e/0x230 net/ipv4/tcp_output.c:2822
tcp_retransmit_timer+0x104c/0x2d50 net/ipv4/tcp_timer.c:491
tcp_write_timer_handler+0x334/0x9d0 net/ipv4/tcp_timer.c:574
tcp_write_timer+0x164/0x180 net/ipv4/tcp_timer.c:592
call_timer_fn+0x241/0x820 kernel/time/timer.c:1266
expire_timers kernel/time/timer.c:1305 [inline]
__run_timers+0x960/0xcf0 kernel/time/timer.c:1599
run_timer_softirq+0x21/0x80 kernel/time/timer.c:1612
__do_softirq+0x31f/0xbe7 kernel/softirq.c:284
invoke_softirq kernel/softirq.c:364 [inline]
irq_exit+0x1cc/0x200 kernel/softirq.c:405
exiting_irq arch/x86/include/asm/apic.h:658 [inline]
smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:962
apic_timer_interrupt+0x93/0xa0 arch/x86/entry/entry_64.S:487
if (before(TCP_SKB_CB(skb)->seq, tp->snd_una)) {
if (before(TCP_SKB_CB(skb)->end_seq, tp->snd_una))
BUG();
Re: [PATCH v4 1/3] x86: Introduce a new constant KERNEL_MAPPING_SIZE
Ok, TBH, I still don't like adding yet another define and paying attention to whether I should use image size or mapping size. After your patch, KERNEL_IMAGE_SIZE is used to enforce the actual image size from exploding: arch/x86/include/asm/page_32_types.h:43:#define KERNEL_IMAGE_SIZE (512 * 1024 * 1024) arch/x86/include/asm/page_32_types.h:49:#define KERNEL_MAPPING_SIZE KERNEL_IMAGE_SIZE arch/x86/include/asm/page_64_types.h:56:#define KERNEL_IMAGE_SIZE (512 * 1024 * 1024) arch/x86/include/asm/pgtable_32.h:83: * (KERNEL_IMAGE_SIZE/4096) / 1024 pages (worst case, non PAE) arch/x86/include/asm/pgtable_32.h:84: * (KERNEL_IMAGE_SIZE/4096) / 512 + 4 pages (worst case for PAE) arch/x86/include/asm/pgtable_32.h:91: * KERNEL_IMAGE_SIZE should be greater than pa(_end) arch/x86/kernel/vmlinux.lds.S:356:. = ASSERT((_end - LOAD_OFFSET <= KERNEL_IMAGE_SIZE), arch/x86/kernel/vmlinux.lds.S:357: "kernel image bigger than KERNEL_IMAGE_SIZE"); arch/x86/kernel/vmlinux.lds.S:370:. = ASSERT((_end - _text <= KERNEL_IMAGE_SIZE), arch/x86/kernel/vmlinux.lds.S:371: "kernel image bigger than KERNEL_IMAGE_SIZE"); So what I'd do is keep KERNEL_IMAGE_SIZE and make it default 1G and use it everywhere. Then, define a separate define which is used only in vmlinux.lds.S to enforce the size check. Having MAPPING_SIZE and IMAGE_SIZE is just needlessly confusing. Especially if this is just some inconsistency you're addressing and not some real issue. BUT(!), don't take my word for it. Rather, do what the maintainers propose. Who knows, they might have a much better idea. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
[PATCH 2/3] futex: fix decoding of operation
encoded_op uses int as type which results in pretty weird behaviour.
E.g. if encoded_op contains oparg 0xfff, it currently results in oparg
being -1.
Switch encoded_op to 'unsigned int' which is correct given it is a bit
mask anyway. And perform upper bound checking on oparg to inform users
about the failure. Finally, avoid int overflows using unsigned shift on
oparg. Note that given we use -fno-strict-overflow, this is not a fix as
there is no problem to fix in the first place.
Signed-off-by: Jiri Slaby
---
kernel/futex.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index c5ff9850952f..c09424406560 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1457,7 +1457,7 @@ futex_wake(u32 __user *uaddr, unsigned int flags, int
nr_wake, u32 bitset)
return ret;
}
-static int futex_atomic_op_inuser(int encoded_op, u32 __user *uaddr)
+static int futex_atomic_op_inuser(unsigned int encoded_op, u32 __user *uaddr)
{
int op = (encoded_op >> 28) & 7;
int cmp = (encoded_op >> 24) & 15;
@@ -1465,8 +1465,11 @@ static int futex_atomic_op_inuser(int encoded_op, u32
__user *uaddr)
int cmparg = (encoded_op << 20) >> 20;
int oldval, ret;
- if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28))
- oparg = 1 << oparg;
+ if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28)) {
+ if (oparg >= 32)
+ return -EINVAL;
+ oparg = 1U << oparg;
+ }
if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
return -EFAULT;
--
2.12.0
Re: [PATCH v2 3/3] remoteproc: qcom: Add msm8996 specific changes in mss rproc driver.
On 03/03, Dwivedi, Avaneesh Kumar (avani) wrote:
> On 2/28/2017 4:18 AM, Stephen Boyd wrote:
> >On 01/30, Avaneesh Kumar Dwivedi wrote:
> >>@@ -1213,6 +1299,47 @@ static int q6v5_remove(struct platform_device *pdev)
> >>return 0;
> >> }
> >>+static const struct rproc_hexagon_res msm8996_mss = {
> >>+ .hexagon_mba_image = "mba.mbn",
> >>+ .proxy_supply = (struct qcom_mss_reg_res[]) {
> >>+ {
> >>+ .supply = "vdd_mx",
> >>+ .uV = 6,
> >>+ },
> >>+ {
> >>+ .supply = "vdd_cx",
> >>+ .uV = 7,
> >>+ .uA = 10,
> >>+ },
> >vdd cx and vdd mx are corners. The plan is to _not_ use the
> >regulator framework for those, so treating them like supplies is
> >incorrect here.
> vdd cx and mx though in downstream are voted for corner but they are
> always ON domain upstream as per regulator team when i discussed
> with them.
> should i drop them altogether?
I would say yes, drop them. The on/off state doesn't matter here.
This code wants to max out the corner for a period of time until
the remote processor has booted far enough to make their own vote
on these RPM resources.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data
On March 1, 2017 2:27:54 AM PST, Ingo Molnar wrote: > >* Thomas Gleixner wrote: > >> On Wed, 1 Mar 2017, Ingo Molnar wrote: >> > >> > * Jiri Slaby wrote: >> > >> > > This is a start of series to unify use of ENTRY, ENDPROC, GLOBAL, >END, >> > > and other macros across x86. When we have all this sorted out, >this will >> > > help to inject DWARF unwinding info by objtool later. >> > > >> > > So, let us use the macros this way: >> > > * ENTRY -- start of a global function >> > > * ENDPROC -- end of a local/global function >> > > * GLOBAL -- start of a globally visible data symbol >> > > * END -- end of local/global data symbol >> > >> > So how about using macro names that actually show the purpose, >instead of >> > importing all the crappy, historic, essentially randomly chosen >debug symbol macro >> > names from the binutils and older kernels? >> > >> > Something sane, like: >> > >> >SYM__FUNCTION_START >> >> Sane would be: >> >> SYM_FUNCTION_START >> >> The double underscore is just not giving any value. > >So the double underscore (at least in my view) has two advantages: > >1) it helps separate the prefix from the postfix. > >I.e. it's a 'symbols' namespace, and a 'function start', not the >'start' of a >'symbol function'. > >2) It also helps easy greppability. > >Try this in latest -tip: > > git grep e820__ > >To see all the E820 API calls - with no false positives! > >'git grep e820_' on the other hand is a lot less reliable... > >But no strong feelings either way, I just try to sneak in these small >namespace >structure tricks when nobody's looking! ;-) > >Thanks, > > Ingo This seems needlessly verbose to me and clutters the code. How about: PROC..ENDPROC, LOCALPROC..ENDPROC and DATA..ENDDATA. Clear, unambiguous and balanced. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[PATCH 3/3] futex: make the encoded_op decoding readable
Decoding of encoded_op is a bit unreadable. It contains shifts to the
left and to the right by some constants. Make it clearly visible what
part of the bit mask is taken and shift the values only to the right
appropriatelly.
Signed-off-by: Jiri Slaby
---
kernel/futex.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index c09424406560..5834df248f09 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1459,10 +1459,10 @@ futex_wake(u32 __user *uaddr, unsigned int flags, int
nr_wake, u32 bitset)
static int futex_atomic_op_inuser(unsigned int encoded_op, u32 __user *uaddr)
{
- int op = (encoded_op >> 28) & 7;
- int cmp = (encoded_op >> 24) & 15;
- int oparg = (encoded_op << 8) >> 20;
- int cmparg = (encoded_op << 20) >> 20;
+ int op = (encoded_op& 0x7000) >> 28;
+ int cmp = (encoded_op & 0x0f00) >> 24;
+ int oparg = (encoded_op & 0x00fff000) >> 12;
+ int cmparg = encoded_op & 0x0fff;
int oldval, ret;
if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28)) {
--
2.12.0
Re: [PATCH 1/7] staging: media: Remove unnecessary typecast of c90 int constant
On Fri, Mar 3, 2017 at 11:15 PM, Sakari Ailus wrote: > Hi Simran, > > On Fri, Mar 03, 2017 at 01:21:56AM +0530, simran singhal wrote: >> This patch removes unnecessary typecast of c90 int constant. >> >> WARNING: Unnecessary typecast of c90 int constant >> >> Signed-off-by: simran singhal > > Which tree are these patches based on? Can you please explain what's the problem with this patch. And please elaborate your question. > > -- > Regards, > > Sakari Ailus > e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
Re: [PATCH v2 2/3] remoteproc: qcom: Add scm call to protect modem mem in mss rproc drv.
On 03/03, Dwivedi, Avaneesh Kumar (avani) wrote: > On 2/28/2017 12:46 PM, Stephen Boyd wrote: > >On 01/30, Avaneesh Kumar Dwivedi wrote: > >>+ dest_info[i].vm = dest[i]; > >>+ dest_info[i].perm = perm[i]; > >Needs to do a cpu_to_le32() somewhere. Please run sparse. > I understand that byte reordering needed but not sure what is sparse > will check and do it. http://git.kernel.org/cgit/devel/sparse/sparse.git/ > > > >>+ dest_info[i].ctx = NULL; > >>+ dest_info[i].ctx_size = 0; > >>+ } > >Perhaps we should just allocate these first (one or two elements > >isn't a big difference) and then fill the details in directly. > Not very clear what is ask here? > > I'm saying we could fill in dest_info in the case statement instead of here in an up to 2 times loop. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH] drm/arcpgu: Get rid of "encoder-slave" property
On Fri, Mar 03, 2017 at 05:48:19PM +, Alexey Brodkin wrote:
> Hi Liviu,
>
> On Fri, 2017-03-03 at 16:28 +, Liviu Dudau wrote:
> > On Fri, Mar 03, 2017 at 06:19:24PM +0300, Alexey Brodkin wrote:
> > >
> > > - /* find the encoder node and initialize it */
> > > - encoder_node = of_parse_phandle(drm->dev->of_node, "encoder-slave", 0);
> > > - if (encoder_node) {
> > > - ret = arcpgu_drm_hdmi_init(drm, encoder_node);
> > > - of_node_put(encoder_node);
> > > + /* There is only one output port inside each device, find it */
> > > + port = of_graph_get_next_endpoint(pdev->dev.of_node, NULL);
> > > +
> > > + if (port) {
> > > + if (of_device_is_available(port))
> > > + encoder = of_graph_get_remote_port_parent(port);
> > > + of_node_put(port);
> > > + }
> >
> > You must've been looking at some old version. Current version in -next uses
> > of_graph_get_remote_node() to replace all those lines you have added (see
> > Rob
> > Herring's series to introduce of_graph_get_remote_node() function)
>
> Hm, I'm not on Linus' master tree [1] and so I thought I was quite up to date
> :)
> Still I made a check of linux-next and don't see any changes in
> "drivers/gpu/drm/arm" compared to Linus' tree.
>
> [1]
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/arm?id=e4563f6ba71792c77aeccb2092cc23149b44e642
> [2]
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/arm?id=e4563f6ba71792c77aeccb2092cc23149b44e642
>
> Could you please clarify which exact tree did you mean?
Sorry, I thought the series got pulled by one of the DRM trees, but it looks
like
I was wrong. I was carrying a private copy in my internal tree, waiting for the
moment when it got pulled into drm-next or drm-misc-next.
Rob, do you have an update on your series introducing
of_graph_get_remote_node() ?
Best regards,
Liviu
>
> Anyways I just tried to rebase my patch on top of linux-next tree and now
> video output is broken for me - I only see some garbage on top of the screen
> so I'll need to investigate it first before moving forward with stuff you
> proposed :)
>
> -Alexey
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
[BUG 4.9/4.10] crash in __d_lookup() due to corrupted dentry_hashtable
Hello Al,
Gustavo reported the crash below within __d_lookup() on s390. I'm wondering
if you can make any sense of it:
Unable to handle kernel pointer dereference in virtual kernel address space
Failing address: f000 TEID: f803
Fault in home space mode while using kernel ASCE.
AS:00ec8007 R3:0003dc5f4007 S:0020
Oops: 0038 ilc:3 [#1] SMP
Modules linked in: dm_mirror dm_region_hash dm_log raid1 dm_raid raid456
async_raid6_recov async_memcpy async_pq async_xor async_tx dm_service_time
paes_s390 pkey zcrypt rng_core xt_CHECKSUM iptable_mangle ipt_MASQUERADE
nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4
nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp
bridge stp llc ip6table_filter ip6_tables iptable_filter aes_s390 des_s390
des_generic sha512_s390 sha256_s390 vmur sha1_s390 sha_common vhost_net nfsd
tun vhost macvtap auth_rpcgss macvlan nfs_acl lockd kvm sch_fq_codel grace
sunrpc dm_multipath dm_mod ip_tables x_tables autofs4
CPU: 1 PID: 31708 Comm: fio Tainted: GW
4.10.0-20170228.0.1e014e7.d661408.fc24.s390xperformance #1
Hardware name: IBM 2964 N96 704 (z/VM)
task: f7e55d00 task.stack: 00023124c000
Krnl PSW : 0704e0018000 0033539e (__d_lookup+0x6e/0x168)
R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
Krnl GPRS: 002f 03e0806248f8 82313080 00d2abe0
00023124fc00 00023124fbfc 003b08a8 0003dafac220
82313080 00023124fdc8 00026248fcce
fffe 0094b420 00023124faf0 00023124faa0
Krnl Code: 00335392: b9040082lgr %r8,%r2
00335396: a798lhi %r9,0
#0033539a: a7f40008brc 15,3353aa
>0033539e: e3c0c004lg %r12,0(%r12)
003353a4: ecc8001d007ccgij%r12,0,8,3353de
003353aa: 59b0c01cc %r11,28(%r12)
003353ae: a774fff8brc 7,33539e
003353b2: 4120c050la %r2,80(%r12)
Call Trace:
([<82313080>] 0x82313080)
[<00327026>] lookup_fast+0x19e/0x340
[<00327530>] walk_component+0x48/0x358
[<00327980>] link_path_walk+0x140/0x508
[<00328806>] path_openat+0xae/0x1320
[<0032af26>] do_filp_open+0x86/0x108
[<00315b5c>] do_sys_open+0x174/0x250
[<00922d5c>] system_call+0xc4/0x264
Last Breaking-Event-Address:
[<003353ae>] __d_lookup+0x7e/0x168
Kernel panic - not syncing: Fatal exception: panic_on_oops
Looking at the relevant part of __d_lookup:
struct dentry *__d_lookup(const struct dentry *parent, const struct qstr *name)
{
unsigned int hash = name->hash;
struct hlist_bl_head *b = d_hash(hash); <--- points to corrupted entry
struct hlist_bl_node *node;
struct dentry *found = NULL;
struct dentry *dentry;
rcu_read_lock();
hlist_bl_for_each_entry_rcu(dentry, node, b, d_hash) {
if (dentry->d_name.hash != hash)
continue;
...
The contents of *b within the dump is:
> struct hlist_bl_head 03e0806248f8
struct hlist_bl_head {
first = 0x
}
Note that 0x03e0806248f8 is a valid address within the
dentry_hashtable. In addition all other entries look ok, as far as I can
tell. This is the only entry that contains a -1UL value.
We also have a second dump with a similar crash with a 4.9 kernel. In that
case there are in total three entries spread within the dentry_hashtable
with a -1UL value, while all other entries seem to look ok. So there seems
to be a pattern.
Note: these kernels do contain addon patches that are not mainline, but I
don't believe that any of those can explain these corruptions.
Re: [PATCH v2 3/3] remoteproc: qcom: Add msm8996 specific changes in mss rproc driver.
On 2/28/2017 4:18 AM, Stephen Boyd wrote:
On 01/30, Avaneesh Kumar Dwivedi wrote:
diff --git a/drivers/remoteproc/qcom_q6v5_pil.c
b/drivers/remoteproc/qcom_q6v5_pil.c
index 35eee68..9c12a36 100644
--- a/drivers/remoteproc/qcom_q6v5_pil.c
+++ b/drivers/remoteproc/qcom_q6v5_pil.c
@@ -485,35 +497,99 @@ static int q6v5_rmb_mba_wait(struct q6v5 *qproc, u32
status, int ms)
static int q6v5proc_reset(struct q6v5 *qproc)
{
- u32 val;
+ u64 val;
Why u64? There isn't any readq/writeq usage here.
OK
int ret;
+ int i;
[...]
+ if (qproc->version == MSS_MSM8996) {
+ /* Override the ACC value if required */
+ writel(QDSP6SS_ACC_OVERRIDE_VAL,
+ qproc->reg_base + QDSP6SS_STRAP_ACC);
+
+ /* Assert resets, stop core */
+ val = readl(qproc->reg_base + QDSP6SS_RESET_REG);
+ val |= (Q6SS_CORE_ARES | Q6SS_BUS_ARES_ENABLE | Q6SS_STOP_CORE);
Useless parenthesis.
ok
+ writel(val, qproc->reg_base + QDSP6SS_RESET_REG);
+
+ /* BHS require xo cbcr to be enabled */
+ val = readl(qproc->reg_base + QDSP6SS_XO_CBCR);
+ val |= 0x1;
+ writel(val, qproc->reg_base + QDSP6SS_XO_CBCR);
+ /* Read CLKOFF bit to go low indicating CLK is enabled */
+ ret = readl_poll_timeout(qproc->reg_base + QDSP6SS_XO_CBCR,
+ val, !(val & BIT(31)), 1, HALT_CHECK_MAX_LOOPS);
+ if (ret) {
+ dev_err(qproc->dev,
+ "xo cbcr enabling timed out (rc:%d)\n", ret);
+ return ret;
+ }
+ /* Enable power block headswitch and wait for it to stabilize */
+ val = readl(qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+ val |= QDSP6v56_BHS_ON;
+ writel(val, qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+ val |= readl(qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+ udelay(1);
+
+ /* Put LDO in bypass mode */
+ val |= QDSP6v56_LDO_BYP;
+ writel(val, qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+
+ /* Deassert QDSP6 compiler memory clamp */
+ val = readl(qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+ val &= ~QDSP6v56_CLAMP_QMC_MEM;
+ writel(val, qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+
+ /* Deassert memory peripheral sleep and L2 memory standby */
+ val |= (Q6SS_L2DATA_STBY_N | Q6SS_SLP_RET_N);
Useless parenthesis.
ok
+ writel(val, qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+
+ /* Turn on L1, L2, ETB and JU memories 1 at a time */
+ val = readl(qproc->reg_base + QDSP6SS_MEM_PWR_CTL);
+ for (i = 19; i >= 0; i--) {
+ val |= BIT(i);
+ writel(val, qproc->reg_base +
+ QDSP6SS_MEM_PWR_CTL);
+ /*
+* Read back value to ensure the write is done then
+* wait for 1us for both memory peripheral and data
+* array to turn on.
+*/
+ val |= readl(qproc->reg_base + QDSP6SS_MEM_PWR_CTL);
+ udelay(1);
+ }
+ /* Remove word line clamp */
+ val = readl(qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+ val &= ~QDSP6v56_CLAMP_WL;
+ writel(val, qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+ } else {
+ /* Assert resets, stop core */
+ val = readl(qproc->reg_base + QDSP6SS_RESET_REG);
+ val |= (Q6SS_CORE_ARES | Q6SS_BUS_ARES_ENABLE | Q6SS_STOP_CORE);
Useless parenthesis.
ok
+ writel(val, qproc->reg_base + QDSP6SS_RESET_REG);
+
+ /* Enable power block headswitch and wait for it to stabilize */
+ val = readl(qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+ val |= QDSS_BHS_ON | QDSS_LDO_BYP;
+ writel(val, qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+ val |= readl(qproc->reg_base + QDSP6SS_PWR_CTL_REG);
+ udelay(1);
@@ -849,6 +925,7 @@ static int q6v5_stop(struct rproc *rproc)
{
struct q6v5 *qproc = (struct q6v5 *)rproc->priv;
int ret;
+ int val;
u32 instead of int?
ok
qproc->running = false;
@@ -866,6 +943,15 @@ static int q6v5_stop(struct rproc *rproc)
q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_modem);
q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_nc);
+ if (qproc->version == MSS_MSM8996) {
+ /*
+* To avoid high MX current during LPASS/MSS restart.
+*/
Three lines could be one line comment instead.
ok.
+ val = readl(qproc->
Re: [PATCH net] rxrpc: Fix potential NULL-pointer exception
From: David Howells
Date: Thu, 02 Mar 2017 23:26:13 +
> Fix a potential NULL-pointer exception in rxrpc_do_sendmsg(). The call
> state check that I added should have gone into the else-body of the
> if-statement where we actually have a call to check.
>
> Found by CoverityScan CID#1414316 ("Dereference after null check").
>
> Fixes: 540b1c48c37a ("rxrpc: Fix deadlock between call creation and
> sendmsg/recvmsg")
> Reported-by: Colin Ian King
> Signed-off-by: David Howells
Applied.
hi
Greetings to you, My name is Avriel Harry, a sergeant of UNITED STATE ARMY, I hope this email will find you well & healthy and I hope we can establish a relationship since we are meeting here for the first time,i have gone through a profile that speaks good of you in this site and I was impressed when i saw your profile and i decided to communicate with you. It is my desire to know you too, and I like honesty, trust, love, caring, truth, & respect, I have all this qualities in me, kindly respond to me through my private email boxso that we can know ourselves better. I hope to read from you if you are interested. Thanks and hoping to hear from you soonest. Lots Of Love, Avriel Harry
RE: [PATCH v2 1/1] serial: 8250_dw: Allow hardware flow control to be used
James,
Can you verify that changing the code to the following fixes your problem?
if (IS_ERR_OR_NULL(d->clk) || !old)
goto out;
Regards,
Jason
-Original Message-
From: Ray Jui [mailto:ray@broadcom.com]
Sent: March-03-17 9:34 AM
To: Andy Shevchenko ; James Hogan
; Heiko Stuebner
Cc: Jason Uy ; Greg Kroah-Hartman
; Jiri Slaby ; Kefeng Wang
; Noam Camus ; Heikki Krogerus
; Wang Hongcheng ;
linux-ser...@vger.kernel.org; LKML ;
bcm-kernel-feedback-l...@broadcom.com; Linux MIPS Mailing List
; David Daney ; Russell
King ; linux-...@vger.kernel.org; Viresh Kumar
Subject: Re: [PATCH v2 1/1] serial: 8250_dw: Allow hardware flow control to
be used
Hi Andy/Jason,
On 3/3/2017 5:31 AM, Andy Shevchenko wrote:
> Heiko, you might be interested in this as well.
>
> On Fri, 2017-03-03 at 00:21 +, James Hogan wrote:
>> On Wed, Mar 01, 2017 at 08:50:20PM +0200, Andy Shevchenko wrote:
>>> On Wed, 2017-03-01 at 18:02 +, James Hogan wrote:
On 11 January 2017 at 19:48, Jason Uy
wrote:
> In the most common use case, the Synopsys DW UART driver does not
> set the set_termios callback function. This prevents
> UPSTAT_AUTOCTS from being set when the UART flag CRTSCTS is set.
> As a result, the driver will use software flow control as opposed
> to hardware flow control.
>
> To fix the problem, the set_termios callback function is set to
> the DW specific function. The logic to set UPSTAT_AUTOCTS is
> moved so that any clock error will not affect setting the hardware
> flow control.
Bisection shows that this patch, commit
6a171b29937984a5e0bf29d6577b055998f03edb, has broken boot of the
Cavium Octeon III based UTM-8 board (MIPS architecture).
I now get the following warning:
[] uart_get_baud_rate+0xfc/0x1f0
[] serial8250_do_set_termios+0xb0/0x440
[] uart_set_options+0xe8/0x190
[] serial8250_console_setup+0x84/0x158
[] univ8250_console_setup+0x54/0x70
[] register_console+0x1c8/0x418
[] uart_add_one_port+0x434/0x4b0
[] serial8250_register_8250_port+0x2d8/0x440
[] dw8250_probe+0x388/0x5e8 Then it hangs and the
watchdog restarts the machine.
Any ideas?
>>>
>>> 1. Does it use clock on that platform?
>
>> I've now dug a little deeper. Essentially what is going on is:
>>
>> 1) CONFIG_HAVE_CLK=n (Octeon doesn't select it)
>> 2) The CONFIG_HAVE_CLK=n implementation of devm_clk_get() returns
>> NULL
>> 3) The "if (IS_ERR(d->clk) || !old) {" check in dw8250_set_termios()
>>doesn't match, since !IS_ERR(NULL)
>> 4) The CONFIG_HAVE_CLK=n implementation of clk_round_rate() returns 0
>> 5) The CONFIG_HAVE_CLK=n implementation of clk_set_rate(d->clk, 0)
>>returns 0
>> 6) dw8250_set_termios() thinks the frequency for that baud rate has
>> been
>>set successfully and writes 0 into uartclk
>> 7) it all goes wrong from there...
>
> So, it means we have need special care of NULL case here, and
> honestly, I don't like it. But it seems the only feasible (quick) fix
> right now.
I agree. I think it should have been:
if (IS_ERR_OR_NULL(d->clk) || !old)
goto out;
I think it makes sense to validate to make sure the 'clk' pointer is valid
before proceeding any further down below (regardless of how well or how not
well the clock framework handles it).
Thanks,
Ray
>
>> The CONFIG_HAVE_CLK=n implementation of devm_clk_get() in particular
>> seems highly questionable to me, given that commit 93abe8e4b13a ("clk:
>> add non CONFIG_HAVE_CLK routines") which added it 5 years ago says:
>>
>>> These calls will return error for platforms that don't select
>>> HAVE_CLK
>>
>> And NULL isn't an error in this API.
>
> Which is okay. I dunno what should be returned from clk_round_rate()
> if clk is NULL. I would fix CLK framework, though I would like to
> gather more details.
>
> Btw, I hope you also noticed this one:
>
> http://www.spinics.net/lists/linux-serial/msg25314.html
>
Re: [PATCH] drm/arcpgu: use .mode_fixup instead of .atomic_check
Hi Alexey,
On 03-03-2017 13:27, Alexey Brodkin wrote:
>
> So if I understood you correct here what I really need is just to get rid of
> existing check,
> right? I.e. the following is to be in v2 respin:
> --->8---
> diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
> b/drivers/gpu/drm/arc/arcpgu_crtc.c
> index ad9a95916f1f..86f1555914e8 100644
> --- a/drivers/gpu/drm/arc/arcpgu_crtc.c
> +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
> @@ -129,20 +129,6 @@ static void arc_pgu_crtc_disable(struct drm_crtc *crtc)
> ~ARCPGU_CTRL_ENABLE_MASK);
> }
>
> -static int arc_pgu_crtc_atomic_check(struct drm_crtc *crtc,
> -struct drm_crtc_state *state)
> -{
> - struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
> - struct drm_display_mode *mode = &state->adjusted_mode;
> - long rate, clk_rate = mode->clock * 1000;
> -
> - rate = clk_round_rate(arcpgu->clk, clk_rate);
> - if (rate != clk_rate)
> - return -EINVAL;
> -
> - return 0;
> -}
> -
> static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
> struct drm_crtc_state *state)
> {
> @@ -165,7 +151,6 @@ static const struct drm_crtc_helper_funcs
> arc_pgu_crtc_helper_funcs = {
> .disable= arc_pgu_crtc_disable,
> .prepare= arc_pgu_crtc_disable,
> .commit = arc_pgu_crtc_enable,
> - .atomic_check = arc_pgu_crtc_atomic_check,
> .atomic_begin = arc_pgu_crtc_atomic_begin,
> };
> --->8---
I don't think you can remove the check entirely as this will make
any mode be accepted, right?
Best regards,
Jose Miguel Abreu
Re: [PATCH] selinux: check for address length in selinux_socket_bind()
On Fri, Mar 3, 2017 at 9:23 AM, Alexander Potapenko wrote:
> This happens because bind() unconditionally copies |size| bytes of
> |addr| to the kernel, leaving the rest uninitialized. Then
> security_socket_bind() reads the IP address bytes, including the
> uninitialized ones, to determine the port, or e.g. pass them further to
> sel_netnode_find(), which uses them to calculate a hash.
>
> Signed-off-by: Alexander Potapenko
> ---
> security/selinux/hooks.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 0a4b4b040e0a..eba54489b11b 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -4351,10 +4351,19 @@ static int selinux_socket_bind(struct socket *sock,
> struct sockaddr *address, in
> u32 sid, node_perm;
>
> if (family == PF_INET) {
> + if (addrlen != sizeof(struct sockaddr_in)) {
Please take a look at inet_bind()
The correct test would be :
if (addrlen < sizeof(struct sockaddr_in))
err = -EINVAL;
...
> + err = -EINVAL;
> + goto out;
> + }
> addr4 = (struct sockaddr_in *)address;
> snum = ntohs(addr4->sin_port);
> addrp = (char *)&addr4->sin_addr.s_addr;
> +
> } else {
> + if (addrlen != sizeof(struct sockaddr_in6)) {
Look at inet6_bind()
if (addrlen < SIN6_LEN_RFC2133)
> + err = -EINVAL;
> + goto out;
> + }
> addr6 = (struct sockaddr_in6 *)address;
> snum = ntohs(addr6->sin6_port);
> addrp = (char *)&addr6->sin6_addr.s6_addr;
> --
> 2.12.0.rc1.440.g5b76565f74-goog
>
[PATCH v4 2/5] staging: lustre: Remove unnecessary cast on void pointer
The following Coccinelle script was used to detect this:
@r@
expression x;
void* e;
type T;
identifier f;
@@
(
*((T *)e)
|
((T *)x)[...]
|
((T*)x)->f
|
- (T*)
e
)
Signed-off-by: simran singhal
---
drivers/staging/lustre/lustre/lmv/lmv_obd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lustre/lmv/lmv_obd.c
b/drivers/staging/lustre/lustre/lmv/lmv_obd.c
index 271e189..09b46924 100644
--- a/drivers/staging/lustre/lustre/lmv/lmv_obd.c
+++ b/drivers/staging/lustre/lustre/lmv/lmv_obd.c
@@ -640,7 +640,7 @@ static int lmv_fid2path(struct obd_export *exp, int len,
void *karg,
int remote_gf_size = 0;
int rc;
- gf = (struct getinfo_fid2path *)karg;
+ gf = karg;
tgt = lmv_find_target(lmv, &gf->gf_fid);
if (IS_ERR(tgt))
return PTR_ERR(tgt);
@@ -657,7 +657,7 @@ static int lmv_fid2path(struct obd_export *exp, int len,
void *karg,
struct getinfo_fid2path *ori_gf;
char *ptr;
- ori_gf = (struct getinfo_fid2path *)karg;
+ ori_gf = karg;
if (strlen(ori_gf->gf_path) +
strlen(gf->gf_path) > ori_gf->gf_pathlen) {
rc = -EOVERFLOW;
--
2.7.4
[PATCH v4 4/5] staging: rts5208: Remove unnecessary cast on void pointer
The following Coccinelle script was used to detect this:
@r@
expression x;
void* e;
type T;
identifier f;
@@
(
*((T *)e)
|
((T *)x)[...]
|
((T*)x)->f
|
- (T*)
e
)
Signed-off-by: simran singhal
---
drivers/staging/rts5208/rtsx_transport.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx_transport.c
b/drivers/staging/rts5208/rtsx_transport.c
index 2379901..8b57e17 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -766,8 +766,7 @@ int rtsx_transfer_data(struct rtsx_chip *chip, u8 card,
void *buf, size_t len,
return -EIO;
if (use_sg) {
- err = rtsx_transfer_sglist_adma(chip, card,
- (struct scatterlist *)buf,
+ err = rtsx_transfer_sglist_adma(chip, card, buf,
use_sg, dma_dir, timeout);
} else {
err = rtsx_transfer_buf(chip, card, buf, len, dma_dir, timeout);
--
2.7.4
[PATCH v4 5/5] staging: rtl8712: Remove unnecessary cast on void pointer
The following Coccinelle script was used to detect this:
@r@
expression x;
void* e;
type T;
identifier f;
@@
(
*((T *)e)
|
((T *)x)[...]
|
((T*)x)->f
|
- (T*)
e
)
Signed-off-by: simran singhal
---
drivers/staging/rtl8712/rtl8712_recv.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl8712_recv.c
b/drivers/staging/rtl8712/rtl8712_recv.c
index 20fe45a..266ffef 100644
--- a/drivers/staging/rtl8712/rtl8712_recv.c
+++ b/drivers/staging/rtl8712/rtl8712_recv.c
@@ -444,9 +444,9 @@ void r8712_rxcmd_event_hdl(struct _adapter *padapter, void
*prxcmdbuf)
u16 cmd_len, drvinfo_sz;
struct recv_stat *prxstat;
- poffset = (u8 *)prxcmdbuf;
+ poffset = prxcmdbuf;
voffset = *(__le32 *)poffset;
- prxstat = (struct recv_stat *)prxcmdbuf;
+ prxstat = prxcmdbuf;
drvinfo_sz = (le32_to_cpu(prxstat->rxdw0) & 0x000f) >> 16;
drvinfo_sz <<= 3;
poffset += RXDESC_SIZE + drvinfo_sz;
@@ -634,8 +634,7 @@ static int recv_indicatepkt_reorder(struct _adapter
*padapter,
void r8712_reordering_ctrl_timeout_handler(void *pcontext)
{
unsigned long irql;
- struct recv_reorder_ctrl *preorder_ctrl =
-(struct recv_reorder_ctrl *)pcontext;
+ struct recv_reorder_ctrl *preorder_ctrl = pcontext;
struct _adapter *padapter = preorder_ctrl->padapter;
struct __queue *ppending_recvframe_queue =
&preorder_ctrl->pending_recvframe_queue;
@@ -976,7 +975,7 @@ int recv_func(struct _adapter *padapter, void *pcontext)
struct __queue *pfree_recv_queue = &padapter->recvpriv.free_recv_queue;
struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
- prframe = (union recv_frame *)pcontext;
+ prframe = pcontext;
orig_prframe = prframe;
pattrib = &prframe->u.hdr.attrib;
if (check_fwstate(pmlmepriv, WIFI_MP_STATE)) {
@@ -1124,7 +1123,7 @@ static int recvbuf2recvframe(struct _adapter *padapter,
struct sk_buff *pskb)
static void recv_tasklet(void *priv)
{
struct sk_buff *pskb;
- struct _adapter *padapter = (struct _adapter *)priv;
+ struct _adapter *padapter = priv;
struct recv_priv *precvpriv = &padapter->recvpriv;
while (NULL != (pskb = skb_dequeue(&precvpriv->rx_skb_queue))) {
--
2.7.4
Re: [PATCH 1/4] net: thunderx: Fix IOMMU translation faults
From: sunil.kovv...@gmail.com Date: Fri, 3 Mar 2017 16:17:47 +0530 > @@ -1643,6 +1650,9 @@ static int nicvf_probe(struct pci_dev *pdev, const > struct pci_device_id *ent) > if (!pass1_silicon(nic->pdev)) > nic->hw_tso = true; > > + /* Check if we are attached to IOMMU */ > + nic->iommu_domain = iommu_get_domain_for_dev(dev); This function is not universally available. This looks very hackish to me anyways, how all of this stuff is supposed to work is that you simply use the DMA interfaces unconditionally and whatever is behind the operations takes care of everything. Doing it conditionally in the driver with all of this special IOMMU domain et al. knowledge makes no sense to me at all. I don't see other drivers doing stuff like this at all, so if you're going to handle this in a unique way like this you better write several paragraphs in your commit message explaining why this weird crap is necessary. There is no way I can apply this series as it is current written. Thanks.
[PATCH v4 3/5] staging: lustre: lustre: Remove unnecessary cast on void pointer
The following Coccinelle script was used to detect this:
@r@
expression x;
void* e;
type T;
identifier f;
@@
(
*((T *)e)
|
((T *)x)[...]
|
((T*)x)->f
|
- (T*)
e
)
Signed-off-by: simran singhal
---
drivers/staging/lustre/lustre/llite/range_lock.c | 2 +-
drivers/staging/lustre/lustre/mgc/mgc_request.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lustre/llite/range_lock.c
b/drivers/staging/lustre/lustre/llite/range_lock.c
index 14148a0..161391b 100644
--- a/drivers/staging/lustre/lustre/llite/range_lock.c
+++ b/drivers/staging/lustre/lustre/llite/range_lock.c
@@ -174,7 +174,7 @@ void range_unlock(struct range_lock_tree *tree, struct
range_lock *lock)
*/
static enum interval_iter range_lock_cb(struct interval_node *node, void *arg)
{
- struct range_lock *lock = (struct range_lock *)arg;
+ struct range_lock *lock = arg;
struct range_lock *overlap = node2rangelock(node);
lock->rl_blocking_ranges += overlap->rl_lock_count + 1;
diff --git a/drivers/staging/lustre/lustre/mgc/mgc_request.c
b/drivers/staging/lustre/lustre/mgc/mgc_request.c
index 6a76605..8ca0a04 100644
--- a/drivers/staging/lustre/lustre/mgc/mgc_request.c
+++ b/drivers/staging/lustre/lustre/mgc/mgc_request.c
@@ -1050,7 +1050,7 @@ static int mgc_set_info_async(const struct lu_env *env,
struct obd_export *exp,
sptlrpc_flavor2name(&cli->cl_flvr_mgc,
str, sizeof(str));
LCONSOLE_ERROR("asking sptlrpc flavor %s to MGS but
currently %s is in use\n",
- (char *)val, str);
+ val, str);
rc = -EPERM;
}
return rc;
--
2.7.4
Re: [PATCH] drm/arcpgu: Get rid of "encoder-slave" property
Hi Liviu,
On Fri, 2017-03-03 at 16:28 +, Liviu Dudau wrote:
> On Fri, Mar 03, 2017 at 06:19:24PM +0300, Alexey Brodkin wrote:
> >
> > - /* find the encoder node and initialize it */
> > - encoder_node = of_parse_phandle(drm->dev->of_node, "encoder-slave", 0);
> > - if (encoder_node) {
> > - ret = arcpgu_drm_hdmi_init(drm, encoder_node);
> > - of_node_put(encoder_node);
> > + /* There is only one output port inside each device, find it */
> > + port = of_graph_get_next_endpoint(pdev->dev.of_node, NULL);
> > +
> > + if (port) {
> > + if (of_device_is_available(port))
> > + encoder = of_graph_get_remote_port_parent(port);
> > + of_node_put(port);
> > + }
>
> You must've been looking at some old version. Current version in -next uses
> of_graph_get_remote_node() to replace all those lines you have added (see Rob
> Herring's series to introduce of_graph_get_remote_node() function)
Hm, I'm not on Linus' master tree [1] and so I thought I was quite up to date :)
Still I made a check of linux-next and don't see any changes in
"drivers/gpu/drm/arm" compared to Linus' tree.
[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/arm?id=e4563f6ba71792c77aeccb2092cc23149b44e642
[2]
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/arm?id=e4563f6ba71792c77aeccb2092cc23149b44e642
Could you please clarify which exact tree did you mean?
Anyways I just tried to rebase my patch on top of linux-next tree and now
video output is broken for me - I only see some garbage on top of the screen
so I'll need to investigate it first before moving forward with stuff you
proposed :)
-Alexey
[PATCH v4 0/5] Remove unnecessary cast on void pointer
This patch-series removes unnecessary cast on void pointer in various drivers. v4: -change the cover-letter subject v3: -Fixed compilation warning in lustre/lustre/llite/range_lock.c simran singhal (5): staging: nvec: Remove unnecessary cast on void pointer staging: lustre: Remove unnecessary cast on void pointer staging: lustre: lustre: Remove unnecessary cast on void pointer staging: rts5208: Remove unnecessary cast on void pointer staging: rtl8712: Remove unnecessary cast on void pointer drivers/staging/lustre/lustre/llite/range_lock.c | 2 +- drivers/staging/lustre/lustre/lmv/lmv_obd.c | 4 ++-- drivers/staging/lustre/lustre/mgc/mgc_request.c | 2 +- drivers/staging/nvec/nvec_kbd.c | 2 +- drivers/staging/rtl8712/rtl8712_recv.c | 11 +-- drivers/staging/rts5208/rtsx_transport.c | 3 +-- 6 files changed, 11 insertions(+), 13 deletions(-) -- 2.7.4
Re: [Outreachy kernel] [PATCH] staging: speakup: else is not generally useful after a break or return
On Fri, Mar 03, 2017 at 05:03:09PM +0100, Julia Lawall wrote: > > > On Fri, 3 Mar 2017, Arushi Singhal wrote: > > > fixed checkpatch.pl warning: else is not generally useful after a break > > or return. > > Removed the else without affecting the logic. > > Dead code is also eliminated. > > The chhange is not correct. There is a big chain of if/else if. The if > (type == KT_LATIN) can reach the code at the end of the file. > Yeah. And KT_CUR as well. regards, dan carpenter
Re: [PATCH 1/7] staging: media: Remove unnecessary typecast of c90 int constant
Hi Simran, On Fri, Mar 03, 2017 at 01:21:56AM +0530, simran singhal wrote: > This patch removes unnecessary typecast of c90 int constant. > > WARNING: Unnecessary typecast of c90 int constant > > Signed-off-by: simran singhal Which tree are these patches based on? -- Regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
Re: [PATCH net v5 0/2] net: ethernet: bgmac: bug fixes
From: Jon Mason Date: Thu, 2 Mar 2017 17:59:55 -0500 > Bug fixes for bgmac driver Series applied.
Re: [PATCH v9 00/10] mux controller abstraction and iio/i2c muxes
On 3 March 2017 16:52:47 GMT+00:00, Wolfram Sang wrote: > >> Jonathan, Wolfram, do you have any preferences on how this should be >> coordinated regarding the new iio and i2c drivers (and iio changes)? > >You got the acks, all is fine, I think. > >> My plan is to at some point declare the branch immutable. Then both >of >> you can pull it in. Or? > >Yup, sounds good. > >> But now that I think about it I wonder what the point is of having >> Greg pull it in also? Sure, third time's a charm and all that, but... > >AFAIU, Greg will be your "upstream", so he should definately pull the >branch. I will just pull it in to avoid merge conflicts in my tree. >Or did I misunderstand your question? Agreed, will do the same if needed. Btw Greg is a very nice upstream to have! Jonathan -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging
On 03/03/2017 05:29 AM, Michal Hocko wrote: > On Thu 02-03-17 13:44:32, Laura Abbott wrote: >> Hi, >> >> There's been some recent discussions[1] about Ion-like frameworks. There's >> apparently interest in just keeping Ion since it works reasonablly well. >> This series does what should be the final clean ups for it to possibly be >> moved out of staging. >> >> This includes the following: >> - Some general clean up and removal of features that never got a lot of use >> as far as I can tell. >> - Fixing up the caching. This is the series I proposed back in December[2] >> but never heard any feedback on. It will certainly break existing >> applications that rely on the implicit caching. I'd rather make an effort >> to move to a model that isn't going directly against the establishement >> though. >> - Fixing up the platform support. The devicetree approach was never well >> recieved by DT maintainers. The proposal here is to think of Ion less as >> specifying requirements and more of a framework for exposing memory to >> userspace. >> - CMA allocations now happen without the need of a dummy device structure. >> This fixes a bunch of the reasons why I attempted to add devicetree >> support before. >> >> I've had problems getting feedback in the past so if I don't hear any major >> objections I'm going to send out with the RFC dropped to be picked up. >> The only reason there isn't a patch to come out of staging is to discuss any >> other changes to the ABI people might want. Once this comes out of staging, >> I really don't want to mess with the ABI. > > Could you recapitulate concerns preventing the code being merged > normally rather than through the staging tree and how they were > addressed? > Sorry, I'm really not understanding your question here, can you clarify? Thanks, Laura
Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks
On Fri, 3 Mar 2017 09:27:23 +0100
Michal Hocko wrote:
> On Thu 02-03-17 18:03:15, Igor Mammedov wrote:
> > On Thu, 2 Mar 2017 15:28:16 +0100
> > Michal Hocko wrote:
> >
> > > On Thu 02-03-17 14:53:48, Igor Mammedov wrote:
> > > [...]
> > > > When trying to support memory unplug on guest side in RHEL7,
> > > > experience shows otherwise. Simplistic udev rule which onlines
> > > > added block doesn't work in case one wants to online it as movable.
> > > >
> > > > Hotplugged blocks in current kernel should be onlined in reverse
> > > > order to online blocks as movable depending on adjacent blocks zone.
> > >
> > > Could you be more specific please? Setting online_movable from the udev
> > > rule should just work regardless of the ordering or the state of other
> > > memblocks. If that doesn't work I would call it a bug.
> > It's rather an implementation constrain than a bug
> > for details and workaround patch see
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1314306#c7
>
> "You are not authorized to access bug #1314306"
Sorry,
I've made it public, related comments and patch should be accessible now
(code snippets in BZ are based on older kernel but logic is still the same
upstream)
> could you paste the reasoning here please?
sure here is reproducer:
start VM with CLI:
qemu-system-x86_64 -enable-kvm -m size=1G,slots=2,maxmem=4G -numa node \
-object memory-backend-ram,id=m1,size=1G -device pc-dimm,node=0,memdev=m1 \
/path/to/guest_image
then in guest dimm1 blocks are from 32-39
echo online_movable > /sys/devices/system/memory/memory32/state
-bash: echo: write error: Invalid argument
in current mainline kernel it triggers following code path:
online_pages()
...
if (online_type == MMOP_ONLINE_KERNEL) {
if (!zone_can_shift(pfn, nr_pages, ZONE_NORMAL, &zone_shift))
return -EINVAL;
zone_can_shift()
...
if (idx < target) {
/* pages must be at end of current zone */
if (pfn + nr_pages != zone_end_pfn(zone))
return false;
since we are trying to online as movable not the last section in
ZONE_NORMAL.
Here is what makes hotplugged memory end up in ZONE_NORMAL:
acpi_memory_enable_device() -> add_memory -> add_memory_resource ->
-> arch/x86/mm/init_64.c
/*
* Memory is added always to NORMAL zone. This means you will never get
* additional DMA/DMA32 memory.
*/
int arch_add_memory(int nid, u64 start, u64 size, bool for_device)
{
...
struct zone *zone = pgdat->node_zones +
zone_for_memory(nid, start, size, ZONE_NORMAL, for_device);
i.e. all hot-plugged memory modules always go to ZONE_NORMAL
and only the first/last block in zone is allowed to be moved
to another zone. Patch [1] tries to fix issue by assigning
removable memory resource to movable zone so hotplugged+removable
blocks look like:
movable normal, movable, movable
instead of current:
normal, normal, normal movable
but then with this fixed as suggested, auto online by default
should work just fine in kernel with normal and movable zones
without any need for user-space.
> > patch attached there is limited by another memory hotplug
> > issue, which is NORMAL/MOVABLE zone balance, if kernel runs
> > on configuration where the most of memory is hot-removable
> > kernel might experience lack of memory in zone NORMAL.
>
> yes and that is an inherent problem of movable memory.
>
> > > > Which means simple udev rule isn't usable since it gets event from
> > > > the first to the last hotplugged block order. So now we would have
> > > > to write a daemon that would
> > > > - watch for all blocks in hotplugged memory appear (how would it know)
> > > > - online them in right order (order might also be different depending
> > > >on kernel version)
> > > >-- it becomes even more complicated in NUMA case when there are
> > > > multiple zones and kernel would have to provide user-space
> > > > with information about zone maps
> > > >
> > > > In short current experience shows that userspace approach
> > > > - doesn't solve issues that Vitaly has been fixing (i.e. onlining
> > > >fast and/or under memory pressure) when udev (or something else
> > > >might be killed)
> > >
> > > yeah and that is why the patch does the onlining from the kernel.
> > onlining in this patch is limited to hyperv and patch breaks
> > auto-online on x86 kvm/vmware/baremetal as they reuse the same
> > hotplug path.
>
> Those can use the udev or do you see any reason why they couldn't?
Reasons are above, under and >> quotations, patch breaks
what Vitaly's fixed (including kvm/vmware usecases) i.e. udev/some
user-space process could be killed if hotplugged memory isn't o
net: heap out-of-bounds in fib6_clean_node/rt6_fill_node/fib6_age/fib6_prune_clone
Hello, I am getting heap out-of-bounds reports in fib6_clean_node/rt6_fill_node/fib6_age/fib6_prune_clone while running syzkaller fuzzer on 86292b33d4b79ee03e2f43ea0381ef85f077c760. They all follow the same pattern: an object of size 216 is allocated from ip_dst_cache slab, and then accessed at offset 272/276 withing fib6_walk. Looks like type confusion. Unfortunately this is not reproducible. == BUG: KASAN: slab-out-of-bounds in rt6_dump_route+0x293/0x2f0 net/ipv6/route.c:3547 at addr 88004b864514 Read of size 4 by task syz-executor7/25042 CPU: 0 PID: 25042 Comm: syz-executor7 Not tainted 4.10.0+ #234 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:15 [inline] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51 kasan_object_err+0x1c/0x70 mm/kasan/report.c:166 print_address_description mm/kasan/report.c:204 [inline] kasan_report_error mm/kasan/report.c:288 [inline] kasan_report.part.2+0x198/0x440 mm/kasan/report.c:310 kasan_report mm/kasan/report.c:330 [inline] __asan_report_load4_noabort+0x29/0x30 mm/kasan/report.c:330 rt6_dump_route+0x293/0x2f0 net/ipv6/route.c:3547 fib6_dump_node+0x101/0x1a0 net/ipv6/ip6_fib.c:315 fib6_walk_continue+0x4b3/0x620 net/ipv6/ip6_fib.c:1576 fib6_walk+0x1cf/0x300 net/ipv6/ip6_fib.c:1621 fib6_dump_table net/ipv6/ip6_fib.c:374 [inline] inet6_dump_fib+0x832/0xea0 net/ipv6/ip6_fib.c:447 rtnl_dump_all+0x8a/0x2a0 net/core/rtnetlink.c:2776 netlink_dump+0x54d/0xd40 net/netlink/af_netlink.c:2127 __netlink_dump_start+0x4e5/0x760 net/netlink/af_netlink.c:2217 netlink_dump_start include/linux/netlink.h:165 [inline] rtnetlink_rcv_msg+0x4a3/0x860 net/core/rtnetlink.c:4094 netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298 rtnetlink_rcv+0x2a/0x40 net/core/rtnetlink.c:4110 netlink_unicast_kernel net/netlink/af_netlink.c:1231 [inline] netlink_unicast+0x514/0x730 net/netlink/af_netlink.c:1257 netlink_sendmsg+0xa9f/0xe50 net/netlink/af_netlink.c:1803 sock_sendmsg_nosec net/socket.c:633 [inline] sock_sendmsg+0xca/0x110 net/socket.c:643 sock_write_iter+0x326/0x600 net/socket.c:846 new_sync_write fs/read_write.c:499 [inline] __vfs_write+0x483/0x740 fs/read_write.c:512 vfs_write+0x187/0x530 fs/read_write.c:560 SYSC_write fs/read_write.c:607 [inline] SyS_write+0xfb/0x230 fs/read_write.c:599 entry_SYSCALL_64_fastpath+0x1f/0xc2 RIP: 0033:0x4458d9 RSP: 002b:7fe10102bb58 EFLAGS: 0292 ORIG_RAX: 0001 RAX: ffda RBX: 0006 RCX: 004458d9 RDX: 001f RSI: 20691000 RDI: 0006 RBP: 006e2fc0 R08: R09: R10: R11: 0292 R12: 00708000 R13: 209e1ff7 R14: 0001 R15: fffd Object at 88004b864400, in cache ip_dst_cache size: 216 Allocated: PID = 21976 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57 save_stack+0x43/0xd0 mm/kasan/kasan.c:502 set_track mm/kasan/kasan.c:514 [inline] kasan_kmalloc+0xaa/0xd0 mm/kasan/kasan.c:605 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:544 kmem_cache_alloc+0x102/0x680 mm/slab.c:3571 dst_alloc+0x11b/0x1a0 net/core/dst.c:209 rt_dst_alloc+0xf0/0x580 net/ipv4/route.c:1482 __mkroute_output net/ipv4/route.c:2163 [inline] __ip_route_output_key_hash+0xce3/0x2c70 net/ipv4/route.c:2373 __ip_route_output_key include/net/route.h:122 [inline] ip_route_output_flow+0x29/0xa0 net/ipv4/route.c:2459 ip_route_output_key include/net/route.h:132 [inline] sctp_v4_get_dst+0x5d2/0x1570 net/sctp/protocol.c:454 sctp_transport_route+0xa8/0x420 net/sctp/transport.c:292 sctp_assoc_add_peer+0x5a5/0x1470 net/sctp/associola.c:653 sctp_sendmsg+0x1800/0x3970 net/sctp/socket.c:1870 inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:761 sock_sendmsg_nosec net/socket.c:633 [inline] sock_sendmsg+0xca/0x110 net/socket.c:643 ___sys_sendmsg+0x4a3/0x9f0 net/socket.c:1985 __sys_sendmmsg+0x25c/0x750 net/socket.c:2075 SYSC_sendmmsg net/socket.c:2106 [inline] SyS_sendmmsg+0x35/0x60 net/socket.c:2101 entry_SYSCALL_64_fastpath+0x1f/0xc2 Freed: PID = 15058 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57 save_stack+0x43/0xd0 mm/kasan/kasan.c:502 set_track mm/kasan/kasan.c:514 [inline] kasan_slab_free+0x6f/0xb0 mm/kasan/kasan.c:578 __cache_free mm/slab.c:3513 [inline] kmem_cache_free+0x71/0x240 mm/slab.c:3773 dst_destroy+0x1fd/0x330 net/core/dst.c:269 dst_free include/net/dst.h:428 [inline] rt_fibinfo_free_cpus net/ipv4/fib_semantics.c:198 [inline] free_fib_info_rcu+0x399/0x590 net/ipv4/fib_semantics.c:213 __rcu_reclaim kernel/rcu/rcu.h:118 [inline] rcu_do_batch.isra.67+0xa31/0xe50 kernel/rcu/tree.c:2877 invoke_rcu_callbacks kernel/rcu/tree.c:3140 [inline] __rcu_process_callbacks kernel/rcu/tree.c:3107 [inline] rcu_process_callbacks+0x45b/0xc50 kernel/rcu/tree.c:3124 __do_softirq+0x31f/0xbe7 kernel/softirq.c:284 Memory state aro
[PATCH 04/10] Modified indentation
Signed-off-by: Ryan Lee
---
Modified indentation problem.
sound/soc/codecs/max98927.c | 80 ++---
1 file changed, 39 insertions(+), 41 deletions(-)
diff --git a/sound/soc/codecs/max98927.c b/sound/soc/codecs/max98927.c
index 5627279c..efc761b 100755
--- a/sound/soc/codecs/max98927.c
+++ b/sound/soc/codecs/max98927.c
@@ -141,22 +141,21 @@ static struct reg_default max98927_reg[] = {
};
static int max98927_reg_get(struct snd_kcontrol *kcontrol,
- struct snd_ctl_elem_value *ucontrol, unsigned int reg,
- unsigned int mask, unsigned int shift)
+ struct snd_ctl_elem_value *ucontrol, unsigned int reg,
+ unsigned int mask, unsigned int shift)
{
struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
struct max98927_priv *max98927 = snd_soc_codec_get_drvdata(codec);
int data;
regmap_read(max98927->regmap, reg, &data);
- ucontrol->value.integer.value[0] =
- (data & mask) >> shift;
+ ucontrol->value.integer.value[0] = (data & mask) >> shift;
return 0;
}
static int max98927_reg_put(struct snd_kcontrol *kcontrol,
- struct snd_ctl_elem_value *ucontrol, unsigned int reg,
- unsigned int mask, unsigned int shift)
+ struct snd_ctl_elem_value *ucontrol, unsigned int reg,
+ unsigned int mask, unsigned int shift)
{
struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
struct max98927_priv *max98927 = snd_soc_codec_get_drvdata(codec);
@@ -164,18 +163,18 @@ static int max98927_reg_put(struct snd_kcontrol *kcontrol,
regmap_update_bits(max98927->regmap, reg, mask, sel << shift);
dev_dbg(codec->dev, "%s: register 0x%02X, value 0x%02X\n",
- __func__, reg, sel);
+ __func__, reg, sel);
return 0;
}
-static int max98927_dai_set_fmt(struct snd_soc_dai *codec_dai,
- unsigned int fmt)
+static int max98927_dai_set_fmt(struct snd_soc_dai *codec_dai, unsigned int
fmt)
{
struct snd_soc_codec *codec = codec_dai->codec;
struct max98927_priv *max98927 = snd_soc_codec_get_drvdata(codec);
unsigned int invert = 0;
dev_dbg(codec->dev, "%s: fmt 0x%08X\n", __func__, fmt);
+
switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
case SND_SOC_DAIFMT_CBS_CFS:
regmap_update_bits(max98927->regmap,
@@ -218,13 +217,13 @@ static int max98927_dai_set_fmt(struct snd_soc_dai
*codec_dai,
regmap_update_bits(max98927->regmap,
MAX98927_R0020_PCM_MODE_CFG,
max98927->iface, max98927->iface);
- break;
+ break;
case SND_SOC_DAIFMT_LEFT_J:
max98927->iface |= SND_SOC_DAIFMT_LEFT_J;
regmap_update_bits(max98927->regmap,
MAX98927_R0020_PCM_MODE_CFG,
max98927->iface, max98927->iface);
- break;
+ break;
default:
return -EINVAL;
}
@@ -292,8 +291,7 @@ static int max98927_set_clock(struct max98927_priv
*max98927,
default:
return -EINVAL;
}
- regmap_update_bits(max98927->regmap,
- reg, mask, value);
+ regmap_update_bits(max98927->regmap, reg, mask, value);
return 0;
}
@@ -388,7 +386,7 @@ static int max98927_dai_hw_params(struct snd_pcm_substream
*substream,
SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S32_LE)
static int max98927_dai_set_sysclk(struct snd_soc_dai *dai,
- int clk_id, unsigned int freq, int dir)
+ int clk_id, unsigned int freq, int dir)
{
struct snd_soc_codec *codec = dai->codec;
struct max98927_priv *max98927 = snd_soc_codec_get_drvdata(codec);
@@ -458,7 +456,7 @@ static DECLARE_TLV_DB_SCALE(max98927_spk_tlv, 300, 300, 0);
static DECLARE_TLV_DB_SCALE(max98927_digital_tlv, -1600, 25, 0);
static int max98927_spk_gain_get(struct snd_kcontrol *kcontrol,
- struct snd_ctl_elem_value *ucontrol)
+ struct snd_ctl_elem_value *ucontrol)
{
struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
struct max98927_priv *max98927 = snd_soc_codec_get_drvdata(codec);
@@ -470,7 +468,7 @@ static int max98927_spk_gain_get(struct snd_kcontrol
*kcontrol,
}
static int max98927_spk_gain_put(struct snd_kcontrol *kcontrol,
- struct snd_ctl_elem_value *ucontrol)
+ struct snd_ctl_elem_value *ucontrol)
{
struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
struct max98927_priv *max98927 = snd_soc_codec_get_drvdata(codec);
@@ -486,7 +484,7 @@ static int max98927_spk_gain_put(struct snd_kcontrol
*kcontrol,
}
static int max98927_digital_gain_get(struct snd_kcontrol *kcontrol,
- struct snd_ctl_elem_value *ucontrol)
+ struct snd_ct
Re: [PATCH] selinux: check for address length in selinux_socket_bind()
On Fri, Mar 3, 2017 at 6:23 PM, Alexander Potapenko wrote:
> KMSAN (KernelMemorySanitizer, a new error detection tool) reports use of
> uninitialized memory in packet_bind_spkt():
Should be "in selinux_socket_bind()", will fix in the next patch version.
> ==
> BUG: KMSAN: use of unitialized memory
> inter: 0
> CPU: 3 PID: 1074 Comm: packet2 Tainted: GB 4.8.0-rc6+ #1916
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> 8800882ffb08 825759c8 8800882ffa48
> 818bf551 85bab870 0092 85bab550
> 0092 bb0009bb 0002
> Call Trace:
> [< inline >] __dump_stack lib/dump_stack.c:15
> [] dump_stack+0x238/0x290 lib/dump_stack.c:51
> [] kmsan_report+0x276/0x2e0 mm/kmsan/kmsan.c:1008
> [] __msan_warning+0x5b/0xb0 mm/kmsan/kmsan_instr.c:424
> [] selinux_socket_bind+0xf41/0x1080
> security/selinux/hooks.c:4288
> [] security_socket_bind+0x1ec/0x240
> security/security.c:1240
> [] SYSC_bind+0x358/0x5f0 net/socket.c:1366
> [] SyS_bind+0x82/0xa0 net/socket.c:1356
> [] do_syscall_64+0x58/0x70 arch/x86/entry/common.c:292
> [] entry_SYSCALL64_slow_path+0x25/0x25
> arch/x86/entry/entry_64.o:?
> chained origin: ba6009bb
> [] save_stack_trace+0x27/0x50
> arch/x86/kernel/stacktrace.c:67
> [< inline >] kmsan_save_stack_with_flags mm/kmsan/kmsan.c:322
> [< inline >] kmsan_save_stack mm/kmsan/kmsan.c:337
> [] kmsan_internal_chain_origin+0x118/0x1e0
> mm/kmsan/kmsan.c:530
> [] __msan_set_alloca_origin4+0xc3/0x130
> mm/kmsan/kmsan_instr.c:380
> [] SYSC_bind+0x129/0x5f0 net/socket.c:1356
> [] SyS_bind+0x82/0xa0 net/socket.c:1356
> [] do_syscall_64+0x58/0x70 arch/x86/entry/common.c:292
> [] return_from_SYSCALL_64+0x0/0x6a
> arch/x86/entry/entry_64.o:?
> origin description: address@SYSC_bind (origin=b8c00900)
> ==
>
> (the line numbers are relative to 4.8-rc6, but the bug persists upstream)
>
> , when I run the following program as root:
>
> ===
> #include
> #include
> #include
>
> int main(int argc, char *argv[]) {
> struct sockaddr addr;
> int size = 0;
> if (argc > 1) {
> size = atoi(argv[1]);
> }
> memset(&addr, 0, sizeof(addr));
> int fd = socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP);
> bind(fd, &addr, size);
> return 0;
> }
> ===
>
> (for different values of |size| other error reports are printed).
>
> This happens because bind() unconditionally copies |size| bytes of
> |addr| to the kernel, leaving the rest uninitialized. Then
> security_socket_bind() reads the IP address bytes, including the
> uninitialized ones, to determine the port, or e.g. pass them further to
> sel_netnode_find(), which uses them to calculate a hash.
>
> Signed-off-by: Alexander Potapenko
> ---
> security/selinux/hooks.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 0a4b4b040e0a..eba54489b11b 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -4351,10 +4351,19 @@ static int selinux_socket_bind(struct socket *sock,
> struct sockaddr *address, in
> u32 sid, node_perm;
>
> if (family == PF_INET) {
> + if (addrlen != sizeof(struct sockaddr_in)) {
> + err = -EINVAL;
> + goto out;
> + }
> addr4 = (struct sockaddr_in *)address;
> snum = ntohs(addr4->sin_port);
> addrp = (char *)&addr4->sin_addr.s_addr;
> +
> } else {
> + if (addrlen != sizeof(struct sockaddr_in6)) {
> + err = -EINVAL;
> + goto out;
> + }
> addr6 = (struct sockaddr_in6 *)address;
> snum = ntohs(addr6->sin6_port);
> addrp = (char *)&addr6->sin6_addr.s6_addr;
> --
> 2.12.0.rc1.440.g5b76565f74-goog
>
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Re: [PATCH 0/2] fix the traced mt-exec deadlock
On 03/02, Eric W. Biederman wrote:
>
> Oleg Nesterov writes:
>
> > our discussion was a bit confusing, and it seems that we did not
> > fully convince each other. So let me ask what do you finally think
> > about this fix.
> >
> > Let me repeat. Even if I do not agree with some of your objections,
> > I do agree that 1/2 does not look nice and clean. And we seem to
> > agree that either way, with or without this fix, we need more changes
> > in this area.
> >
> > But we need a simple and backportable fix for stable trees, say for
> > rhel7. This bug was reported many times, and this is the simplest
> > solution I was able to find.
>
> I am not 100% convinced that we need a backportable solution,
I think we need, this was already requested,
> but
> regardless my experience is that good clean solutions are almost always
> easier to backport that something we just settle for.
Sure.
> The patch below needs a little more looking and testing but arguably
> it is sufficient.
>
> It implements autoreaping for non-leader threads always. We might want
> to limit this to the case of exec.
I should have mentioned this. Of course, this change was proposed from the
very beginning, when this problem was reported first time. And of course
I like this fix much more than my patch (but yes, we shouldd limit it to
the case of exec).
The only problem is that it is incompatible change, and I have no idea what
can be broken.
Trivial test-case:
void *thread(void *arg)
{
for (;;)
pause();
return NULL;
}
int main(void)
{
pthread_t pt;
pthread_create(&pt, NULL, thread, NULL);
execlp("true", "true", NULL);
}
with your patch applied
$ strace -f ./test
strace: wait4(__WALL): No child processes
Yes, this is just a warning, but still. Now we need to change strace. And we
can't know what else can be confused/broken by this change.
man(ptrace) even documents that all other threads except the thread group leader
report death as if they exited via _exit(2).
Yes, yes, it also says that other threads stop in PTRACE_EVENT_EXIT stop,
so 2/2 (which we need with your change too) is is not compatible too and
I am worried, but:
- this was never really true, an already exiting thread won't stop
if it races with exec
- PTRACE_O_TRACEEXEC is not used that often, it never really worked
- man(ptrace) also mentions that PTRACE_EVENT_EXIT behaviour may be
change in the future.
In short. Of course I considered this change. Looks too risky to me. But.
I will be happy if you send this change and take all the blame ;) I won't
argue (if you limit it to execve case).
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -690,7 +690,9 @@ static void exit_notify(struct task_struct *tsk, int
> group_dead)
> thread_group_empty(tsk) &&
> !ptrace_reparented(tsk) ?
> tsk->exit_signal : SIGCHLD;
> - autoreap = do_notify_parent(tsk, sig);
> + do_notify_parent(tsk, sig);
> + /* Autoreap threads even when ptraced */
> + autoreap = !thread_group_leader(tsk);
> } else if (thread_group_leader(tsk)) {
> autoreap = thread_group_empty(tsk) &&
> do_notify_parent(tsk, tsk->exit_signal);
This is all you need,
> @@ -699,8 +701,6 @@ static void exit_notify(struct task_struct *tsk, int
> group_dead)
> }
>
> tsk->exit_state = autoreap ? EXIT_DEAD : EXIT_ZOMBIE;
> - if (tsk->exit_state == EXIT_DEAD)
> - list_add(&tsk->ptrace_entry, &dead);
>
> /* mt-exec, de_thread() is waiting for group leader */
> if (unlikely(tsk->signal->notify_count < 0))
> @@ -711,6 +711,8 @@ static void exit_notify(struct task_struct *tsk, int
> group_dead)
> list_del_init(&p->ptrace_entry);
> release_task(p);
> }
> + if (autoreap)
> + release_task(tsk);
These 2 changes are not needed. release_task(tsk) will be called by
list_for_each_entry_safe() above if autoreap == T.
Oleg.
Re: [PATCH v2 1/1] serial: 8250_dw: Allow hardware flow control to be used
Hi Andy/Jason,
On 3/3/2017 5:31 AM, Andy Shevchenko wrote:
> Heiko, you might be interested in this as well.
>
> On Fri, 2017-03-03 at 00:21 +, James Hogan wrote:
>> On Wed, Mar 01, 2017 at 08:50:20PM +0200, Andy Shevchenko wrote:
>>> On Wed, 2017-03-01 at 18:02 +, James Hogan wrote:
On 11 January 2017 at 19:48, Jason Uy
wrote:
> In the most common use case, the Synopsys DW UART driver does
> not
> set the set_termios callback function. This prevents
> UPSTAT_AUTOCTS
> from being set when the UART flag CRTSCTS is set. As a result,
> the
> driver will use software flow control as opposed to hardware
> flow
> control.
>
> To fix the problem, the set_termios callback function is set to
> the
> DW specific function. The logic to set UPSTAT_AUTOCTS is moved
> so
> that any clock error will not affect setting the hardware flow
> control.
Bisection shows that this patch, commit
6a171b29937984a5e0bf29d6577b055998f03edb, has broken boot of the
Cavium Octeon III based UTM-8 board (MIPS architecture).
I now get the following warning:
[] uart_get_baud_rate+0xfc/0x1f0
[] serial8250_do_set_termios+0xb0/0x440
[] uart_set_options+0xe8/0x190
[] serial8250_console_setup+0x84/0x158
[] univ8250_console_setup+0x54/0x70
[] register_console+0x1c8/0x418
[] uart_add_one_port+0x434/0x4b0
[] serial8250_register_8250_port+0x2d8/0x440
[] dw8250_probe+0x388/0x5e8
Then it hangs and the watchdog restarts the machine.
Any ideas?
>>>
>>> 1. Does it use clock on that platform?
>
>> I've now dug a little deeper. Essentially what is going on is:
>>
>> 1) CONFIG_HAVE_CLK=n (Octeon doesn't select it)
>> 2) The CONFIG_HAVE_CLK=n implementation of devm_clk_get() returns NULL
>> 3) The "if (IS_ERR(d->clk) || !old) {" check in dw8250_set_termios()
>>doesn't match, since !IS_ERR(NULL)
>> 4) The CONFIG_HAVE_CLK=n implementation of clk_round_rate() returns 0
>> 5) The CONFIG_HAVE_CLK=n implementation of clk_set_rate(d->clk, 0)
>>returns 0
>> 6) dw8250_set_termios() thinks the frequency for that baud rate has
>> been
>>set successfully and writes 0 into uartclk
>> 7) it all goes wrong from there...
>
> So, it means we have need special care of NULL case here, and honestly,
> I don't like it. But it seems the only feasible (quick) fix right now.
I agree. I think it should have been:
if (IS_ERR_OR_NULL(d->clk) || !old)
goto out;
I think it makes sense to validate to make sure the 'clk' pointer is
valid before proceeding any further down below (regardless of how well
or how not well the clock framework handles it).
Thanks,
Ray
>
>> The CONFIG_HAVE_CLK=n implementation of devm_clk_get() in particular
>> seems highly questionable to me, given that commit 93abe8e4b13a ("clk:
>> add non CONFIG_HAVE_CLK routines") which added it 5 years ago says:
>>
>>> These calls will return error for platforms that don't select
>>> HAVE_CLK
>>
>> And NULL isn't an error in this API.
>
> Which is okay. I dunno what should be returned from clk_round_rate() if
> clk is NULL. I would fix CLK framework, though I would like to gather
> more details.
>
> Btw, I hope you also noticed this one:
>
> http://www.spinics.net/lists/linux-serial/msg25314.html
>
[PATCH] selinux: check for address length in selinux_socket_bind()
KMSAN (KernelMemorySanitizer, a new error detection tool) reports use of
uninitialized memory in packet_bind_spkt():
==
BUG: KMSAN: use of unitialized memory
inter: 0
CPU: 3 PID: 1074 Comm: packet2 Tainted: GB 4.8.0-rc6+ #1916
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
8800882ffb08 825759c8 8800882ffa48
818bf551 85bab870 0092 85bab550
0092 bb0009bb 0002
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[] dump_stack+0x238/0x290 lib/dump_stack.c:51
[] kmsan_report+0x276/0x2e0 mm/kmsan/kmsan.c:1008
[] __msan_warning+0x5b/0xb0 mm/kmsan/kmsan_instr.c:424
[] selinux_socket_bind+0xf41/0x1080
security/selinux/hooks.c:4288
[] security_socket_bind+0x1ec/0x240 security/security.c:1240
[] SYSC_bind+0x358/0x5f0 net/socket.c:1366
[] SyS_bind+0x82/0xa0 net/socket.c:1356
[] do_syscall_64+0x58/0x70 arch/x86/entry/common.c:292
[] entry_SYSCALL64_slow_path+0x25/0x25
arch/x86/entry/entry_64.o:?
chained origin: ba6009bb
[] save_stack_trace+0x27/0x50 arch/x86/kernel/stacktrace.c:67
[< inline >] kmsan_save_stack_with_flags mm/kmsan/kmsan.c:322
[< inline >] kmsan_save_stack mm/kmsan/kmsan.c:337
[] kmsan_internal_chain_origin+0x118/0x1e0
mm/kmsan/kmsan.c:530
[] __msan_set_alloca_origin4+0xc3/0x130
mm/kmsan/kmsan_instr.c:380
[] SYSC_bind+0x129/0x5f0 net/socket.c:1356
[] SyS_bind+0x82/0xa0 net/socket.c:1356
[] do_syscall_64+0x58/0x70 arch/x86/entry/common.c:292
[] return_from_SYSCALL_64+0x0/0x6a
arch/x86/entry/entry_64.o:?
origin description: address@SYSC_bind (origin=b8c00900)
==
(the line numbers are relative to 4.8-rc6, but the bug persists upstream)
, when I run the following program as root:
===
#include
#include
#include
int main(int argc, char *argv[]) {
struct sockaddr addr;
int size = 0;
if (argc > 1) {
size = atoi(argv[1]);
}
memset(&addr, 0, sizeof(addr));
int fd = socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP);
bind(fd, &addr, size);
return 0;
}
===
(for different values of |size| other error reports are printed).
This happens because bind() unconditionally copies |size| bytes of
|addr| to the kernel, leaving the rest uninitialized. Then
security_socket_bind() reads the IP address bytes, including the
uninitialized ones, to determine the port, or e.g. pass them further to
sel_netnode_find(), which uses them to calculate a hash.
Signed-off-by: Alexander Potapenko
---
security/selinux/hooks.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 0a4b4b040e0a..eba54489b11b 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -4351,10 +4351,19 @@ static int selinux_socket_bind(struct socket *sock,
struct sockaddr *address, in
u32 sid, node_perm;
if (family == PF_INET) {
+ if (addrlen != sizeof(struct sockaddr_in)) {
+ err = -EINVAL;
+ goto out;
+ }
addr4 = (struct sockaddr_in *)address;
snum = ntohs(addr4->sin_port);
addrp = (char *)&addr4->sin_addr.s_addr;
+
} else {
+ if (addrlen != sizeof(struct sockaddr_in6)) {
+ err = -EINVAL;
+ goto out;
+ }
addr6 = (struct sockaddr_in6 *)address;
snum = ntohs(addr6->sin6_port);
addrp = (char *)&addr6->sin6_addr.s6_addr;
--
2.12.0.rc1.440.g5b76565f74-goog
[PATCH 00/10] ALSA SoC MAX98927 driver - revision
The initial driver had many textual and structural problems. I have added next patches to modify existing problems. There was concern about the design of keeping separate regmaps for each instance of the amplifier explicitly instead of instantiating two instances of a single, simpler driver. This was major change of this release. Coding style problem like indentation also have been fixed. Ryan Lee (10): ALSA SoC MAX98927 driver - Initial release Updated max98927_reg table with physical defaults. Replaced max98927.h for better legibility Removed the secondary device initialization from the primary device initialization. Removed manual register configuration from devicetree Modified indentation Replaced pr_err by dev_err. Modified debug message Added mask variable to apply it in one round after the switch Modified initialization code of VI sensing Added DAI Sel Mux and minor updates Added ACPI support. Changed snd_kcontrol_chip to snd_soc_kcontrol_codec Added vendor prefix. Added range information .../devicetree/bindings/sound/max98927.txt | 39 + sound/soc/codecs/Kconfig |5 + sound/soc/codecs/Makefile |2 + sound/soc/codecs/max98927.c| 1039 sound/soc/codecs/max98927.h| 267 + 5 files changed, 1352 insertions(+) create mode 100755 Documentation/devicetree/bindings/sound/max98927.txt mode change 100644 => 100755 sound/soc/codecs/Kconfig mode change 100644 => 100755 sound/soc/codecs/Makefile create mode 100755 sound/soc/codecs/max98927.c create mode 100755 sound/soc/codecs/max98927.h -- 2.7.4
Hello, i am Lindsey , How's everything with you, I picked interest on you after going through your profile I really want to have a good friendship with you.Beside i have something very vital to tell y
Re: [PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE
On Fri, Mar 03, 2017 at 03:49:38PM +0100, Peter Zijlstra wrote: > On Fri, Mar 03, 2017 at 09:26:50AM +0100, Christian Borntraeger wrote: > > Right. The main purpose is to read/write _ONCE_. You can assume a somewhat > > atomic access for sizes <= word size. And there are certainly places that > > rely on that. But the *ONCE thing is mostly used for things where we used > > barrier() 10 years ago. > > A lot of code relies on READ/WRITE_ONCE() to generate single > instructions for naturally aligned machined word sized loads/stores > (something GCC used to guarantee, but does no longer IIRC). > > So much so that I would say its a bug if READ/WRITE_ONCE() doesn't > generate a single instruction under those conditions. > > However, every time I've tried to introduce stricter > semantics/primitives to verify things Linus hated it. See here for the last attempt: https://marc.info/?l=linux-virtualization&m=148007765918101&w=2
Hallo
Sehr geehrter, Mit Respekt und Menschlichkeit hatte ich die Zwang und dränge tief in mein Herz und Geist, um Ihnen diese E-Mail unter einem humanitären Grund zu schreiben. Mein Name ist Frau Joanna Diane Christopher, und ich bin mit Herrn Bakayoko Christopher Direktor J.C Industries in der Elfenbeinküste verheiratet. Wir waren seit 16 Jahren ohne Kind verheiratet. Mein Mann starb letztes Jahr, nach erfolglosem Herz-Arterien-Betrieb. Und vor kurzem sagte mein Doktor mir, dass ich nicht für die nächsten sechs Monate wegen meines Krebsproblems (Krebs des Hebels und des Schlaganfalls) dauern würde. Bevor mein Mann im vergangenen Jahr gestorben ist, gibt es diese Summe von 4,5 Millionen Euro, die er in einer Bank hier hinterlegt hat. In der Elfenbeinküste. Jetzt ist dieses Geld noch in der Bank. Nachdem ich meinen Zustand gekannt habe, habe ich beschlossen, diesen Fonds für jeden guten Gott zu befürchten, der Bruder oder Schwester befürchtet, der diesen Fonds nutzen wird, wie ich hier anweisen werde. Ich möchte jemanden, der diesen Fonds nach dem Wunsch meines verstorbenen Mannes benutzt, um weniger privilegierten Leuten, Waisenhäusern und Witwen zu helfen und das Wort Gottes zu verbreiten. Ich habe diese Entscheidung getroffen, weil ich kein Kind habe, das diesen Fonds erben wird, und ich will nicht in einer Weise, wo dieses Geld auf ungöttliche Weise verwendet wird. Deshalb gehe ich diese Entscheidung, Ihnen diesen Fonds zu übergeben. Ich habe keine Angst vor dem Tod und ich weiß, wo ich hingehe. Ich möchte, dass du mich immer in deiner täglichen Gebete wegen meiner bevorstehenden Krebs-Chirurgie erinnerst. Schreiben Sie so bald wie möglich eine Verzögerung in Ihrer Antwort wird mir Raum in der Beschaffung einer anderen Person für den gleichen Zweck. Gott segne dich, während du auf die Stimme des Denkens hörst, Ich erwarte von dir zu hören. Dein Frau Joanna Christopher
Re: [PATCH] PM / OPP: Documentation: Fix opp-microvolt in examples
On 03/01/2017 03:09 AM, Viresh Kumar wrote: > The triplet present in "opp-microvolt" property should be in the order > , while all the examples have it in the order > . > > Fix it. > > Luckily all of the users of "opp-microvolt" property have applied brain > instead of copying the examples from documentation and none of the > actual dts files have it wrong. > > Reported-by: Rob Herring > Signed-off-by: Viresh Kumar Reviewed-by: Stephen Boyd Did you want a fixes tag too? Sure it's just documentation. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v5 0/4] iio: accel: adxl345: Split driver into core and I2C then add SPI support
On Thu, Mar 2, 2017 at 9:59 PM, Jonathan Cameron wrote: > On 02/03/17 03:02, Eva Rachel Retuya wrote: >> On Thu, Mar 02, 2017 at 01:22:11AM +0200, Andy Shevchenko wrote: >>> On Tue, Feb 28, 2017 at 4:37 AM, Eva Rachel Retuya >>> wrote: This patchset modifies the adxl345 to use regmap. In doing so, we can easily introduce SPI support and let regmap handle the rest. >> Please state your comments and I will submit a new revision. Just did. > Looks good to me so I'll probably pick this up over the weekend unless you > want > to make a V6 with anything from Andy. Can always send follow up patches later > for any issues highlighted. Yep, feel free incorporate now, or fix later (though I prefer now :-) ) -- With Best Regards, Andy Shevchenko
Re: [PATCH v2 1/2] drm: bridge: dw-hdmi: Take input format from plat_data
Hi Neil, On 03-03-2017 16:42, Neil Armstrong wrote: > > Sure, I was meaning the *input* format the controller receives from the > pixel encoder, I'm quite sure the format is strict. > Hmm, not quite following you here. As far as the controller goes it supports the formats I mentioned: -8/10/12/16 bits RGB 4:4:4 -8/10/12/16 bits YCbCr 4:4:4 -8/10/12 bits YCbCr 4:2:2 -8/10/12/16 bits YCbCr 4:2:0 As for the CSC it supports RGB 4:4:4 to/from YCbCr 4:4:4 or 4:2:2 in every defined color depth. So, everything except 4:2:0 (I had to check documentation, I though that CSC supported less formats). Of course this is all limited by the implementation that HW team decides to choose. Best regards, Jose Miguel Abreu
Re: IMA on NFS deadlocks since a5864c999de670
On Fri, Mar 03, 2017 at 11:38:51AM +0100, Sascha Hauer wrote: > Right now I have no idea if this commit is breaking things or if IMA > is the guilty one and this commit only triggers it. IMA is unfortunately completely broken, and it has the same issue on XFS and OCFS2 for example.
Re: [PATCH v2 1/2] drm: bridge: dw-hdmi: Take input format from plat_data
Hi Neil, On 03-03-2017 11:31, Neil Armstrong wrote: > > Sure, but I was struggling about finding an equivalence. > > How should I replace these ? > > DW_HDMI_ENC_FMT_RGB > DW_HDMI_ENC_FMT_YCBCR444 > DW_HDMI_ENC_FMT_YCBCR422_16BITS > DW_HDMI_ENC_FMT_YCBCR422_8BITS > DW_HDMI_ENC_FMT_XVYCC444 > > I do not have the strict information about the bus format, what is RGB in > 8bit per pixel ? > Are the 3 samples transmitted separately ? > What should be the RGB colorspace ? > Should we use the "Packed" formats, LVDS or a new buf format ? > > Jose, what are the *exact* bus formats supported ? Well, the controller supports everything that is in the HDMI spec (1.4 and 2.0), the implementation is the one that limits the supported formats. There is also a CSC but it does not convert from anything to everything :) I think you can safely add every MBUS code that is compatible with HDMI. Namely: -24/30/36/48-bit RGB 4:4:4 -24/30/36/48-bit YCbCr 4:4:4 -16/20/24-bit YCbCr 4:2:2 -24/30/36/48-bit YCbCr 4:2:0 And then let the glue drivers decide which they support in input and what they want in output (the output is a little tricky because it will depend in EDID, this should be handled by userspace + drm core and not the drivers so let it fixed to RGB, just in case). > > Same for DW_HDMI_ENC_FMT_YCBCR* stuff, are they packed ? Hmm, this depends on the implementation. The controller always receives 48bits of data per pixel, its the implementation that is responsible to correctly align that data. > > I understand the YCBCR444/XVYCC444 needs a color space information instead. > > Could we use the following list ? > > Bus Format| Colorspace| Encoding > --- > MEDIA_BUS_FMT_RGB888_1X24 | V4L2_COLORSPACE_SRGB | V4L2_XFER_FUNC_SRGB > MEDIA_BUS_FMT_RGB101010_1X30 | V4L2_COLORSPACE_SRGB | V4L2_XFER_FUNC_SRGB > MEDIA_BUS_FMT_RGB121212_1X36 | V4L2_COLORSPACE_SRGB | V4L2_XFER_FUNC_SRGB > MEDIA_BUS_FMT_VUY8_1X24 | V4L2_XFER_FUNC_709| > V4L2_YCBCR_ENC_709 > MEDIA_BUS_FMT_YUV10_1X30 | V4L2_XFER_FUNC_709| V4L2_YCBCR_ENC_709 > MEDIA_BUS_FMT_YUV10_1X32 | V4L2_XFER_FUNC_709| V4L2_YCBCR_ENC_709 > MEDIA_BUS_FMT_YUV10_1X32 | V4L2_XFER_FUNC_709| V4L2_YCBCR_ENC_709 > MEDIA_BUS_FMT_YUV10_1X32 | V4L2_XFER_FUNC_709| V4L2_YCBCR_ENC_XV709 I think the HDMI spec dictates the default colorspace+encoding for each bus format, not sure though, Laurent? Best regards, Jose Miguel Abreu > > But all of these is complex, and I'm not sure how we should handle SDTV modes > here, > and without knowing the exact inputs types supported by the IP, this needs to > be > confirmed. > > Meanwhile, all this can be fixed later, at least this patch moves the > definition out of the C file and uses better names for these custom enums. >
[PATCH] ARM: DTS armada: Add support for 2 more mvebu model
This patch add support for 2 Linksys router model
(shelby and rango). With this we now support all
the mvebu board on the market.
Signed-off-by: Imre Kaloz
Signed-off-by: Álvaro Fernández Rojas
Signed-off-by: Ansuel Smith
---
arch/arm/boot/dts/armada-385-linksys-rango.dts | 443
arch/arm/boot/dts/armada-385-linksys-shelby.dts | 115 ++
2 files changed, 558 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-385-linksys-rango.dts
create mode 100644 arch/arm/boot/dts/armada-385-linksys-shelby.dts
diff --git a/arch/arm/boot/dts/armada-385-linksys-rango.dts
b/arch/arm/boot/dts/armada-385-linksys-rango.dts
new file mode 100644
index 000..61f4592
--- /dev/null
+++ b/arch/arm/boot/dts/armada-385-linksys-rango.dts
@@ -0,0 +1,443 @@
+/*
+ * Device Tree file for the Linksys WRT3200ACM (Rango)
+ *
+ * Copyright (C) 2016 Imre Kaloz
+ *
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include
+#include
+#include "armada-385.dtsi"
+
+/ {
+ model = "Linksys WRT3200ACM";
+ compatible = "linksys,rango", "linksys,armada385", "marvell,armada385",
+"marvell,armada380";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x2000>; /* 512 MB */
+ };
+
+ soc {
+ ranges = ;
+
+ internal-regs {
+
+ spi@10600 {
+ status = "disabled";
+ };
+
+ i2c@11000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ status = "okay";
+
+ tmp421@4c {
+ compatible = "ti,tmp421";
+ reg = <0x4c>;
+ };
+
+ pca9635@68 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "nxp,pca9635";
+ reg = <0x68>;
+
+ wan_amber@0 {
+ label = "rango:amber:wan";
+ reg = <0x0>;
+ };
+
+ wan_white@1 {
+ label = "rango:white:wan";
+ reg = <0x1>;
+ };
+
+ usb2@5 {
+ label = "rango:white:usb2";
+ reg = <0x5>;
+ };
+
+ usb3_1@6 {
+ label = "rango:white:usb3_1";
+ reg = <0x6>;
+ };
+
+ usb3_2@7 {
+ label = "rango:white:usb3_2";
+ reg = <0x7>;
+
Re: [PATCH 2/4] thp: fix MADV_DONTNEED vs. numa balancing race
On 03/02/2017 07:10 AM, Kirill A. Shutemov wrote: > @@ -1744,7 +1744,39 @@ int change_huge_pmd(struct vm_area_struct *vma, pmd_t > *pmd, > if (prot_numa && pmd_protnone(*pmd)) > goto unlock; > > - entry = pmdp_huge_get_and_clear_notify(mm, addr, pmd); Are there any remaining call sites for pmdp_huge_get_and_clear_notify() after this?
Re: [Outreachy kernel] [PATCH] staging: media: Remove parentheses from return arguments
On Fri, 3 Mar 2017, simran singhal wrote:
> The sematic patch used for this is:
> @@
> identifier i;
> constant c;
> @@
> return
> - (
> \(i\|-i\|i(...)\|c\)
> - )
> ;
>
> Signed-off-by: simran singhal
Acked-by: Julia Lawall
> ---
> .../media/atomisp/pci/atomisp2/css2400/sh_css.c | 20
> ++--
> .../atomisp/pci/atomisp2/css2400/sh_css_firmware.c | 2 +-
> 2 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
> b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
> index f39d6f5..1216efb 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
> @@ -2009,7 +2009,7 @@ enum ia_css_err ia_css_suspend(void)
> for(i=0;i ia_css_debug_dtrace(IA_CSS_DEBUG_TRACE, "==*> after 1: seed %d
> (%p)\n", i, my_css_save.stream_seeds[i].stream);
> ia_css_debug_dtrace(IA_CSS_DEBUG_TRACE, "ia_css_suspend() leave\n");
> - return(IA_CSS_SUCCESS);
> + return IA_CSS_SUCCESS;
> }
>
> enum ia_css_err
> @@ -2021,10 +2021,10 @@ ia_css_resume(void)
>
> err = ia_css_init(&(my_css_save.driver_env), my_css_save.loaded_fw,
> my_css_save.mmu_base, my_css_save.irq_type);
> if (err != IA_CSS_SUCCESS)
> - return(err);
> + return err;
> err = ia_css_start_sp();
> if (err != IA_CSS_SUCCESS)
> - return(err);
> + return err;
> my_css_save.mode = sh_css_mode_resume;
> for(i=0;i {
> @@ -2038,7 +2038,7 @@ ia_css_resume(void)
> if (i)
> for(j=0;j
> ia_css_stream_unload(my_css_save.stream_seeds[j].stream);
> - return(err);
> + return err;
> }
> err =
> ia_css_stream_start(my_css_save.stream_seeds[i].stream);
> if (err != IA_CSS_SUCCESS)
> @@ -2048,7 +2048,7 @@ ia_css_resume(void)
>
> ia_css_stream_stop(my_css_save.stream_seeds[j].stream);
>
> ia_css_stream_unload(my_css_save.stream_seeds[j].stream);
> }
> - return(err);
> + return err;
> }
> *my_css_save.stream_seeds[i].orig_stream =
> my_css_save.stream_seeds[i].stream;
> for(j=0;j @@ -2057,7 +2057,7 @@ ia_css_resume(void)
> }
> my_css_save.mode = sh_css_mode_working;
> ia_css_debug_dtrace(IA_CSS_DEBUG_TRACE, "ia_css_resume() leave:
> return_void\n");
> - return(IA_CSS_SUCCESS);
> + return IA_CSS_SUCCESS;
> }
>
> enum ia_css_err
> @@ -10261,7 +10261,7 @@ ia_css_stream_load(struct ia_css_stream *stream)
> for(k=0;k
> ia_css_pipe_destroy(my_css_save.stream_seeds[i].pipes[k]);
> }
> - return(err);
> + return err;
> }
> err =
> ia_css_stream_create(&(my_css_save.stream_seeds[i].stream_config),
> my_css_save.stream_seeds[i].num_pipes,
>
> my_css_save.stream_seeds[i].pipes, &(my_css_save.stream_seeds[i].stream));
> @@ -10270,12 +10270,12 @@ ia_css_stream_load(struct ia_css_stream *stream)
> ia_css_stream_destroy(stream);
>
> for(j=0;j
> ia_css_pipe_destroy(my_css_save.stream_seeds[i].pipes[j]);
> - return(err);
> + return err;
> }
> break;
> }
> ia_css_debug_dtrace(IA_CSS_DEBUG_TRACE, "ia_css_stream_load() exit,
> \n");
> - return(IA_CSS_SUCCESS);
> + return IA_CSS_SUCCESS;
> #else
> /* TODO remove function - DEPRECATED */
> (void)stream;
> @@ -10416,7 +10416,7 @@ ia_css_stream_unload(struct ia_css_stream *stream)
> break;
> }
> ia_css_debug_dtrace(IA_CSS_DEBUG_TRACE, "ia_css_stream_unload() exit,
> \n");
> - return(IA_CSS_SUCCESS);
> + return IA_CSS_SUCCESS;
> }
>
> #endif
> diff --git
> a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
> b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
> index b7db3de..d3567ac 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
> @@ -74,7 +74,7 @@ static struct fw_param *fw_minibuffer;
>
> char *sh_css_
Re: [PATCH 00/13] rtc: Add OF device table to I2C drivers that are missing it
Hello Alexandre, Sorry for the long email... On 03/03/2017 01:04 PM, Alexandre Belloni wrote: > On 03/03/2017 at 12:27:23 -0300, Javier Martinez Canillas wrote: >> On 03/03/2017 12:01 PM, Alexandre Belloni wrote: >>> On 03/03/2017 at 11:29:11 -0300, Javier Martinez Canillas wrote: This series add OF device ID tables to RTC I2C drivers whose devices are either used in Device Tree source files or are listed in binding docs as a compatible string. That's done because the plan is to change the I2C core to report proper OF modaliases instead of always reporting a MODALIAS=i2c: regardless if a device was registered via DT or using the legacy platform data. >>> >>> Doesn't that break the DT ABI for all i2c devices? A lot of people are >>> getting the vendor wrong in the compatible string and because the i2c >>> core doesn't care, the driver is still probed. Dropping that will break >>> all those DTBs. >>> Or will that only affect module autoload? >>> >> >> The change will only be for module autoload. The I2C core will still attempt >> to match the I2C device ID table as a fallback if fails to match the OF one. >> So there's no change in the match logic for drivers that do the wrong thing. >> > > I'm probably not seeing the big picture here but then I don't understand The big picture is to make the I2C subsystem to be consistent with other subsystems. Take the platform bus as an example, platform drivers define an OF ID table if the platform devices are going to be registered via DT and a platform ID table if the driver supports legacy platform device registration. But that's not the case for I2C, either only a I2C device ID table is defined (and the vendor prefix not used which lead to the current situation of wrong DT's) or a OF device ID table is used to match but still a I2C device table with duplicated entries is needed only to make the driver module to autoload. > why you are reworking the id->driver_data handling and using > of_device_get_match_data instead. > I meant that the proposed change to the I2C core is only for module autoload. The driver changes are for both match and autoload (once I2C core is fixed). So the change to use the of_device_id .data instead of the i2c_device_id .driver_data is to use the correct entry in case the I2C core matches using the OF table instead of the I2C table. Another option is to do the opposite of what's needed currently, that is to have an I2C table to match and only use the OF table to populate the OF aliases in the module (i.e: not setting the .of_match_table field). But I think that if the device is registered via OF, then the correct thing to do is to match using the OF table and the OF aliases for module autoload. > If this is related to b8a1a4cd5a98a2adf8dfd6902cd98e57d910ee12, that is > a completely different issue (and that is probably the kind of changes > that should be notified to maintainers). > It's related in some way. There were two reasons why a I2C driver required a I2C table: 1) Because their probe function received a struct i2c_device_id as argument. 2) Because the reported MODALIAS is always i2c: regardless of how the device was registered (legacy platform dev or DT). Lee's commit that you mention solves (1) and I'm trying to solve (2). >> If someone is using a wrong vendor prefix and the DT can't be changed, then >> an entry in the OF device ID table has to be added for "wrong_vendor,device" >> so the MODALIAS uevent can be "of:N*T*wrong_vendor,device". >> > > And then, we end up with a crap load of useless strings that are matched > against at boottime... > I'm saying that because all the rv3029 compatible strings are wrong. > Yeah... that's the joy of the DT backward compatibility. The reason why added those (wrong) compatibles for rv3029 is because there are mainline users that are either not using a vendor or using a wrong one (mc instead of microchip). Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America
Re: [PATCH v9 00/11] uapi: export all headers under uapi directories
Le 02/03/2017 à 17:56, Nicolas Dichtel a écrit : > Patches #1 and #2 are just cleanup: some exported headers were still under > a non-uapi directory. Patch #3 is a fix to avoid exporting a file that was > not under an uapi directory. > After these three patches, all exported headers are under an uapi directory: > path #4 stops searching files in non uapi directories. > The patch #5 was spotted by code review: there is no in-tree user of this > functionality. > Patch #6 fixes some warnings/errors reported by 0-day tests. > Patch #7 to #9 fix some errors when the corresponding files are included by > userland. > Patches #10 and #11 remove the need to list explicitly headers. Now all files > under an uapi directory are exported. > > This series has been tested with a 'make headers_install' on x86 and a > 'make headers_install_all'. I've checked the result of both commands. > > This patch is built against linus tree. If I must rebase it against the kbuild > tree, just tell me. > Michal, is this series going through your tree? I'm a bit pushy on this, but it would be nice to get this series in before the rc1. In fact, it would certainly be better to have this living some times in -next, but it would probably generate a lot of conflicts in linux-next. OTOH those conflicts would be easy to solve. Regards, Nicolas
Re: [PATCH] vmbus: remove hv_event_tasklet_disable/enable
On Fri, 03 Mar 2017 17:40:47 +0100
Vitaly Kuznetsov wrote:
> Dexuan Cui writes:
>
> > With the recent introduction of per-channel tasklet, we need to update
> > the way we handle the 3 concurrency issues:
> >
> > 1. hv_process_channel_removal -> percpu_channel_deq vs.
> >vmbus_chan_sched -> list_for_each_entry(..., percpu_list);
> >
> > 2. vmbus_process_offer -> percpu_channel_enq/deq vs. vmbus_chan_sched.
> >
> > 3. vmbus_close_internal vs. the per-channel tasklet vmbus_on_event;
> >
> > The first 2 issues can be handled by Stephen's recent patch
> > "vmbus: use rcu for per-cpu channel list", and the third issue
> > can be handled by calling tasklet_disable in vmbus_close_internal here.
> >
> > We don't need the original hv_event_tasklet_disable/enable since we
> > now use per-channel tasklet instead of the previous per-CPU tasklet,
> > and actually we must remove them due to the side effect now:
> > vmbus_process_offer -> hv_event_tasklet_enable -> tasklet_schedule will
> > start the per-channel callback prematurely, cauing NULL dereferencing
> > (the channel may haven't been properly configured to run the callback yet).
> >
> > Fixes: 631e63a9f346 ("vmbus: change to per channel tasklet")
> >
> > Signed-off-by: Dexuan Cui
> > Cc: "K. Y. Srinivasan"
> > Cc: Haiyang Zhang
> > Cc: Stephen Hemminger
>
> Tested-by: Vitaly Kuznetsov
>
> This patch fixes the following crash on boot:
>
> [1.451648] BUG: unable to handle kernel NULL pointer dereference at
> 0004
> [1.452255] IP: netvsc_channel_cb+0x90/0x7b0 [hv_netvsc]
> [1.452255] PGD 0
> [1.452255]
> [1.452255] Oops: [#1] SMP
> [1.452255] Modules linked in: hv_storvsc hv_netvsc(+) scsi_transport_fc
> hyperv_fb hyperv_keyboard hid_hyperv hv_vmbus
> [1.452255] CPU: 1 PID: 19 Comm: ksoftirqd/1 Not tainted 4.10.0_test+ #911
> [1.452255] Hardware name: Microsoft Corporation Virtual Machine/Virtual
> Machine, BIOS Hyper-V UEFI Release v1.0 11/26/2012
> [1.452255] task: 880007fd2b00 task.stack: c9e34000
> [1.452255] RIP: 0010:netvsc_channel_cb+0x90/0x7b0 [hv_netvsc]
> ...
> [1.452255] Call Trace:
> [1.452255] vmbus_on_event+0x22/0x90 [hv_vmbus]
> [1.452255] tasklet_action+0x5e/0x110
> [1.452255] __do_softirq+0x104/0x2af
> [1.452255] run_ksoftirqd+0x29/0x40
> ...
> [1.548068] RIP: netvsc_channel_cb+0x90/0x7b0 [hv_netvsc] RSP:
> c9e37d88
> [1.548068] CR2: 0004
> [1.548068] ---[ end trace 601fd9d6588b21e5 ]---
> [1.548068] Kernel panic - not syncing: Fatal exception in interrupt
> [1.548068] Kernel Offset: disabled
> [1.548068] ---[ end Kernel panic - not syncing: Fatal exception in
> interrupt
> [1.572155] [ cut here ]
>
> The crash is not imminent but it happens pretty often on boot, I think
> we need to push it to 4.11.
>
Agree that this needs to be in 4.11, but when NAPI is merged it also will not
happen.
Re: [PATCH v3] tpm: do not suspend/resume if power stays on
On Fri, Mar 03, 2017 at 05:09:59PM +0100, Enric Balletbo i Serra wrote: > From: Sonny Rao > > The suspend/resume behavior of the TPM can be controlled by setting > "powered-while-suspended" in the DTS. This is useful for the cases > when hardware does not power-off the TPM. > > Signed-off-by: Sonny Rao > Signed-off-by: Enric Balletbo i Serra Reviewed-by: Jason Gunthorpe > +++ b/drivers/char/tpm/tpm_of.c > @@ -34,6 +34,9 @@ int tpm_read_log_of(struct tpm_chip *chip) > else > return -ENODEV; > > + if (of_property_read_bool(np, "powered-while-suspended")) > + chip->flags |= TPM_CHIP_FLAG_ALWAYS_POWERED; > + It is really weird that this is in a function called tpm_read_log_of, but it makes sense to use the existing conditional infrastructure for OF as well. We should try to tidy this later... Jason
RE: [Outreachy kernel] [PATCH v3 0/3] Replace "the the " with "the"
> -Original Message- > From: Julia Lawall [mailto:julia.law...@lip6.fr] > Sent: Friday, March 3, 2017 11:07 AM > To: simran singhal > Cc: gre...@linuxfoundation.org; Kershner, David A > ; *S-Par-Maintainer > ; de...@driverdev.osuosl.org; linux- > ker...@vger.kernel.org; larry.fin...@lwfinger.net; > florian.c.schilha...@googlemail.com; outreachy-ker...@googlegroups.com > Subject: Re: [Outreachy kernel] [PATCH v3 0/3] Replace "the the " with "the" > > > > On Fri, 3 Mar 2017, simran singhal wrote: > > > This patch series replace "the the " with "the" in various drivers. > > > > v3: > > -Resend the complete patch series. > > Acked-by: Julia Lawall Acked-by: David Kershner > > > > > > > simran singhal (3): > > staging: wlan-ng: Replace "the the " with "the" > > staging: rtl8192u: Replace "the the " with "the" > > staging: unisys: Replace "the the " with "the" > > > > drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c | 2 +- > > drivers/staging/unisys/visorbus/visorbus_main.c | 2 +- > > drivers/staging/wlan-ng/prism2sta.c | 2 +- > > 3 files changed, 3 insertions(+), 3 deletions(-) > > > > -- > > 2.7.4 > > > > -- > > You received this message because you are subscribed to the Google > Groups "outreachy-kernel" group. > > To unsubscribe from this group and stop receiving emails from it, send an > email to outreachy-kernel+unsubscr...@googlegroups.com. > > To post to this group, send email to outreachy-ker...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/outreachy-kernel/1488556746-599-1- > git-send-email-singhalsimran0%40gmail.com. > > For more options, visit https://groups.google.com/d/optout. > >
RE: idr: use-after-free write in ida_get_new_above
Thanks! I don't think it's syzcaller per se that's provoking this; it's a matter of an interrupt coming in at the right time and preempting a task that happens to be allocating from an IDA with another task that's also allocating from an IDA. So any workload which makes heavy use of the kernel could provoke it. I imagine syzcaller is exercising a lot of parts of the kernel which use IDAs. Funny that it didn't show up before now ... it's been in linux-next in this form since the start of February. I've created a test case which will reproduce this, and after applying this patch it no longer reproduces. So I'm confident in your second patch :-) > -Original Message- > From: Dmitry Vyukov [mailto:dvyu...@google.com] > Sent: Friday, March 3, 2017 5:06 AM > To: Matthew Wilcox ; Andrew Morton > ; ross.zwis...@linux.intel.com; Johannes Weiner > ; Jan Kara ; LKML ker...@vger.kernel.org>; Tejun Heo > Cc: syzkaller > Subject: Re: idr: use-after-free write in ida_get_new_above > > On Fri, Mar 3, 2017 at 10:51 AM, Dmitry Vyukov > wrote: > > Hello, > > > > I am hitting the following use-after-free reports while running > > syzkaller fuzzer on commit c82be9d2244aacea9851c86f4fb74694c99cd874: > > > > > == > > BUG: KASAN: use-after-free in ida_get_new_above+0x564/0x9b0 > > lib/idr.c:295 at addr 880160ef3600 > > Write of size 128 by task syz-executor1/1757 > > CPU: 1 PID: 1757 Comm: syz-executor1 Not tainted 4.10.0+ #98 > > Hardware name: Google Google Compute Engine/Google Compute Engine, > > BIOS Google 01/01/2011 > > Call Trace: > > __dump_stack lib/dump_stack.c:15 [inline] > > dump_stack+0x2ee/0x3ef lib/dump_stack.c:51 > > kasan_object_err+0x1c/0x70 mm/kasan/report.c:162 > > print_address_description mm/kasan/report.c:200 [inline] > > kasan_report_error mm/kasan/report.c:289 [inline] > > kasan_report.part.2+0x1e5/0x4b0 mm/kasan/report.c:311 > > kasan_report+0x21/0x30 mm/kasan/report.c:298 > > check_memory_region_inline mm/kasan/kasan.c:315 [inline] > > check_memory_region+0x139/0x190 mm/kasan/kasan.c:322 > > memset+0x23/0x40 mm/kasan/kasan.c:340 > > ida_get_new_above+0x564/0x9b0 lib/idr.c:295 > > ida_get_new include/linux/idr.h:209 [inline] > > proc_alloc_inum+0x97/0x1f0 fs/proc/generic.c:201 > > proc_register+0x25/0x2f0 fs/proc/generic.c:338 > > proc_create_data+0x100/0x190 fs/proc/generic.c:509 > > proc_create include/linux/proc_fs.h:35 [inline] > > ip_rt_do_proc_init+0x53/0x110 net/ipv4/route.c:382 > > ops_init+0x10a/0x530 net/core/net_namespace.c:115 > > setup_net+0x2ed/0x690 net/core/net_namespace.c:291 > > copy_net_ns+0x26c/0x530 net/core/net_namespace.c:396 > > create_new_namespaces+0x409/0x860 kernel/nsproxy.c:106 > > unshare_nsproxy_namespaces+0xae/0x1e0 kernel/nsproxy.c:205 > > SYSC_unshare kernel/fork.c:2281 [inline] > > SyS_unshare+0x64e/0xfc0 kernel/fork.c:2231 > > entry_SYSCALL_64_fastpath+0x1f/0xc2 > > RIP: 0033:0x44fb79 > > RSP: 002b:7f1b66930b58 EFLAGS: 0212 ORIG_RAX: > 0110 > > RAX: ffda RBX: RCX: 0044fb79 > > RDX: RSI: RDI: 62020200 > > RBP: 62020200 R08: R09: > > R10: R11: 0212 R12: 007082a0 > > R13: 0004 R14: 0400 R15: > > Object at 880160ef3600, in cache kmalloc-128 size: 128 > > Allocated: > > PID = 1730 > > save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57 > > save_stack+0x43/0xd0 mm/kasan/kasan.c:502 > > set_track mm/kasan/kasan.c:514 [inline] > > kasan_kmalloc+0xaa/0xd0 mm/kasan/kasan.c:605 > > kmem_cache_alloc_trace+0x10b/0x670 mm/slab.c:3634 > > kmalloc include/linux/slab.h:490 [inline] > > ida_pre_get+0xcd/0xe0 lib/radix-tree.c:2129 > > proc_alloc_inum+0xc5/0x1f0 fs/proc/generic.c:197 > > proc_register+0x25/0x2f0 fs/proc/generic.c:338 > > proc_create_data+0x100/0x190 fs/proc/generic.c:509 > > proc_create include/linux/proc_fs.h:35 [inline] > > packet_net_init+0x8d/0xb0 net/packet/af_packet.c:4488 > > ops_init+0x10a/0x530 net/core/net_namespace.c:115 > > setup_net+0x2ed/0x690 net/core/net_namespace.c:291 > > copy_net_ns+0x26c/0x530 net/core/net_namespace.c:396 > > create_new_namespaces+0x409/0x860 kernel/nsproxy.c:106 > > unshare_nsproxy_namespaces+0xae/0x1e0 kernel/nsproxy.c:205 > > SYSC_unshare kernel/fork.c:2281 [inline] > > SyS_unshare+0x64e/0xfc0 kernel/fork.c:2231 > > entry_SYSCALL_64_fastpath+0x1f/0xc2 > > Freed: > > PID = 1648 > > save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57 > > save_stack+0x43/0xd0 mm/kasan/kasan.c:502 > > set_track mm/kasan/kasan.c:514 [inline] > > kasan_slab_free+0x6f/0xb0 mm/kasan/kasan.c:578 > > __cache_free mm/slab.c:3510 [inline] > > kfree+0xd3/0x250 mm/slab.c:3827 > > ida_pre_get+0x8a/0xe0 lib/radix-tree.c:2133 > > ida_simple_get+0x168/0x320 lib/idr.c:443 > > __kernfs_new_
Re: [PATCH v5 4/4] iio: accel: adxl345: Add SPI support
On Tue, Feb 28, 2017 at 4:37 AM, Eva Rachel Retuya wrote:
> Add SPI driver that initializes SPI regmap for the adxl345 core driver.
> The driver supports the same functionality as I2C namely the x, y, z and
> scale readings.
Portion of minor comments.
> +config ADXL345_SPI
> + tristate "Analog Devices ADXL345 3-Axis Digital Accelerometer SPI
> Driver"
> + depends on !(INPUT_ADXL34X=y || INPUT_ADXL34X=m)
Same question. Would it be just
depends on INPUT_ADXL34X=n
?
> +/* Setting bits 7 and 6 enables multiple-byte read */
> + .read_flag_mask = BIT(7) | BIT(6),
GENMASK(7, 6) ?
> +static int adxl345_spi_probe(struct spi_device *spi)
> +{
> + struct regmap *regmap;
> + const struct spi_device_id *id = spi_get_device_id(spi);
Reverse order.
And usually we do assignments from function parameters first.
> + dev_err(&spi->dev, "Error initializing spi regmap: %d\n",
> + (int)PTR_ERR(regmap));
Ugly casting!
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v9 00/10] mux controller abstraction and iio/i2c muxes
> Jonathan, Wolfram, do you have any preferences on how this should be > coordinated regarding the new iio and i2c drivers (and iio changes)? You got the acks, all is fine, I think. > My plan is to at some point declare the branch immutable. Then both of > you can pull it in. Or? Yup, sounds good. > But now that I think about it I wonder what the point is of having > Greg pull it in also? Sure, third time's a charm and all that, but... AFAIU, Greg will be your "upstream", so he should definately pull the branch. I will just pull it in to avoid merge conflicts in my tree. Or did I misunderstand your question? signature.asc Description: PGP signature
[PATCH] staging: media: Remove parentheses from return arguments
The sematic patch used for this is: @@ identifier i; constant c; @@ return - ( \(i\|-i\|i(...)\|c\) - ) ; Signed-off-by: simran singhal --- .../media/atomisp/pci/atomisp2/css2400/sh_css.c | 20 ++-- .../atomisp/pci/atomisp2/css2400/sh_css_firmware.c | 2 +- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c index f39d6f5..1216efb 100644 --- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c +++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c @@ -2009,7 +2009,7 @@ enum ia_css_err ia_css_suspend(void) for(i=0;i after 1: seed %d (%p)\n", i, my_css_save.stream_seeds[i].stream); ia_css_debug_dtrace(IA_CSS_DEBUG_TRACE, "ia_css_suspend() leave\n"); - return(IA_CSS_SUCCESS); + return IA_CSS_SUCCESS; } enum ia_css_err @@ -2021,10 +2021,10 @@ ia_css_resume(void) err = ia_css_init(&(my_css_save.driver_env), my_css_save.loaded_fw, my_css_save.mmu_base, my_css_save.irq_type); if (err != IA_CSS_SUCCESS) - return(err); + return err; err = ia_css_start_sp(); if (err != IA_CSS_SUCCESS) - return(err); + return err; my_css_save.mode = sh_css_mode_resume; for(i=0;i
RE: [PATCH 01/26] compiler: introduce noinline_for_kasan annotation
From: Andrey Ryabinin > Sent: 03 March 2017 13:50 ... > noinline_iff_kasan might be a better name. noinline_for_kasan gives the > impression > that we always noinline function for the sake of kasan, while > noinline_iff_kasan > clearly indicates that function is noinline only if kasan is used. noinline_if_stackbloat David
Re: [PATCH v5 3/4] iio: accel: adxl345: Split driver into core and I2C
On Tue, Feb 28, 2017 at 4:37 AM, Eva Rachel Retuya wrote:
> Move I2C-specific code into its own file and rely on regmap to access
> registers. The core code provides access to x, y, z and scale readings.
Portion of minor comments.
> +config ADXL345_I2C
> + tristate "Analog Devices ADXL345 3-Axis Digital Accelerometer I2C
> Driver"
> depends on !(INPUT_ADXL34X=y || INPUT_ADXL34X=m)
I'm wondering if it works in a form of
depends on INPUT_ADXL34X=n
> +int adxl345_common_probe(struct device *dev, struct regmap *regmap,
> +const char *name);
> +int adxl345_common_remove(struct device *dev);
I think a "common" word is redundant.
> - * IIO driver for ADXL345
> - * 7-bit I2C slave address: 0x1D (ALT ADDRESS pin tied to VDDIO) or
> - * 0x53 (ALT ADDRESS pin grounded)
> + * IIO core driver for ADXL345
Should not it be at the beginning of header comment?
> +static int adxl345_i2c_probe(struct i2c_client *client,
> +const struct i2c_device_id *id)
> +{
> + struct regmap *regmap;
> + const char *name = NULL;
Reverse tree order, please.
> +
> + regmap = devm_regmap_init_i2c(client, &adxl345_i2c_regmap_config);
> + if (IS_ERR(regmap)) {
> + dev_err(&client->dev, "Error initializing i2c regmap: %d\n",
> + (int)PTR_ERR(regmap));
> + return PTR_ERR(regmap);
> + }
> +
> + if (id)
> + name = id->name;
> +
> + return adxl345_common_probe(&client->dev, regmap, name);
Do you need temporary variable?
return adxl345_probe(&client->dev, regmap, id ? id->name : NULL);
--
With Best Regards,
Andy Shevchenko
Re: [RFC PATCH v2 01/32] x86: Add the Secure Encrypted Virtualization CPU feature
On Thu, Mar 02, 2017 at 10:12:09AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky
>
> Update the CPU features to include identifying and reporting on the
> Secure Encrypted Virtualization (SEV) feature. SME is identified by
> CPUID 0x801f, but requires BIOS support to enable it (set bit 23 of
> MSR_K8_SYSCFG and set bit 0 of MSR_K7_HWCR). Only show the SEV feature
> as available if reported by CPUID and enabled by BIOS.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/include/asm/cpufeatures.h |1 +
> arch/x86/include/asm/msr-index.h |2 ++
> arch/x86/kernel/cpu/amd.c | 22 ++
> arch/x86/kernel/cpu/scattered.c|1 +
> 4 files changed, 22 insertions(+), 4 deletions(-)
So this patchset is not really ontop of Tom's patchset because this
patch doesn't apply. The reason is, Tom did the SME bit this way:
https://lkml.kernel.org/r/20170216154236.19244.7580.st...@tlendack-t1.amdoffice.net
but it should've been in scattered.c.
> diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
> index cabda87..c3f58d9 100644
> --- a/arch/x86/kernel/cpu/scattered.c
> +++ b/arch/x86/kernel/cpu/scattered.c
> @@ -31,6 +31,7 @@ static const struct cpuid_bit cpuid_bits[] = {
> { X86_FEATURE_CPB, CPUID_EDX, 9, 0x8007, 0 },
> { X86_FEATURE_PROC_FEEDBACK,CPUID_EDX, 11, 0x8007, 0 },
> { X86_FEATURE_SME, CPUID_EAX, 0, 0x801f, 0 },
> + { X86_FEATURE_SEV, CPUID_EAX, 1, 0x801f, 0 },
> { 0, 0, 0, 0, 0 }
... and here it is in scattered.c, as it should be. So you've used an
older version of the patch, it seems.
Please sync with Tom to see whether he's reworked the v4 version of that
patch already. If yes, then you could send only the SME and SEV adding
patches as a reply to this message so that I can continue reviewing in
the meantime.
Thanks.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
--
Re: net/dccp: use-after-free in dccp_feat_activate_values
On Fri, Mar 3, 2017 at 3:48 PM, Eric Dumazet wrote:
> On Fri, 2017-03-03 at 06:32 -0800, Eric Dumazet wrote:
>> On Fri, 2017-03-03 at 15:11 +0100, Dmitry Vyukov wrote:
>> > On Mon, Feb 13, 2017 at 11:29 PM, Cong Wang
>> > wrote:
>> > > On Mon, Feb 13, 2017 at 11:19 AM, Andrey Konovalov
>> > > wrote:
>> > >> Hi,
>> > >>
>> > >> I've got the following error report while fuzzing the kernel with
>> > >> syzkaller.
>> > >>
>> > >> On commit 926af6273fc683cd98cd0ce7bf0d04a02eed6742.
>> > >>
>> > >> A reproducer and .config are attached.
>> > >> Note, that it takes quite some time to trigger the bug (up to 10
>> > >> minutes).
>> > >>
>> > >> BUG: KASAN: use-after-free in dccp_feat_activate_values+0x967/0xab0
>> > >> net/dccp/feat.c:1541 at addr 88003713be68
>> > >> Read of size 8 by task syz-executor2/8457
>> > >> CPU: 2 PID: 8457 Comm: syz-executor2 Not tainted 4.10.0-rc7+ #127
>> > >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
>> > >> 01/01/2011
>> > >> Call Trace:
>> > >>
>> > >> __dump_stack lib/dump_stack.c:15 [inline]
>> > >> dump_stack+0x292/0x398 lib/dump_stack.c:51
>> > >> kasan_object_err+0x1c/0x70 mm/kasan/report.c:162
>> > >> print_address_description mm/kasan/report.c:200 [inline]
>> > >> kasan_report_error mm/kasan/report.c:289 [inline]
>> > >> kasan_report.part.1+0x20e/0x4e0 mm/kasan/report.c:311
>> > >> kasan_report mm/kasan/report.c:332 [inline]
>> > >> __asan_report_load8_noabort+0x29/0x30 mm/kasan/report.c:332
>> > >> dccp_feat_activate_values+0x967/0xab0 net/dccp/feat.c:1541
>> > >> dccp_create_openreq_child+0x464/0x610 net/dccp/minisocks.c:121
>> > >> dccp_v6_request_recv_sock+0x1f6/0x1960 net/dccp/ipv6.c:457
>> > >> dccp_check_req+0x335/0x5a0 net/dccp/minisocks.c:186
>> > >> dccp_v6_rcv+0x69e/0x1d00 net/dccp/ipv6.c:711
>> > >> ip6_input_finish+0x46d/0x17a0 net/ipv6/ip6_input.c:279
>> > >> NF_HOOK include/linux/netfilter.h:257 [inline]
>> > >> ip6_input+0xdb/0x590 net/ipv6/ip6_input.c:322
>> > >> dst_input include/net/dst.h:507 [inline]
>> > >> ip6_rcv_finish+0x289/0x890 net/ipv6/ip6_input.c:69
>> > >> NF_HOOK include/linux/netfilter.h:257 [inline]
>> > >> ipv6_rcv+0x12ec/0x23d0 net/ipv6/ip6_input.c:203
>> > >> __netif_receive_skb_core+0x1ae5/0x3400 net/core/dev.c:4190
>> > >> __netif_receive_skb+0x2a/0x170 net/core/dev.c:4228
>> > >> process_backlog+0xe5/0x6c0 net/core/dev.c:4839
>> > >> napi_poll net/core/dev.c:5202 [inline]
>> > >> net_rx_action+0xe70/0x1900 net/core/dev.c:5267
>> > >> __do_softirq+0x2fb/0xb7d kernel/softirq.c:284
>> > >> do_softirq_own_stack+0x1c/0x30 arch/x86/entry/entry_64.S:902
>> > >
>> > >
>> > > Seems there is a race condition between iterating dccp_feat_entry
>> > > and freeing it, bh_lock_sock() seems not held in this path.
>> >
>> >
>> >
>> > Cong, where exactly do we need to add bh_lock_sock()?
>> >
>> > I am still seeing this on 4977ab6e92e267afe9d8f78438c3db330ca8434c
>>
>>
>> I would try :
>
> Or something that would compile. I will take a deeper look after my
> commute.
Something that compiles is definitely better :)
Reapplied.
> diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
> index
> 409d0cfd34474812c3bf74f26cd423a3d65ee441..56f883b301ccd610fc24efeac4fb47d3c2f95ecf
> 100644
> --- a/net/dccp/ipv4.c
> +++ b/net/dccp/ipv4.c
> @@ -482,7 +482,11 @@ static int dccp_v4_send_response(const struct sock *sk,
> struct request_sock *req
> if (dst == NULL)
> goto out;
>
> + /* DCCP is not ready yet for lockless SYN processing */
> + bh_lock_sock((struct sock *)sk);
> skb = dccp_make_response(sk, dst, req);
> + bh_unlock_sock((struct sock *)sk);
> +
> if (skb != NULL) {
> const struct inet_request_sock *ireq = inet_rsk(req);
> struct dccp_hdr *dh = dccp_hdr(skb);
> diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c
> index
> 233b57367758c64c09ed40f7359cb8fcb1918d93..673f45f85b7c755c8165c6274ffb6b1fe5660683
> 100644
> --- a/net/dccp/ipv6.c
> +++ b/net/dccp/ipv6.c
> @@ -214,7 +214,11 @@ static int dccp_v6_send_response(const struct sock *sk,
> struct request_sock *req
> goto done;
> }
>
> + /* DCCP is not ready yet for lockless SYN processing */
> + bh_lock_sock((struct sock *)sk);
> skb = dccp_make_response(sk, dst, req);
> + bh_unlock_sock((struct sock *)sk);
> +
> if (skb != NULL) {
> struct dccp_hdr *dh = dccp_hdr(skb);
> struct ipv6_txoptions *opt;
>
>
Re: [PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE
On Fri, Mar 03, 2017 at 09:26:50AM +0100, Christian Borntraeger wrote: > Right. The main purpose is to read/write _ONCE_. You can assume a somewhat > atomic access for sizes <= word size. And there are certainly places that > rely on that. But the *ONCE thing is mostly used for things where we used > barrier() 10 years ago. A lot of code relies on READ/WRITE_ONCE() to generate single instructions for naturally aligned machined word sized loads/stores (something GCC used to guarantee, but does no longer IIRC). So much so that I would say its a bug if READ/WRITE_ONCE() doesn't generate a single instruction under those conditions. However, every time I've tried to introduce stricter semantics/primitives to verify things Linus hated it.
Re: [Outreachy kernel] [PATCH] staging: speakup: else is not generally useful after a break or return
On Fri, 3 Mar 2017, Arushi Singhal wrote:
>
>
> On Friday, March 3, 2017 at 9:33:22 PM UTC+5:30, Julia Lawall wrote:
>
>
> On Fri, 3 Mar 2017, Arushi Singhal wrote:
>
> > fixed checkpatch.pl warning: else is not generally useful
> after a break
> > or return.
> > Removed the else without affecting the logic.
> > Dead code is also eliminated.
>
> The chhange is not correct. There is a big chain of if/else if.
> The if
> (type == KT_LATIN) can reach the code at the end of the file.
>
> If there is else and all if/else have return statement so then the code will
> not reach at the end.
The first one does not end in a return.
julia
> Thanks
> Aruhsi
> \
> julia
>
> >
> > Signed-off-by: Arushi Singhal
> > ---
> > drivers/staging/speakup/keyhelp.c | 53
> ++-
> > 1 file changed, 19 insertions(+), 34 deletions(-)
> >
> > diff --git a/drivers/staging/speakup/keyhelp.c
> b/drivers/staging/speakup/keyhelp.c
> > index 4e6e5daba50c..ad3efded37c1 100644
> > --- a/drivers/staging/speakup/keyhelp.c
> > +++ b/drivers/staging/speakup/keyhelp.c
> > @@ -176,43 +176,28 @@ int spk_handle_help(struct vc_data *vc,
> u_char type, u_char ch, u_short key)
> > synth_printf("%s\n",
> spk_msg_get(MSG_HELP_INFO));
> > build_key_data(); /* rebuild each time in
> case new mapping */
> > return 1;
> > -} else {
> > -name = NULL;
> > -if ((type != KT_SPKUP) && (key > 0) && (key
> <= num_key_names)) {
> > -synth_printf("%s\n",
> > -
> spk_msg_get(MSG_KEYNAMES_START + key - 1));
> > -return 1;
> > -}
> > -for (i = 0; funcvals[i] != 0 && !name; i++) {
> > -if (ch == funcvals[i])
> > -name =
> spk_msg_get(MSG_FUNCNAMES_START + i);
> > -}
> > -if (!name)
> > -return -1;
> > -kp = spk_our_keys[key] + 1;
> > -for (i = 0; i < nstates; i++) {
> > -if (ch == kp[i])
> > -break;
> > -}
> > -key += (state_tbl[i] << 8);
> > -say_key(key);
> > -synth_printf(spk_msg_get(MSG_KEYDESC), name);
> > -synth_printf("\n");
> > -return 1;
> > }
> > -name = spk_msg_get(MSG_FUNCNAMES_START + cur_item);
> > -func = funcvals[cur_item];
> > -synth_printf("%s", name);
> > -if (key_offsets[func] == 0) {
> > -synth_printf(" %s\n",
> spk_msg_get(MSG_IS_UNASSIGNED));
> > +
> > +name = NULL;
> > +if ((type != KT_SPKUP) && (key > 0) && (key <=
> num_key_names)) {
> > +synth_printf("%s\n",
> > + spk_msg_get(MSG_KEYNAMES_START +
> key - 1));
> > return 1;
> > }
> > -p_keys = key_data + key_offsets[func];
> > -for (n = 0; p_keys[n]; n++) {
> > -val = p_keys[n];
> > -if (n > 0)
> > -synth_printf("%s ",
> spk_msg_get(MSG_DISJUNCTION));
> > -say_key(val);
> > +for (i = 0; funcvals[i] != 0 && !name; i++) {
> > +if (ch == funcvals[i])
> > +name =
> spk_msg_get(MSG_FUNCNAMES_START + i);
> > +}
> > +if (!name)
> > +return -1;
> > +kp = spk_our_keys[key] + 1;
> > +for (i = 0; i < nstates; i++) {
> > +if (ch == kp[i])
> > +break;
> > }
> > +key += (state_tbl[i] << 8);
> > +say_key(key);
> > +synth_printf(spk_msg_get(MSG_KEYDESC), name);
> > +synth_printf("\n");
> > return 1;
> > }
> > --
> > 2.11.0
> >
> > --
> > You received this message because you are subscribed to the
> Google Groups "outreachy-kernel" group.
> > To unsubscribe from this group and stop receiving emails from
> it, send an email to outreachy-kern...@googlegroups.com.
> > To post to this group, send email to
> outreach...@googlegroups.com.
> > To view this discussion on the web
> visithttps://groups.google.com/d/msgid/outreachy-kernel
Re: FW: FW: RE: Re: FW: RE: Re: Subject: [PATCH v3] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously
On Fri, 3 Mar 2017, Ajay Kaher wrote:
> > usb_class->kref is not accessible outside the file.c
> > as usb_class is _static_ inside the file.c and
> > pointer of usb_class->kref is not passed anywhere.
> >
> > Hence as you wanted, there are no references of usb_class->kref
> > other than taken by init_usb_class() and released by destroy_usb_class().
>
> Verified the code again, I hope my last comments clarifed the things
> which came in your mind and helps you to accept the patch :)
Your main point is that usb_class->kref is accessed from only two
points, both of which are protected by the new mutex. This means there
is no reason for the value to be a struct kref at all. You should
change it to an int (and change its name). Leaving it as a kref will
make readers wonder why it needs to be updated atomically.
Also, why does destroy_usb_class() have that "if (usb_class) "test?
Isn't it true that usb_class can never be NULL there?
Alan Stern
> thanks,
> ajay kaher
>
>
> Signed-off-by: Ajay Kaher
>
> ---
>
> drivers/usb/core/file.c |6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/usb/core/file.c b/drivers/usb/core/file.c
> index 822ced9..a12d184 100644
> --- a/drivers/usb/core/file.c
> +++ b/drivers/usb/core/file.c
> @@ -27,6 +27,7 @@
> #define MAX_USB_MINORS 256
> static const struct file_operations *usb_minors[MAX_USB_MINORS];
> static DECLARE_RWSEM(minor_rwsem);
> +static DEFINE_MUTEX(init_usb_class_mutex);
>
> static int usb_open(struct inode *inode, struct file *file)
> {
> @@ -109,8 +110,10 @@ static void release_usb_class(struct kref *kref)
>
> static void destroy_usb_class(void)
> {
> + mutex_lock(&init_usb_class_mutex);
> if (usb_class)
> kref_put(&usb_class->kref, release_usb_class);
> + mutex_unlock(&init_usb_class_mutex);
> }
>
> int usb_major_init(void)
> @@ -171,7 +174,10 @@ int usb_register_dev(struct usb_interface *intf,
> if (intf->minor >= 0)
> return -EADDRINUSE;
>
> + mutex_lock(&init_usb_class_mutex);
> retval = init_usb_class();
> + mutex_unlock(&init_usb_class_mutex);
> +
> if (retval)
> return retval;
>
Re: + mm-reclaim-madv_free-pages.patch added to -mm tree
On Fri, Mar 03, 2017 at 11:52:37AM +0900, Minchan Kim wrote:
> Hi,
>
> On Tue, Feb 28, 2017 at 04:32:38PM -0800, a...@linux-foundation.org wrote:
> >
> > The patch titled
> > Subject: mm: reclaim MADV_FREE pages
> > has been added to the -mm tree. Its filename is
> > mm-reclaim-madv_free-pages.patch
> >
> > This patch should soon appear at
> >
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__ozlabs.org_-7Eakpm_mmots_broken-2Dout_mm-2Dreclaim-2Dmadv-5Ffree-2Dpages.patch&d=DwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=X13hAPkxmvBro1Ug8vcKHw&m=oMKTke-r00qQPnpEwo0Cn43po669gckvribhR9LQWf0&s=wzX_7IDavzBkFEMl7HDTMwrFXo1skB35mu0CjZmfFOg&e=
> >
> > and later at
> >
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__ozlabs.org_-7Eakpm_mmotm_broken-2Dout_mm-2Dreclaim-2Dmadv-5Ffree-2Dpages.patch&d=DwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=X13hAPkxmvBro1Ug8vcKHw&m=oMKTke-r00qQPnpEwo0Cn43po669gckvribhR9LQWf0&s=eUYtR1qeasKBGvuNWsZP6jE4XwoKwMb4CdKQU7OXGYM&e=
> >
> >
> > Before you just go and hit "reply", please:
> >a) Consider who else should be cc'ed
> >b) Prefer to cc a suitable mailing list as well
> >c) Ideally: find the original patch on the mailing list and do a
> > reply-to-all to that, adding suitable additional cc's
> >
> > *** Remember to use Documentation/SubmitChecklist when testing your code ***
> >
> > The -mm tree is included into linux-next and is updated
> > there every 3-4 working days
> >
> > --
> > From: Shaohua Li
> > Subject: mm: reclaim MADV_FREE pages
> >
> > When memory pressure is high, we free MADV_FREE pages. If the pages are
> > not dirty in pte, the pages could be freed immediately. Otherwise we
> > can't reclaim them. We put the pages back to anonumous LRU list (by
> > setting SwapBacked flag) and the pages will be reclaimed in normal swapout
> > way.
> >
> > We use normal page reclaim policy. Since MADV_FREE pages are put into
> > inactive file list, such pages and inactive file pages are reclaimed
> > according to their age. This is expected, because we don't want to
> > reclaim too many MADV_FREE pages before used once pages.
> >
> > Based on Minchan's original patch
> >
> > Link:
> > http://lkml.kernel.org/r/14b8eb1d3f6bf6cc492833f183ac8c304e560484.1487965799.git.s...@fb.com
> > Signed-off-by: Shaohua Li
> > Acked-by: Minchan Kim
> > Acked-by: Michal Hocko
> > Acked-by: Johannes Weiner
> > Acked-by: Hillf Danton
> > Cc: Hugh Dickins
> > Cc: Rik van Riel
> > Cc: Mel Gorman
> > Signed-off-by: Andrew Morton
> > ---
>
> < snip >
>
> > @@ -1419,11 +1413,21 @@ static int try_to_unmap_one(struct page
> > VM_BUG_ON_PAGE(!PageSwapCache(page) &&
> > PageSwapBacked(page),
> > page);
> >
> > - if (!PageDirty(page)) {
> > + /*
> > +* swapin page could be clean, it has data stored in
> > +* swap. We can't silently discard it without setting
> > +* swap entry in the page table.
> > +*/
> > + if (!PageDirty(page) && !PageSwapCache(page)) {
> > /* It's a freeable page by MADV_FREE */
> > dec_mm_counter(mm, MM_ANONPAGES);
> > - rp->lazyfreed++;
> > goto discard;
> > + } else if (!PageSwapBacked(page)) {
> > + /* dirty MADV_FREE page */
> > + set_pte_at(mm, address, pvmw.pte, pteval);
> > + ret = SWAP_DIRTY;
> > + page_vma_mapped_walk_done(&pvmw);
> > + break;
> > }
>
> There is no point to make this logic complicated with clean swapin-page.
>
> Andrew,
> Could you fold below patch into the mm-reclaim-madv_free-pages.patch
> if others are not against?
>
> Thanks.
>
> From 0c28f6560fbc4e65da4f4a8cc4664ab9f7b11cf3 Mon Sep 17 00:00:00 2001
> From: Minchan Kim
> Date: Fri, 3 Mar 2017 11:42:52 +0900
> Subject: [PATCH] mm: clean up lazyfree page handling
>
> We can make it simple to understand without need to be aware of
> clean-swapin page.
> This patch just clean up lazyfree page handling in try_to_unmap_one.
Looks good, thanks!
Reviewed-by: Shaohua Li
> Signed-off-by: Minchan Kim
> ---
> mm/rmap.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/mm/rmap.c b/mm/rmap.c
> index bb45712..f7eab40 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -1413,17 +1413,17 @@ static int try_to_unmap_one(struct page *page, struct
> vm_area_struct *vma,
> VM_BUG_ON_PAGE(!PageSwapCache(page) &&
> PageSwapBacked(page),
> page);
>
> - /*
> - * swapin page could be clean, it has data stored in
> -
Re: [RFC PATCH 06/12] staging: android: ion: Remove crufty cache support
Hi Daniel,
On Friday 03 Mar 2017 10:56:54 Daniel Vetter wrote:
> On Thu, Mar 02, 2017 at 01:44:38PM -0800, Laura Abbott wrote:
> > Now that we call dma_map in the dma_buf API callbacks there is no need
> > to use the existing cache APIs. Remove the sync ioctl and the existing
> > bad dma_sync calls. Explicit caching can be handled with the dma_buf
> > sync API.
> >
> > Signed-off-by: Laura Abbott
> > ---
> >
> > drivers/staging/android/ion/ion-ioctl.c | 5
> > drivers/staging/android/ion/ion.c | 40
> > drivers/staging/android/ion/ion_carveout_heap.c | 6
> > drivers/staging/android/ion/ion_chunk_heap.c| 6
> > drivers/staging/android/ion/ion_page_pool.c | 3 --
> > drivers/staging/android/ion/ion_system_heap.c | 5
> > 6 files changed, 65 deletions(-)
> >
> > diff --git a/drivers/staging/android/ion/ion-ioctl.c
> > b/drivers/staging/android/ion/ion-ioctl.c index 5b2e93f..f820d77 100644
> > --- a/drivers/staging/android/ion/ion-ioctl.c
> > +++ b/drivers/staging/android/ion/ion-ioctl.c
> > @@ -146,11 +146,6 @@ long ion_ioctl(struct file *filp, unsigned int cmd,
> > unsigned long arg)>
> > data.handle.handle = handle->id;
> >
> > break;
> >
> > }
> >
> > - case ION_IOC_SYNC:
> > - {
> > - ret = ion_sync_for_device(client, data.fd.fd);
> > - break;
> > - }
>
> You missed the case ION_IOC_SYNC: in compat_ion.c.
>
> While at it: Should we also remove the entire custom_ioctl infrastructure?
> It's entirely unused afaict, and for a pure buffer allocator I don't see
> any need to have custom ioctl.
I second that, if you want to make ion a standard API, then we certainly don't
want any custom ioctl.
> More code to remove potentially:
> - The entire compat ioctl stuff - would be an abi break, but I guess if we
> pick the 32bit abi and clean up the uapi headers we'll be mostly fine.
> would allow us to remove compat_ion.c entirely.
>
> - ION_IOC_IMPORT: With this ion is purely an allocator, so not sure we
> still need to be able to import anything. All the cache flushing/mapping
> is done through dma-buf ops/ioctls.
>
>
> With the case in compat_ion.c also removed, this patch is:
>
> Reviewed-by: Daniel Vetter
>
> > case ION_IOC_CUSTOM:
> > {
> >
> > if (!dev->custom_ioctl)
> >
> > diff --git a/drivers/staging/android/ion/ion.c
> > b/drivers/staging/android/ion/ion.c index 8eef1d7..c3c316f 100644
> > --- a/drivers/staging/android/ion/ion.c
> > +++ b/drivers/staging/android/ion/ion.c
> > @@ -815,22 +815,6 @@ static void ion_unmap_dma_buf(struct
> > dma_buf_attachment *attachment,>
> > free_duped_table(table);
> >
> > }
> >
> > -void ion_pages_sync_for_device(struct device *dev, struct page *page,
> > - size_t size, enum dma_data_direction dir)
> > -{
> > - struct scatterlist sg;
> > -
> > - sg_init_table(&sg, 1);
> > - sg_set_page(&sg, page, size, 0);
> > - /*
> > -* This is not correct - sg_dma_address needs a dma_addr_t that is
valid
> > -* for the targeted device, but this works on the currently targeted
> > -* hardware.
> > -*/
> > - sg_dma_address(&sg) = page_to_phys(page);
> > - dma_sync_sg_for_device(dev, &sg, 1, dir);
> > -}
> > -
> >
> > static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
> > {
> >
> > struct ion_buffer *buffer = dmabuf->priv;
> >
> > @@ -1042,30 +1026,6 @@ struct ion_handle *ion_import_dma_buf_fd(struct
> > ion_client *client, int fd)>
> > }
> > EXPORT_SYMBOL(ion_import_dma_buf_fd);
> >
> > -int ion_sync_for_device(struct ion_client *client, int fd)
> > -{
> > - struct dma_buf *dmabuf;
> > - struct ion_buffer *buffer;
> > -
> > - dmabuf = dma_buf_get(fd);
> > - if (IS_ERR(dmabuf))
> > - return PTR_ERR(dmabuf);
> > -
> > - /* if this memory came from ion */
> > - if (dmabuf->ops != &dma_buf_ops) {
> > - pr_err("%s: can not sync dmabuf from another exporter\n",
> > - __func__);
> > - dma_buf_put(dmabuf);
> > - return -EINVAL;
> > - }
> > - buffer = dmabuf->priv;
> > -
> > - dma_sync_sg_for_device(NULL, buffer->sg_table->sgl,
> > - buffer->sg_table->nents, DMA_BIDIRECTIONAL);
> > - dma_buf_put(dmabuf);
> > - return 0;
> > -}
> > -
> >
> > int ion_query_heaps(struct ion_client *client, struct ion_heap_query
> > *query) {
> >
> > struct ion_device *dev = client->dev;
> >
> > diff --git a/drivers/staging/android/ion/ion_carveout_heap.c
> > b/drivers/staging/android/ion/ion_carveout_heap.c index 9bf8e98..e0e360f
> > 100644
> > --- a/drivers/staging/android/ion/ion_carveout_heap.c
> > +++ b/drivers/staging/android/ion/ion_carveout_heap.c
> > @@ -100,10 +100,6 @@ static void ion_carveout_heap_free(struct ion_buffer
> > *buffer)>
> > ion_heap_buffer_zero(buffer);
> >
> > - if (io
[GIT PULL] PCI fixes for v4.11
PCI fixes: - fix NULL pointer dereferences in many DesignWare-based drivers due to refactoring error - fix Altera config write breakage due to my refactoring error The following changes since commit 9e314890292c0dd357eadef6a043704fa0b4c157: Merge tag 'openrisc-for-linus' of git://github.com/openrisc/linux (2017-02-24 18:37:03 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git tags/pci-v4.11-fixes-1 for you to fetch changes up to 2a7275a3d867b228216886aae35e1f64291180b1: PCI: altera: Fix TLP_CFG_DW0 for TLP write (2017-02-28 15:06:29 -0600) pci-v4.11-fixes-1 Guenter Roeck (1): PCI: dwc: Fix crashes seen due to missing assignments Ley Foon Tan (1): PCI: altera: Fix TLP_CFG_DW0 for TLP write drivers/pci/dwc/pci-exynos.c | 1 + drivers/pci/dwc/pci-imx6.c | 1 + drivers/pci/dwc/pci-keystone.c | 2 ++ drivers/pci/dwc/pci-layerscape.c | 2 ++ drivers/pci/dwc/pcie-armada8k.c| 2 ++ drivers/pci/dwc/pcie-artpec6.c | 2 ++ drivers/pci/dwc/pcie-designware-plat.c | 2 ++ drivers/pci/dwc/pcie-hisi.c| 2 ++ drivers/pci/dwc/pcie-qcom.c| 2 ++ drivers/pci/dwc/pcie-spear13xx.c | 2 ++ drivers/pci/host/pcie-altera.c | 10 +++--- 11 files changed, 25 insertions(+), 3 deletions(-)
Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging
Hi Daniel, On Friday 03 Mar 2017 11:04:33 Daniel Vetter wrote: > On Thu, Mar 02, 2017 at 01:44:32PM -0800, Laura Abbott wrote: > > Hi, > > > > There's been some recent discussions[1] about Ion-like frameworks. There's > > apparently interest in just keeping Ion since it works reasonablly well. > > This series does what should be the final clean ups for it to possibly be > > moved out of staging. > > > > This includes the following: > > - Some general clean up and removal of features that never got a lot of > > use as far as I can tell. > > > > - Fixing up the caching. This is the series I proposed back in December[2] > > but never heard any feedback on. It will certainly break existing > > applications that rely on the implicit caching. I'd rather make an > > effort to move to a model that isn't going directly against the > > establishement though. > > > > - Fixing up the platform support. The devicetree approach was never well > > recieved by DT maintainers. The proposal here is to think of Ion less as > > specifying requirements and more of a framework for exposing memory to > > userspace. > > > > - CMA allocations now happen without the need of a dummy device structure. > > This fixes a bunch of the reasons why I attempted to add devicetree > > support before. > > > > I've had problems getting feedback in the past so if I don't hear any > > major objections I'm going to send out with the RFC dropped to be picked > > up. The only reason there isn't a patch to come out of staging is to > > discuss any other changes to the ABI people might want. Once this comes > > out of staging, I really don't want to mess with the ABI. > > > > Feedback appreciated. > > Imo looks all good. And I just realized that cross-checking with the TODO, > the 2 items about _CUSTOM and _IMPORT ioctls I noted are already there. > > Otherwise I looked through the patches, looks all really reasonable. Two more items that need to be addressed in my opinion : - Let's not export the ion_client API, we don't want drivers to be ion- specific. Only the dma-buf interface should be visible to drivers. - I haven't seen any proposal how a heap-based solution could be used in a generic distribution. This needs to be figured out before committing to any API/ABI. > Wrt merging, my experience from destaging the android syncpt stuff was > that merging the patches through the staging tree lead to lots of > cross-tree issues with the gpu folks wanting to use that. Ion will > probably run into similar things, so I'd propose we pull these cleanup > patches and the eventual de-staging in throught drm. Yes that defacto > means I'm also volunteering myself a bit :-) > > In the end we could put it all into drivers/gpu/ion or something like > that. > > Thoughts? Greg? > -Daniel > > > Thanks, > > Laura > > > > [1] https://marc.info/?l=linux-kernel&m=148699712602105&w=2 > > [2] https://marc.info/?l=linaro-mm-sig&m=148176050802908&w=2 > > > > Laura Abbott (12): > > staging: android: ion: Remove dmap_cnt > > staging: android: ion: Remove alignment from allocation field > > staging: android: ion: Duplicate sg_table > > staging: android: ion: Call dma_map_sg for syncing and mapping > > staging: android: ion: Remove page faulting support > > staging: android: ion: Remove crufty cache support > > staging: android: ion: Remove old platform support > > cma: Store a name in the cma structure > > cma: Introduce cma_for_each_area > > staging: android: ion: Use CMA APIs directly > > staging: android: ion: Make Ion heaps selectable > > staging; android: ion: Enumerate all available heaps > > > > drivers/base/dma-contiguous.c | 5 +- > > drivers/staging/android/ion/Kconfig| 51 ++-- > > drivers/staging/android/ion/Makefile | 14 +- > > drivers/staging/android/ion/hisilicon/Kconfig | 5 - > > drivers/staging/android/ion/hisilicon/Makefile | 1 - > > drivers/staging/android/ion/hisilicon/hi6220_ion.c | 113 - > > drivers/staging/android/ion/ion-ioctl.c| 6 - > > drivers/staging/android/ion/ion.c | 282 > > ++--- drivers/staging/android/ion/ion.h > > | 5 +- > > drivers/staging/android/ion/ion_carveout_heap.c| 16 +- > > drivers/staging/android/ion/ion_chunk_heap.c | 15 +- > > drivers/staging/android/ion/ion_cma_heap.c | 102 ++-- > > drivers/staging/android/ion/ion_dummy_driver.c | 156 > > drivers/staging/android/ion/ion_enumerate.c| 89 +++ > > drivers/staging/android/ion/ion_of.c | 184 -- > > drivers/staging/android/ion/ion_of.h | 37 --- > > drivers/staging/android/ion/ion_page_pool.c| 3 - > > drivers/staging/android/ion/ion_priv.h | 57 - > > drivers/staging/android/ion/ion_system_heap.c | 14 +- > > drivers/staging/android/ion/tegra/M
Re: [PATCH v2 6/9] kasan: improve slab object description
On Fri, Mar 3, 2017 at 2:31 PM, Andrey Ryabinin wrote: > On 03/02/2017 04:48 PM, Andrey Konovalov wrote: >> Changes slab object description from: >> >> Object at 880068388540, in cache kmalloc-128 size: 128 >> >> to: >> >> The buggy address belongs to the object at 880068388540 >> which belongs to the cache kmalloc-128 of size 128 >> The buggy address is located 123 bytes inside of >> 128-byte region [880068388540, 8800683885c0) >> >> Makes it more explanatory and adds information about relative offset >> of the accessed address to the start of the object. >> > > I don't think that this is an improvement. You replaced one simple line with > a huge > and hard to parse text without giving any new/useful information. > Except maybe offset, it useful sometimes, so wouldn't mind adding it to > description. Agreed. How about: === Access 123 bytes inside of 128-byte region [880068388540, 8800683885c0) Object at 880068388540 belongs to the cache kmalloc-128 === ? > -- > You received this message because you are subscribed to the Google Groups > "kasan-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to kasan-dev+unsubscr...@googlegroups.com. > To post to this group, send email to kasan-...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/kasan-dev/db0b6605-32bc-4c7a-0c99-2e60e4bdb11f%40virtuozzo.com. > For more options, visit https://groups.google.com/d/optout. -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg
Re: [PATCH V3] perf: qcom: Add L3 cache PMU driver
Hi Augustin,
On Thu, Mar 02, 2017 at 03:58:32PM -0500, Agustin Vega-Frias wrote:
> This adds a new dynamic PMU to the Perf Events framework to program
> and control the L3 cache PMUs in some Qualcomm Technologies SOCs.
>
> The driver supports a distributed cache architecture where the overall
> cache for a socket is comprised of multiple slices each with its own PMU.
> Access to each individual PMU is provided even though all CPUs share all
> the slices. User space needs to aggregate to individual counts to provide
> a global picture.
>
> The driver exports formatting and event information to sysfs so it can
> be used by the perf user space tools with the syntaxes:
>perf stat -a -e l3cache_0_0/read-miss/
>perf stat -a -e l3cache_0_0/event=0x21/
As a high-level thing, while we can't do aggregation of counts across
slices, and while we'd have to reject cross-slice groups, we *could*
have a single struct PMU that covers all those slices, with userspace
selecting which slice an event targets via
perf_event_attr::config{,1,2}. i.e. we'd treat those as independent
sub-units under the PMU.
With some sysfs and userspace work, it would then be possible to have
the perf tool infer automatically that it should open an event on each
sub-unit as it currently does per-cpu.
>
> Signed-off-by: Agustin Vega-Frias
> ---
> drivers/perf/Kconfig | 10 +
> drivers/perf/Makefile | 1 +
> drivers/perf/qcom_l3_pmu.c | 755
> +
> include/linux/cpuhotplug.h | 1 +
> 4 files changed, 767 insertions(+)
> create mode 100644 drivers/perf/qcom_l3_pmu.c
This could do with documentation, as we have for the L2 PMU in
Documentation/perf/qcom_l2_pmu.txt, e.g. with hhow to user the long
counter option.
IIRC this also has a flat event space, rather than the row/column style
that the L2 PMU has. That would be worth mentioning explicitly, too.
[...]
> diff --git a/drivers/perf/qcom_l3_pmu.c b/drivers/perf/qcom_l3_pmu.c
> new file mode 100644
> index 000..207f174
> --- /dev/null
> +++ b/drivers/perf/qcom_l3_pmu.c
> @@ -0,0 +1,755 @@
> +/* Copyright (c) 2015-2017, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Nit: please keep includes ordered alphabetically.
Also, as a general stylistic note, please keep the start of the file
file organised as:
1) description of the file
2) copyright
3) includes
4) code
(perhaps with 1 & 2 being the same comment block)
That's what we do in the other PMU drivers in this directory.
> +/*
> + * Driver for the L3 cache PMUs in Qualcomm Technologies chips.
> + *
> + * The driver supports a distributed cache architecture where the overall
> + * cache for a socket is comprised of multiple slices each with its own PMU.
> + * Access to each individual PMU is provided even though all CPUs share all
> + * the slices. User space needs to aggregate to individual counts to provide
> + * a global picture.
> + *
> + * The hardware supports counter chaining to provide the user a way to avoid
> + * overhead of software counter maintenance. This is exposed via a the 'lc'
> + * flag field in perf_event_attr.config.
We should be able to refer to the documentation file here.
> + *
> + * The hardware also supports a feature that asserts the IRQ on the toggling
> + * of the most significanty bit in the 32bit counter.
Nit: s/significanty/significant/
This is just an overflow interrupt, right?
Or does this interrupt also trigger when bit 31 goes from 0 to 1?
[...]
> +/*
> + * Decoding of settings from perf_event_attr
> + *
> + * The config format for perf events is:
> + * - config: bits 0-7: event type
> + * bit 32: HW counter size requested, 0: 32 bits, 1: 64 bits
> + */
Not really a problem, but is there a specific reason to avoid bits 31-8?
> +static inline u32 get_event_type(struct perf_event *event)
> +{
> + return (event->attr.config) & L3_MAX_EVTYPE;
> +}
> +
> +static inline int get_hw_counter_size(struct perf_event *event)
> +{
> + return event->attr.config >> 32 & 1;
> +}
This would be better as something like
#define L3_EVENT_ATTR_LC_BIT32
static inline bool event_uses_long_counter(struct perf_event *event)
{
return !!(event->attr.config & BIT_ULL(L3_EVENT_ATTR_LC_BIT));
}
That way it's clear what the return value means, and you can reuse the
definition for the sysfs attr.
That means qcom_l3_cache__event_add(
