RE: [PATCH v2] net: bluetooth: hci_sock: Use 'const void *' instead of 'void *' for 2nd parameter of hci_test_bit()

From: Chen Gang S [mailto:gang.c...@sunrus.com.cn] On 2/5/15 05:09, Marcel Holtmann wrote: Hi Sergei, -static inline int hci_test_bit(int nr, void *addr) +static inline int hci_test_bit(int nr, const void *addr) { return *((__u32 *) addr + (nr 5)) ((__u32) 1 (nr 31));

RE: [PATCH 1/2] if_link: Add VF multicast promiscuous mode control

From: Hiroshi Shimamoto From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com Add netlink directives and ndo entry to control VF multicast promiscuous mode. Intel ixgbe and ixgbevf driver can handle only 30 multicast MAC addresses per VF. It means that we cannot assign over 30 IPv6 addresses

RE: [PATCH v2 07/11] powerpc/8xx: macro for handling CPU15 errata

From Christophe Leroy Having a macro will help keep clear code. It might remove an #if but it doesn't really help. All it means is that anyone reading the code has to hunt for the definition before proceeding. Some comment about what (and why) the extra code is needed might help. ... +

RE: [PATCH v2 07/11] powerpc/8xx: macro for handling CPU15 errata

From: leroy Le 20/01/2015 12:09, David Laight a écrit : From Christophe Leroy Having a macro will help keep clear code. It might remove an #if but it doesn't really help. All it means is that anyone reading the code has to hunt for the definition before proceeding. Some comment

RE: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast promiscuous mode control

From: Skidmore, Donald C From: Hiroshi Shimamoto My concern is what is the real issue that VF multicast promiscuous mode can cause. I think there is the 4k entries to filter multicast address, and the current ixgbe/ixgbevf can turn all bits on from VM. That is almost same as

RE: [PATCH v2 1/1] atm: remove deprecated use of pci api

From: David Miller From: Quentin Lambert lambert.quen...@gmail.com Date: Mon, 12 Jan 2015 17:10:42 +0100 @@ -2246,7 +2246,8 @@ static int eni_init_one(struct pci_dev *pci_dev, goto err_disable; zero = eni_dev-zero; - zero-addr = pci_alloc_consistent(pci_dev,

RE: [PATCH v2 1/2] fixup! net/macb: Adding comments to various #defs to make interpretation easier

From: Xander Huff Put #define comments into a single line. Breaks the 80 char limit. I suspect the definitions could be made to fit by judicial editing. But that probably requires knowing exactly what the comments mean. David Signed-off-by: Xander Huff xander.h...@ni.com ---

RE: [E1000-devel] [PATCH 1/2] if_link: Add VF multicast promiscuous mode control

From: Hiroshi Shimamoto My concern is what is the real issue that VF multicast promiscuous mode can cause. I think there is the 4k entries to filter multicast address, and the current ixgbe/ixgbevf can turn all bits on from VM. That is almost same as enabling multicast promiscuous mode.

RE: [PATCH 3.12 065/122] lib/checksum.c: fix carry in csum_tcpudp_nofold

From: Karl Beldan On Tue, Feb 17, 2015 at 12:04:22PM +, David Laight wrote: +static inline u32 from64to32(u64 x) +{ + /* add up 32-bit and 32-bit for 32+c bit */ + x = (x 0x) + (x 32); + /* add up carry.. */ + x = (x 0x) + (x 32); + return (u32)x

RE: [PATCH] iwl4965: Enable checking of format strings

From: Rasmus Villemoes Well, probably the linker is allowed to overlap anonymous objects (string literals) with whatever const char[] (or indeed any const) object it finds containing the appropriate byte sequence. But I think language lawyers would insist that for const char foo[] = a

RE: [PATCH 3.12 065/122] lib/checksum.c: fix carry in csum_tcpudp_nofold

+static inline u32 from64to32(u64 x) +{ + /* add up 32-bit and 32-bit for 32+c bit */ + x = (x 0x) + (x 32); + /* add up carry.. */ + x = (x 0x) + (x 32); + return (u32)x; +} As a matter of interest, does the compiler optimise away the second (x

RE: [PATCH V6 03/10] USB: f81232: implement RX bulk-in ep

From: Greg KH + for (i = 0 ; i urb-actual_length ; i += 2) { + tty_flag = TTY_NORMAL; + + if (unlikely(data[i+0] UART_LSR_BRK_ERROR_BITS)) { Never use unlikely() unless you can prove that it actually matters if you use it. Hint, it's almost impossible to prove,

RE: [PATCH net-next 1/7] timecounter: provide a macro to initialize the cyclecounter mask field.

On Mon, Jan 05, 2015 at 01:20:57PM +, David Laight wrote: +/* simplify initialization of mask field */ +#define CYCLECOUNTER_MASK(bits) (cycle_t)((bits) 64 ? ((1ULL(bits))-1) : -1) That has me chasing through the C integer promotion rules. Better might be: ((bits) 64

RE: [PATCH net-next 1/7] timecounter: provide a macro to initialize the cyclecounter mask field.

There is no need for users of the timecounter/cyclecounter code to include clocksource.h just for a single macro. Signed-off-by: Richard Cochran richardcoch...@gmail.com --- include/linux/timecounter.h |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

RE: [PATCH 05/11] powerpc/8xx: Optimise access to swapper_pg_dir

On Tue, 2014-12-16 at 16:03 +0100, Christophe Leroy wrote: All accessed to PGD entries are done via 0(r11). By using lower part of swapper_pg_dir as load index to r11, we can remove the ori instruction. Signed-off-by: Christophe Leroy christophe.le...@c-s.fr Nice :) Acked-by:

RE: [PATCH 05/11] powerpc/8xx: Optimise access to swapper_pg_dir

From: leroy christophe Le 06/01/2015 13:08, David Laight a écrit : On Tue, 2014-12-16 at 16:03 +0100, Christophe Leroy wrote: All accessed to PGD entries are done via 0(r11). By using lower part of swapper_pg_dir as load index to r11, we can remove the ori instruction. Signed-off

RE: /proc/net/dev regression

From: Al Viro I think the problem with wmnet is not that it was expecting the fields to be aligned because it never had problems before (when definitely more than 10 megabytes were received, wmnet is crappy but not _that_ crappy). I think the problem really was here,

RE: [PATCH 1/1] update ip-sysctl.txt documentation

From: Ani Sinha Update documentation to reflect the fact that /proc/sys/net/ipv4/route/max_size is no longer used for ipv4. Signed-off-by: Ani Sinha a...@arista.com --- Documentation/networking/ip-sysctl.txt |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git

RE: [PATCH net-next] rhashtable: Lower/upper bucket may map to same lock while shrinking

From: Thomas Graf Each per bucket lock covers a configurable number of buckets. While shrinking, two buckets in the old table contain entries for a single bucket in the new table. We need to lock down both while linking. Check if they are protected by different locks to avoid a recursive

RE: [PATCH net-next] rhashtable: Lower/upper bucket may map to same lock while shrinking

From: Thomas Graf ... Thought, could the shrunk table use the same locks as the lower half of the old table? No. A new bucket table and thus a new set of locks is allocated when the table is shrunk or grown. We only have check for overlapping locks when holding multiple locks for the same

RE: [PATCH net-next] rhashtable: Lower/upper bucket may map to same lock while shrinking

From: Thomas Graf ... spin_lock_bh(old_bucket_lock1); - spin_lock_bh_nested(old_bucket_lock2, RHT_LOCK_NESTED); - spin_lock_bh_nested(new_bucket_lock, RHT_LOCK_NESTED2); + + /* Depending on the lock per buckets mapping, the bucket in + *

RE: [PATCH v3] net: bluetooth: hci_sock: Use 'const u32 *' instead of 'void *' for 2nd parameter of hci_test_bit()

From: Marcel Holtmann Hi David, So at present, in kernel part, we can only say the original authors intended to do like this. And only within kernel part, it can not cause issue. I guess, original authors originally knew what we talk about. I've just searched for hci_u*filter it is

RE: [PATCH v3] net: bluetooth: hci_sock: Use 'const u32 *' instead of 'void *' for 2nd parameter of hci_test_bit()

From: Chen Gang ... So at present, in kernel part, we can only say the original authors intended to do like this. And only within kernel part, it can not cause issue. I guess, original authors originally knew what we talk about. I've just searched for hci_u*filter it is all horrid. Look at the

RE: [PATCH v3] brcmfmac: avoid duplicated suspend/resume operation

WiFi chip has 2 SDIO functions, and PM core will trigger twice suspend/resume operations for one WiFi chip to do the same things. This patch avoid this case. Do you want to suspend on the first or last request? In general it might be that one function is in use and something wants to

RE: [PATCH net-next 07/11] r8169:update rtl8168f pcie ephy parameter

From: Chunhao Lin rtl8168f may return to PCIe L0 from PCIe L0s low power mode too slow. The following ephy parameters are for this issue. { 0x00, 0x, 0x0008 } { 0x0c, 0x3df0, 0x0200 } Signed-off-by: Chunhao Lin h...@realtek.com --- drivers/net/ethernet/realtek/r8169.c | 4

Re: [PATCH v2 15/15] x86/lib/memcpy_64.S: Convert memcpy to ALTERNATIVE_2 macro

I've just 'fallen over' this 'optimisation' on a new Intel Atom processor. AFAICT all the copy functions get patched to 'rep movsb'. The problem arises when one of the buffers is uncached, in this case the 'rep movsb' has to perform single byte transfers. So memcpy_toio() and memcpy_fromio()

RE: [PATCH v10 tip 5/9] tracing: allow BPF programs to call bpf_trace_printk()

From: Alexei Starovoitov Debugging of BPF programs needs some form of printk from the program, so let programs call limited trace_printk() with %d %u %x %p modifiers only. Should anyone be allowed to use BPF programs to determine the kernel addresses of any items? Looks as though it is leaking

RE: [PATCH net-next] wireless: test sscanf return values

From: Joe Perches At some point, it'd be good to make sscanf use __must_check so make sure the net/ uses of sscanf use the return value. Isn't it much safer to avoid sscanf() completely and use a different function for converting numerics? David -- To unsubscribe from this list: send

RE: [PATCH 1/7] Add die_spin_lock_{irqsave,irqrestore}

From: Ingo Molnar ... So why not trylock and time out here after a few seconds, instead of indefinitely supressing some potentially vital output due to some other CPU crashing/locking with the lock held? I've used that for status requests that usually lock a table to get a consistent view. If

RE: [PATCH 07/11] powerpc/8xx: macro for handling CPU15 errata

From: Christophe Leroy Sent: 20 April 2015 06:27 Having a macro will help keep clear code. ... * We have to use the MD_xxx registers for the tablewalk because the * equivalent MI_xxx registers only perform the attribute functions. */ + +#ifdef CONFIG_8xx_CPU15 +#define

RE: [PATCHSET] printk, netconsole: implement reliable netconsole

From: Of Rob Landley Sent: 19 April 2015 08:25 On Thu, Apr 16, 2015 at 6:03 PM, Tejun Heo t...@kernel.org wrote: In a lot of configurations, netconsole is a useful way to collect system logs; however, all netconsole does is simply emitting UDP packets for the raw messages and there's no

RE: [Y2038] [PATCH 04/11] posix timers:Introduce the 64bit methods with timespec64 type for k_clock structure

From: Thomas Gleixner Sent: 22 April 2015 09:45 On Tue, 21 Apr 2015, Thomas Gleixner wrote: On Tue, 21 Apr 2015, Arnd Bergmann wrote: I know there are concerns about this, in particular because C11 and POSIX both require tv_nsec to be 'long', unlike timeval-tv_usec, which is a

RE: [PATCH] net: usb: allow MTU that is a multiple of USB packet size

From: Oliver Neukum Sent: 07 May 2015 11:11 On Thu, 2015-05-07 at 12:49 +0300, Ruslan Bilovol wrote: Current usbnet driver rejects setting MTU that is a multiple of USB endpoint's wMaxPacketSize size. However, it may only lead to possible performance degradation but is not so critical

RE: [PATCH 1/4] ozwpan: Use proper check to prevent heap overflow

From: Jason A. Donenfeld Sent: 13 May 2015 19:34 Since elt-length is a u8, we can make this variable a u8. Then we can do proper bounds checking more easily. Without this, a potentially negative value is passed to the memcpy inside oz_hcd_get_desc_cnf, resulting in a remotely exploitable heap

RE: [PATCH v2 0/6] powerpc32: replace memcpy and memset by cacheable alternatives

From: Christophe Leroy Sent: 19 May 2015 11:08 This patchset implements use of cacheable versions of memset and memcpy since when the destination is not cacheable, memset_io and memcpy_toio are used. This isn't the right list to ask, but: Can someone fix the x86 versions of memset/memcpy

RE: [Xen-devel] tcp: refine TSO autosizing causes performance regression on Xen

From: George Dunlap Sent: 16 April 2015 09:56 On 04/15/2015 07:19 PM, Eric Dumazet wrote: On Wed, 2015-04-15 at 19:04 +0100, George Dunlap wrote: Maybe you should stop wasting all of our time and just tell us what you're thinking. I think you make me wasting my time. I already

RE: [PATCH v3 03/17] crypto: talitos - talitos_ptr renamed ptr for more lisibility

From: Christophe Leroy Linux CodyingStyle recommends to use short variables for local variables. ptr is just good enough for those 3 lines functions. It helps keep single lines shorter than 80 characters. ... -static void to_talitos_ptr(struct talitos_ptr *talitos_ptr, dma_addr_t dma_addr)

RE: [PATCH] usb: gadget: ffs: don't allow to open with O_NONBLOCK flag

From: Robert Baldyga Hi Michal, On 04/01/2015 05:17 PM, Michal Nazarewicz wrote: On Wed, Apr 01 2015, Robert Baldyga r.bald...@samsung.com wrote: FunctionFS can't support O_NONBLOCK because read/write operatons are directly translated into USB requests which are asynchoronous, so we

RE: [PATCH] ethernet: e1000e: define lat_ns as u64 instead of s64

From: yanjiang@windriver.com Sent: 03 April 2015 10:18 From: Yanjiang Jin yanjiang@windriver.com do_div() expects the type of n to be uint64_t, define lat_ns as u64 to avoid the below warning, also update its correlative operations and data. In file included from

RE: [PATCH v3 2/2] powerpc: add support for csum_add()

From: Scott Wood Sent: 26 May 2015 20:43 ... I was thinking of all 64bit targets, not 32bit ones. Oh, you mean move it out of arch/powerpc? Sounds reasonable, but someone should probably check what the resulting code looks like on other common arches. OTOH, if we're going to modify

RE: [PATCH] net: tcp: Fix a PTO timing granularity issue

From: Of Ido Yariv Sent: 26 May 2015 21:17 The Tail Loss Probe RFC specifies that the PTO value should be set to max(2 * SRTT, 10ms), where SRTT is the smoothed round-trip time. The PTO value is converted to jiffies, so the timer may expire prematurely. This is especially problematic on

RE: [PATCH] net: tcp: Fix a PTO timing granularity issue

From: Ido Yariv Sent: 28 May 2015 05:37 ... +/* Convert msecs to jiffies, ensuring that the return value is at least 2 + * jiffies. + * This can be used when setting tick-based timers to guarantee that they won't + * expire right away. + */ +static inline unsigned long

RE: [PATCH 1/2] usb: chipidea: Reduce ULPI PHY reset pulse to datasheet spec of 1us

From: Peter Chen Sent: 30 June 2015 03:06 On Fri, Jun 26, 2015 at 03:47:03PM +0200, Mike Looijmans wrote: The datasheet for the 334x PHY mentions that a reset can be performed: ... by bringing the pin low for a minimum of 1 microsecond and then high. A delay of 5ms to implement that

RE: [PATCH v3 2/2] powerpc: add support for csum_add()

From: Linuxppc-dev Christophe Leroy Sent: 19 May 2015 16:19 ... diff --git a/arch/powerpc/include/asm/checksum.h b/arch/powerpc/include/asm/checksum.h index 5e43d2d..e8d9ef4 100644 --- a/arch/powerpc/include/asm/checksum.h +++ b/arch/powerpc/include/asm/checksum.h @@ -130,6 +130,22 @@

RE: [PATCH v3 2/2] powerpc: add support for csum_add()

From: Scott Wood ... I'd also have thought that the 64bit C version above would be generally 'good'. It doesn't generate the addc/addze sequence. At least with GCC 4.8.2, it does something like: mr tmp0, csum li tmp1, 0 li tmp2, 0 addc

RE: [PATCH v2 3/3] power: wm831x_power: Support USB charger current limit management

From: Baolin Wang Sent: 14 August 2015 10:48 +/* In miliamps */ Spelling police: milliamps +static unsigned int wm831x_usb_limits[] = { + 0, + 2, + 100, + 500, + 900, + 1500, + 1800, + 550, +}; David -- To unsubscribe from this list: send the

RE: Re: [PATCH 4.2-rc5] workqueue: Make flush_workqueue() available again to non GPL modules

From: David Laight Sent: 05 August 2015 10:52 To: linux-kernel@vger.kernel.org Subject: Re: [PATCH 4.2-rc5] workqueue: Make flush_workqueue() available again to non GPL modules From: Tejun Heo Date: 2015-08-04 18:05:20 On Tue, Aug 04, 2015 at 11:26:04AM -0600, tim.gard

RE: [PATCH] usb: gadget: f_uac1: Convert use of __constant_cpu_to_le16 to cpu_to_le16

From: Vaishali Thakkar Sent: 19 August 2015 06:31 To: Felipe Balbi Cc: Greg Kroah-Hartman; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org Subject: [PATCH] usb: gadget: f_uac1: Convert use of __constant_cpu_to_le16 to cpu_to_le16 In big endian cases, macro cpu_to_le16 unfolds to

RE: [PATCH] usb: gadget: f_uac1: Convert use of __constant_cpu_to_le16 to cpu_to_le16

From: Vaishali Thakkar [mailto:vthakkar1...@gmail.com] Sent: 22 August 2015 02:57 ... - .bcdADC = __constant_cpu_to_le16(0x0100), - .wTotalLength = __constant_cpu_to_le16(UAC_DT_TOTAL_LENGTH), + .bcdADC = cpu_to_le16(0x0100), +

RE: [PATCH v5 02/46] usb: gadget: add endpoint capabilities flags

From: Robert Baldyga Sent: 31 July 2015 15:00 Introduce struct usb_ep_caps which contains information about capabilities of usb endpoints - supported transfer types and directions. This structure should be filled by UDC driver for each of its endpoints, and will be used in epautoconf in new

RE: [PATCH 08/15] drivers: net: Drop unlikely before IS_ERR(_OR_NULL)

From: Murali Karicheri Sent: 31 July 2015 16:04 On 07/31/2015 04:38 AM, Viresh Kumar wrote: IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there is no need to do that again from its callers. Drop it. IS_ERR_OR_NULL() is defined as static inline bool __must_check

Re: [PATCH 4.2-rc5] workqueue: Make flush_workqueue() available again to non GPL modules

From: Tejun Heo Date: 2015-08-04 18:05:20 On Tue, Aug 04, 2015 at 11:26:04AM -0600, tim.gard...@canonical.com wrote: From: Tim Gardner tim.gard...@canonical.com Commit 37b1ef31a568fc02e53587620226e5f3c66454c8 (workqueue: move flush_scheduled_work() to workqueue.h) moved the

RE: [PATCH] powerpc/hvsi: Fix endianness issues in the HVSI driver

From: Laurent Dufour Sent: 31 July 2015 10:30 This patch fixes several endianness issues detected when running the HVSI driver in little endian mode. These issues are raised in little endian mode because the data exchanged in memory between the kernel and the hypervisor has to be in big

RE: [RFC] bmac:change to use bitrev8() generic function

From: Tobias Klauser Sent: 10 August 2015 12:49 On 2015-08-10 at 11:53:41 +0200, yalin wang yalin.wang2...@gmail.com wrote: This change to use generic bitrev8() for bmac driver. ... @@ -871,7 +860,7 @@ bmac_addhash(struct bmac_data *bp, unsigned char *addr) if (!(*addr)) return;

RE: [PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation

From: Paul E. McKenney > Sent: 21 October 2015 00:35 ... > There is also the question of whether the barrier forces ordering > of unrelated stores, everything initially zero and all accesses > READ_ONCE() or WRITE_ONCE(): > > P0 P1 P2 P3 > X = 1;

RE: [PATCH] of: Print rather than WARN'ing when overlap check fails

From: Michael Ellerman > Sent: 10 November 2015 05:09 > __rmem_check_for_overlap() is called very early in boot, and on some > powerpc systems it's not safe to call WARN that early in boot. > > If the overlap check fails the system will oops instead of printing a > warning. Furthermore because

RE: irq_fpu_usable() is false in ndo_start_xmit() for UDP packets

From: David Miller > Sent: 16 November 2015 20:32 > From: "Jason A. Donenfeld" > Date: Mon, 16 Nov 2015 20:52:28 +0100 > > > This works fine with, say, iperf3 in TCP mode. The AVX performance > > is great. However, when using iperf3 in UDP mode, irq_fpu_usable() > > is mostly

RE: [PATCH RFC net-next 2/2] tcp: Add Redundant Data Bundling (RDB)

From: Bendik Rønning Opstad > Sent: 23 October 2015 21:50 > RDB is a mechanism that enables a TCP sender to bundle redundant > (already sent) data with TCP packets containing new data. By bundling > (retransmitting) already sent data with each TCP packet containing new > data, the connection will

RE: [PATCH RFC net-next 2/2] tcp: Add Redundant Data Bundling (RDB)

From: Bendik Rønning Opstad > Sent: 29 October 2015 22:54 ... > > > > The semantics of the tp->nonagle bits are already a bit complex. My > > > > sense is that having a setsockopt of TCP_RDB transparently modify the > > > > nagle behavior is going to add more extra complexity and unanticipated > >

RE: [GIT] Networking

> From: Linus Torvalds > Sent: 03 November 2015 20:45 > On Tue, Nov 3, 2015 at 12:05 PM, Linus Torvalds > wrote: > > result = add_overflow( > > mul_overflow(sec, SEC_CONVERSION, ), > > mul_overflow(nsec, NSEC_CONVERSION, ), > > ); > > >

RE: [PATCH] net: hix5hd2_gmac: avoid integer overload warning

From: Arnd Bergmann > Sent: 16 October 2015 11:01 > BITS_RX_EN is an 'unsigned long' constant, so the ones complement of that > has bits set that do not fit into a 32-bit variable on 64-bit architectures, > which causes a harmless gcc warning: ... > static void hix5hd2_port_disable(struct

RE: next build: 235 warnings 3 failures (next/next-20151117)

From: Will Deacon > Sent: 18 November 2015 12:28 > On Wed, Nov 18, 2015 at 12:11:25PM +, David Laight wrote: > > From: Will Deacon > > > Sent: 18 November 2015 10:14 > > > On Tue, Nov 17, 2015 at 08:17:17PM +0100, Arnd Bergmann wrote: > > > > On Tue

RE: next build: 235 warnings 3 failures (next/next-20151117)

From: Will Deacon [mailto:will.dea...@arm.com] > Sent: 18 November 2015 15:37 > On Wed, Nov 18, 2015 at 03:21:19PM +, David Laight wrote: > > From: Will Deacon > > > Sent: 18 November 2015 12:28 > > > On Wed, Nov 18, 2015 at 12:11:25PM +, David Laight wr

RE: [GIT] Networking

> I find them useful as syntactic sugar. We have not used them a lot, but there > are cases in our crypto > handling code where we have fixed size array inputs/outputs and there we > opted to use them. They make > it easy to remember what the expected sizes of input and output are without >

RE: [GIT] Networking

From: Rustad, Mark D ... > >> static int smp_ah(struct crypto_blkcipher *tfm, const u8 irk[16], > >> const u8 r[3], u8 res[3]) > > > > Expect that it looks like you are passing arrays by value, > > but instead you are passing by reference. > > > > Explicitly pass by reference and

RE: [PATCH] powerpc32: memcpy: only use dcbz once cache is enabled

From: Christophe Leroy > Sent: 07 September 2015 15:25 ... > diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32.S > index 2ef50c6..05b3096 100644 > --- a/arch/powerpc/lib/copy_32.S > +++ b/arch/powerpc/lib/copy_32.S > @@ -172,7 +172,16 @@ _GLOBAL(memcpy) > mtctr r0 >

RE: [PATCH] x86: Wire up 32-bit direct socket calls

From: Peter Anvin > Sent: 02 September 2015 21:16 > On 09/02/2015 02:48 AM, Geert Uytterhoeven wrote: > > > > Should all other architectures follow suit? > > Or should we follow the s390 approach: > > > > It is up to the maintainer(s), largely dependent on how likely you are > going to want to

RE: [PATCH] mwifiex: Make mwifiex_dbg a function, reduce object size

From: Joe Perches > Sent: 31 August 2015 18:47 > > The mwifiex_dbg macro has two tests that could be consolidated > into a function reducing overall object size ~10KB (~4%). > > So convert the macro into a function. This looks like it will slow things down somewhat. Maybe inline the tests and

RE: First kernel patch (optimization)

From: Austin S Hemmelgarn > Sent: 16 September 2015 12:46 > On 2015-09-15 20:09, Steve Calfee wrote: > > On Tue, Sep 15, 2015 at 12:53 PM, Eric Curtin > > wrote: > >> Signed-off-by: Eric Curtin > >> > >> diff --git

RE: tools: usbip: detach: avoid calling strlen() at each iteration

From: Aaro Koskinen > Sent: 15 September 2015 21:56 ... > > - for (unsigned int i = 0; i < strlen(port); i++) > > + unsigned int port_len = strlen(port); > > + > > + for (unsigned int i = 0; i < port_len; i++) > > port is read only in this function, so maybe just use "const" and the >

RE: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V

From: Haiyang Zhang > Sent: 16 September 2015 17:09 > > -Original Message- > > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > > Sent: Wednesday, September 16, 2015 11:50 AM > > To: net...@vger.kernel.org > > Cc: David S. Miller ; linux-kernel@vger.kernel.org; >

RE: First kernel patch (optimization)

From: Jaime Arrocha > Sent: 17 September 2015 02:50 .. > One interesting observation I found was that in O0 and O2, it does make > a call to strlen while in O1 it calculates > the length of the string using: > You want an 'xor %rcx,%rcx' here. > repnz scas%es:(%rdi),%al > not

RE: [PATCH net-next RFC] net: increase LL_MAX_HEADER for Hyper-V

From: KY Srinivasan > Sent: 16 September 2015 23:58 ... > > I think we get that. The question is does the Remote NDIS header and > > packet info actually need to be a part of the header data? I would > > argue that it probably doesn't. > > > > So for example in netvsc_start_xmit it looks like

RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

From: James Bottomley > Sent: 28 September 2015 16:12 > > > > The x86 cpus will also do 32bit wide rmw cycles for the 'bit' > > > > operations. > > > > > > That's different: it's an atomic RMW operation. The problem with the > > > alpha was that the operation wasn't atomic (meaning that it

RE: [PATCH v2] net: sctp: Don't use 64 kilobyte lookup table for four elements

From: Neil Horman > Sent: 28 September 2015 14:51 > On Mon, Sep 28, 2015 at 02:34:04PM +0200, Denys Vlasenko wrote: > > Seemingly innocuous sctp_trans_state_to_prio_map[] array > > is way bigger than it looks, since > > "[SCTP_UNKNOWN] = 2" expands into "[0x] = 2" ! > > > > This patch replaces

RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] > Sent: 28 September 2015 15:27 > On Mon, 2015-09-28 at 08:58 +, David Laight wrote: > > From: Rafael J. Wysocki > > > Sent: 27 September 2015 15:09 > > ... > > > > > Say you have thr

RE: [PATCH v2] net: sctp: Don't use 64 kilobyte lookup table for four elements

From: Eric Dumazet > Sent: 28 September 2015 15:27 > On Mon, 2015-09-28 at 14:12 +, David Laight wrote: > > From: Neil Horman > > > Sent: 28 September 2015 14:51 > > > On Mon, Sep 28, 2015 at 02:34:04PM +0200, Denys Vlasenko wrote: > > > > Seemin

RE: [PATCH v2 00/14] RDS: connection scalability and performance improvements

From: Santosh Shilimkar > Sent: 30 September 2015 18:24 ... > This is being addressed by simply using per bucket rw lock which makes the > locking simple and very efficient. The hash table size is still an issue and > I plan to address it by using re-sizable hash tables as suggested on the list.

RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

From: Rafael J. Wysocki > Sent: 27 September 2015 15:09 ... > > > Say you have three adjacent fields in a structure, x, y, z, each one byte > > > long. > > > Initially, all of them are equal to 0. > > > > > > CPU A writes 1 to x and CPU B writes 2 to y at the same time. > > > > > > What's the

RE: [PATCH v2 08/25] powerpc/8xx: Map IMMR area with 512k page at a fixed address

From: Christophe Leroy > Sent: 22 September 2015 17:51 ... > Traditionaly, each driver manages one computer board which has its > own components with its own memory maps. > But on embedded chips like the MPC8xx, the SOC has all registers > located in the same IO area. > > When looking at ioremaps

RE: [PATCH v2 08/25] powerpc/8xx: Map IMMR area with 512k page at a fixed address

From: Scott Wood > Sent: 24 September 2015 21:14 > > Isn't this a more general problem? > > > > If there are multiple remap requests for the same physical page > > shouldn't the kernel be just increasing a reference count somewhere > > and returning address in the same virtual page? > > This

RE: [PATCH 05/15] RDS: increase size of hash-table to 8K

From: Santosh Shilimkar > Sent: 20 September 2015 00:05 > Even with per bucket locking scheme, in a massive parallel > system with active rds sockets which could be in excess of multiple > of 10K, rds_bin_lookup() workload is siginificant because of smaller > hashtable size. > > With some tests,

RE: [PATCH v2 3/5] printk/nmi: Try hard to print Oops message in NMI context

From: Russell King - ARM Linux > Sent: 04 December 2015 17:13 ... > I have a slightly different view... > > > > I don't see bust_spinlocks() dealing with any of these locks, so IMHO > > > trying to make this work in NMI context strikes me as making the > > > existing solution more unreliable on

RE: [PATCH v2 8/8] treewide: Remove newlines inside DEFINE_PER_CPU() macros

From: Michal Marek > Sent: 04 December 2015 15:26 > Otherwise make tags can't parse them: > > ctags: Warning: arch/ia64/kernel/smp.c:60: null expansion of name pattern "\1" ... Seems to me you need to fix ctags. David -- To unsubscribe from this list: send the line "unsubscribe

RE: [PATCH v2 5/5] printk/nmi: Increase the size of the temporary buffer

From: yalin wang > Sent: 30 November 2015 16:42 > > On Nov 27, 2015, at 19:09, Petr Mladek wrote: > > > > Testing has shown that the backtrace sometimes does not fit > > into the 4kB temporary buffer that is used in NMI context. > > > > The warnings are gone when I double the

RE: bpf: undefined shift in __bpf_prog_run

From: Dmitry Vyukov > Sent: 04 December 2015 19:49 ... > 3.4.3 > undefined behavior > 1 behavior, upon use of a nonportable or erroneous program construct > or of erroneous data, for which this International Standard imposes no > requirements > 2 NOTE Possible undefined behavior ranges from

RE: [PATCH net] ipv6: sctp: clone options to avoid use after free

> SCTP is lacking proper np->opt cloning at accept() time. > > TCP and DCCP use ipv6_dup_options() helper, do the same in SCTP. > > We might later factorize this code in a common helper to avoid > future mistakes. I'm wondering what the real impact of this and the other recent SCTP bugs/patches

RE: [PATCH net] ipv6: sctp: clone options to avoid use after free

From: Eric Dumazet [mailto:eric.duma...@gmail.com] > Sent: 09 December 2015 16:00 > On Wed, 2015-12-09 at 15:49 +, David Laight wrote: > > > SCTP is lacking proper np->opt cloning at accept() time. > > > > > > TCP and DCCP use ipv6_dup_options() helper,

RE: rhashtable: ENOMEM errors when hit with a flood of insertions

From: Herbert Xu > Sent: 03 December 2015 12:51 > On Mon, Nov 30, 2015 at 06:18:59PM +0800, Herbert Xu wrote: > > > > OK that's better. I think I see the problem. The test in > > rhashtable_insert_rehash is racy and if two threads both try > > to grow the table one of them may be tricked into

RE: [RFC PATCH 3/3] vfio-pci: Allow to mmap MSI-X table if EEH is supported

> The MSI-X table is paravirtualized on vfio in general and interrupt > remapping theoretically protects against errant interrupts, so why is > this PPC64 specific? We have the same safeguards on x86 if we want to > decide they're sufficient. Offhand, the only way I can think that a > device can

RE: [RFC PATCH 3/3] vfio-pci: Allow to mmap MSI-X table if EEH is supported

From: Alex Williamson > Sent: 17 December 2015 21:07 ... > > Is this all related to the statements in the PCI(e) spec that the > > MSI-X table and Pending bit array should in their own BARs? > > (ISTR it even suggests a BAR each.) > > > > Since the MSI-X table exists in device memory/registers

RE: [PATCH net] ipv6: sctp: clone options to avoid use after free

From: Daniel Borkmann > Sent: 09 December 2015 19:19 > On 12/09/2015 06:11 PM, Marcelo Ricardo Leitner wrote: > > Em 09-12-2015 14:31, David Laight escreveu: > >> From: Eric Dumazet [mailto:eric.duma...@gmail.com] > >>> Sent: 09 December 2015 16:00 > >>

RE: [PATCH net] ipv6: sctp: clone options to avoid use after free

From: Eric Dumazet > Sent: 10 December 2015 15:58 > > BTW, are you even using IPv6 SCTP sessions ? Our M3UA/SCTP protocol stack supports them and defaults to using IPv6 listening sockets for IPv4 connections. I very much doubt than any customers have used them yet. So most of the IPv6

RE: [PATCH] usb: remove redundant conditions

From: Felipe Balbi > Sent: 10 December 2015 15:14 > "Geyslan G. Bem" writes: > > > This patch removes redundant conditions. > > > > - (!A || (A && B)) is the same as (!A || B). > > - (length && length > 5) can be reduced to a single evaluation. > > > > Caught by: cppcheck >

RE: [PATCH] net: add per device sg_max_frags for skb

From: Hans Westgaard Ry > Sent: 06 January 2016 13:16 > Devices may have limits on the number of fragments in an skb they > support. Current codebase uses a constant as maximum for number of > fragments (MAX_SKB_FRAGS) one skb can hold and use. > > When enabling scatter/gather and running traffic

RE: [PATCH] netfilter: nf_conntrack: use safer way to lock all buckets

From: Sasha Levin > Sent: 05 January 2016 02:26 > When we need to lock all buckets in the connection hashtable we'd attempt to > lock 1024 spinlocks, which is way more preemption levels than supported by > the kernel. Furthermore, this behavior was hidden by checking if lockdep is > enabled, and

RE: [Resend PATCH] RDS: fix race condition when sending a message on unbound socket

From: Santosh Shilimkar > Sent: 24 November 2015 22:13 ... > Sasha's found a NULL pointer dereference in the RDS connection code when > sending a message to an apparently unbound socket. The problem is caused > by the code checking if the socket is bound in rds_sendmsg(), which checks > the

RE: [PATCH] sctp: use GFP_USER for user-controlled kmalloc

From: Marcelo Ricardo Leitner > Sent: 30 November 2015 16:33 > Dmitry Vyukov reported that the user could trigger a kernel warning by > using a large len value for getsockopt SCTP_GET_LOCAL_ADDRS, as that > value directly affects the value used as a kmalloc() parameter. > > This patch thus

RE: next build: 235 warnings 3 failures (next/next-20151117)

From: Will Deacon > Sent: 18 November 2015 10:14 > On Tue, Nov 17, 2015 at 08:17:17PM +0100, Arnd Bergmann wrote: > > On Tuesday 17 November 2015 17:12:37 Will Deacon wrote: > > > On Tue, Nov 17, 2015 at 06:03:40PM +0100, Arnd Bergmann wrote: > > > > On Tuesday 17 November 2015 16:44:53 Will

RE: [PATCH] usb: gadget: Add the console support for usb-to-serial port

From: Baolin Wang > Sent: 18 November 2015 10:45 > On 18 November 2015 at 17:32, Andy Shevchenko > wrote: > > On Wed, Nov 18, 2015 at 4:15 AM, Baolin Wang wrote: > >> On 17 November 2015 at 21:34, Andy Shevchenko >

<    1   2   3   4   5   6   7   8   9   10   >