Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

On Thu, Dec 22, 2016 at 05:50:12PM +1100, Dave Chinner wrote: > On Wed, Dec 21, 2016 at 09:46:37PM -0800, Linus Torvalds wrote: > > On Wed, Dec 21, 2016 at 9:13 PM, Dave Chinner wrote: > > > > > > There may be deeper issues. I just started running scalability tests > > >

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

On Thu, Dec 22, 2016 at 05:50:12PM +1100, Dave Chinner wrote: > On Wed, Dec 21, 2016 at 09:46:37PM -0800, Linus Torvalds wrote: > > On Wed, Dec 21, 2016 at 9:13 PM, Dave Chinner wrote: > > > > > > There may be deeper issues. I just started running scalability tests > > > (e.g. 16-way fsmark

Re: [PATCH 11/12] crypto: atmel-authenc: add support to authenc(hmac(shaX),Y(aes)) modes

Hi Cyrille, [auto build test ERROR on cryptodev/master] [also build test ERROR on next-20161222] [cannot apply to v4.9] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Cyrille-Pitchen/crypto

Re: [PATCH 11/12] crypto: atmel-authenc: add support to authenc(hmac(shaX),Y(aes)) modes

Hi Cyrille, [auto build test ERROR on cryptodev/master] [also build test ERROR on next-20161222] [cannot apply to v4.9] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Cyrille-Pitchen/crypto

Re: [PATCH 1/3] NFC: trf7970a: add device tree option for 27MHz clock

On Mon, Dec 19, 2016 at 5:23 PM, Geoff Lansberry wrote: > I can make that change, however, I worry that it may be a bit > misleading, since there are only two supported clock frequencies, but > a number like that to me implies that it could be set to any number > you want. I'm

Re: [PATCH 1/3] NFC: trf7970a: add device tree option for 27MHz clock

On Mon, Dec 19, 2016 at 5:23 PM, Geoff Lansberry wrote: > I can make that change, however, I worry that it may be a bit > misleading, since there are only two supported clock frequencies, but > a number like that to me implies that it could be set to any number > you want. I'm new at this, and

Re: [PATCH] pci: add kernel config option for disabling common PCI quirks

On Thu, Dec 22, 2016 at 06:54:51AM +0100, John Crispin wrote: > On 21/12/2016 15:26, Christoph Hellwig wrote: > > On Wed, Dec 21, 2016 at 02:11:25PM +0100, John Crispin wrote: > >> I can turn it into an enable patch that is selected by default. > >> > >> The current patch disables all those quirks

Re: [PATCH] pci: add kernel config option for disabling common PCI quirks

On Thu, Dec 22, 2016 at 06:54:51AM +0100, John Crispin wrote: > On 21/12/2016 15:26, Christoph Hellwig wrote: > > On Wed, Dec 21, 2016 at 02:11:25PM +0100, John Crispin wrote: > >> I can turn it into an enable patch that is selected by default. > >> > >> The current patch disables all those quirks

Re: [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-type-adjustment" for INCR burst type

On Mon, Dec 19, 2016 at 05:25:53PM +0800, Changming Huang wrote: > New property "snps,incr-burst-type-adjustment = , " for USB3.0 DWC3. > Field "x": 1/0 - undefined length INCR burst type enable or not; > Field "y": INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 burst type. > > While enabling

Re: [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-type-adjustment" for INCR burst type

On Mon, Dec 19, 2016 at 05:25:53PM +0800, Changming Huang wrote: > New property "snps,incr-burst-type-adjustment = , " for USB3.0 DWC3. > Field "x": 1/0 - undefined length INCR burst type enable or not; > Field "y": INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 burst type. > > While enabling

Re: [PATCH v2] fs: exec: apply CLOEXEC before changing dumpable task flags

Aleksa Sarai writes: > If you have a process that has set itself to be non-dumpable, and it > then undergoes exec(2), any CLOEXEC file descriptors it has open are > "exposed" during a race window between the dumpable flags of the process > being reset for exec(2) and CLOEXEC

Re: [PATCH v2] fs: exec: apply CLOEXEC before changing dumpable task flags

Aleksa Sarai writes: > If you have a process that has set itself to be non-dumpable, and it > then undergoes exec(2), any CLOEXEC file descriptors it has open are > "exposed" during a race window between the dumpable flags of the process > being reset for exec(2) and CLOEXEC being applied to the

Re: [alsa-devel] [PATCH v6 1/3] clk: x86: Add Atom PMC platform clocks

On Thu, Dec 22, 2016 at 3:07 AM, Pierre-Louis Bossart wrote: > On 12/21/16 5:05 PM, Stephen Boyd wrote: >>> The name pmc_plt_clk_ follows the data sheet specification, where >>> this convention is suggested: >>> PLT_CLK[2:0] - Camera >>> PLT_CLK[3] -

Re: [PATCH V2 1/2] PM / Domains: Introduce domain-performance-states binding

On Mon, Dec 12, 2016 at 04:26:18PM +0530, Viresh Kumar wrote: > Some platforms have the capability to configure the performance state of > their Power Domains. The performance levels are represented by positive > integer values, a lower value represents lower performance state. > > The

Re: [alsa-devel] [PATCH v6 1/3] clk: x86: Add Atom PMC platform clocks

On Thu, Dec 22, 2016 at 3:07 AM, Pierre-Louis Bossart wrote: > On 12/21/16 5:05 PM, Stephen Boyd wrote: >>> The name pmc_plt_clk_ follows the data sheet specification, where >>> this convention is suggested: >>> PLT_CLK[2:0] - Camera >>> PLT_CLK[3] - Audio Codec >>> PLT_CLK[4] - >>>

Re: [PATCH V2 1/2] PM / Domains: Introduce domain-performance-states binding

On Mon, Dec 12, 2016 at 04:26:18PM +0530, Viresh Kumar wrote: > Some platforms have the capability to configure the performance state of > their Power Domains. The performance levels are represented by positive > integer values, a lower value represents lower performance state. > > The

Re: [PATCH v3 2/2] crypto: mediatek - add DT bindings documentation

On Mon, Dec 19, 2016 at 10:20:45AM +0800, Ryder Lee wrote: > Add DT bindings documentation for the crypto driver > > Signed-off-by: Ryder Lee > --- > .../devicetree/bindings/crypto/mediatek-crypto.txt | 27 > ++ > 1 file changed, 27 insertions(+) >

Re: [PATCH v3 2/2] crypto: mediatek - add DT bindings documentation

On Mon, Dec 19, 2016 at 10:20:45AM +0800, Ryder Lee wrote: > Add DT bindings documentation for the crypto driver > > Signed-off-by: Ryder Lee > --- > .../devicetree/bindings/crypto/mediatek-crypto.txt | 27 > ++ > 1 file changed, 27 insertions(+) > create mode 100644 >

Re: [PATCH 3/3] lib: Update LZ4 compressor module based on LZ4 v1.7.2.

On 12/22/2016 06:31 PM, Greg KH wrote: >On Wed, Dec 21, 2016 at 09:04:02PM +0100, Sven Schmidt wrote: >> On 12/20/2016 08:52 PM, Joe Perches wrote: >> > On Tue, 2016-12-20 at 19:53 +0100, Sven Schmidt wrote: >> >> This patch updates LZ4 kernel module to LZ4 v1.7.2 by Yann Collet. >> >> The kernel

Re: [PATCH 3/3] lib: Update LZ4 compressor module based on LZ4 v1.7.2.

On 12/22/2016 06:31 PM, Greg KH wrote: >On Wed, Dec 21, 2016 at 09:04:02PM +0100, Sven Schmidt wrote: >> On 12/20/2016 08:52 PM, Joe Perches wrote: >> > On Tue, 2016-12-20 at 19:53 +0100, Sven Schmidt wrote: >> >> This patch updates LZ4 kernel module to LZ4 v1.7.2 by Yann Collet. >> >> The kernel

Re: [PATCH v2 2/4] dt-bindings: add bindings for rk3328 clock controller

On Mon, Dec 19, 2016 at 09:56:11AM +0800, Elaine Zhang wrote: > Add devicetree bindings for Rockchip cru which found on > Rockchip SoCs. > > Signed-off-by: Elaine Zhang > --- > .../bindings/clock/rockchip,rk3328-cru.txt | 57 > ++ > 1 file

Re: [PATCH v2 2/4] dt-bindings: add bindings for rk3328 clock controller

On Mon, Dec 19, 2016 at 09:56:11AM +0800, Elaine Zhang wrote: > Add devicetree bindings for Rockchip cru which found on > Rockchip SoCs. > > Signed-off-by: Elaine Zhang > --- > .../bindings/clock/rockchip,rk3328-cru.txt | 57 > ++ > 1 file changed, 57 insertions(+)

Re: [PATCH] dax: kill uml support

On Thu, Dec 22, 2016 at 8:40 AM, Ross Zwisler wrote: > On Thu, Dec 22, 2016 at 11:00:55AM +0100, Jan Kara wrote: >> On Wed 21-12-16 10:51:18, Ross Zwisler wrote: >> > On Wed, Dec 21, 2016 at 09:53:47AM +0100, Jan Kara wrote: >> > > On Tue 20-12-16 17:37:40, Dan

Re: [PATCH] dax: kill uml support

On Thu, Dec 22, 2016 at 8:40 AM, Ross Zwisler wrote: > On Thu, Dec 22, 2016 at 11:00:55AM +0100, Jan Kara wrote: >> On Wed 21-12-16 10:51:18, Ross Zwisler wrote: >> > On Wed, Dec 21, 2016 at 09:53:47AM +0100, Jan Kara wrote: >> > > On Tue 20-12-16 17:37:40, Dan Williams wrote: >> > > > The lack

Re: [PATCH 0/3] Update LZ4 compressor module

On 12/22/2016 06:29 PM, Greg KH wrote: > On Tue, Dec 20, 2016 at 07:53:09PM +0100, Sven Schmidt wrote: >> >> This patchset is for updating the LZ4 compression module to a version based >> on LZ4 v1.7.2 allowing to use the fast compression algorithm aka LZ4 fast >> which provides an "acceleration"

Re: [PATCH 0/3] Update LZ4 compressor module

On 12/22/2016 06:29 PM, Greg KH wrote: > On Tue, Dec 20, 2016 at 07:53:09PM +0100, Sven Schmidt wrote: >> >> This patchset is for updating the LZ4 compression module to a version based >> on LZ4 v1.7.2 allowing to use the fast compression algorithm aka LZ4 fast >> which provides an "acceleration"

Re: [PATCH v3 13/15] livepatch: change to a per-task consistency model

On Thu, Dec 22, 2016 at 03:34:52PM +0100, Petr Mladek wrote: > On Wed 2016-12-21 15:25:05, Josh Poimboeuf wrote: > > On Tue, Dec 20, 2016 at 06:32:46PM +0100, Petr Mladek wrote: > > > On Thu 2016-12-08 12:08:38, Josh Poimboeuf wrote: > > > > Change livepatch to use a basic per-task consistency

Re: [PATCH v3 13/15] livepatch: change to a per-task consistency model

On Thu, Dec 22, 2016 at 03:34:52PM +0100, Petr Mladek wrote: > On Wed 2016-12-21 15:25:05, Josh Poimboeuf wrote: > > On Tue, Dec 20, 2016 at 06:32:46PM +0100, Petr Mladek wrote: > > > On Thu 2016-12-08 12:08:38, Josh Poimboeuf wrote: > > > > Change livepatch to use a basic per-task consistency

Re: [alsa-devel] [PATCH v6 1/3] clk: x86: Add Atom PMC platform clocks

On 12/21/2016 05:07 PM, Pierre-Louis Bossart wrote: > On 12/21/16 5:05 PM, Stephen Boyd wrote: >> >> Ok, by clkdev design if a device is passed but there isn't a >> match in the lookup table it allows it to match based solely on >> the connection id. Given that the connection id is globally >>

Re: [alsa-devel] [PATCH v6 1/3] clk: x86: Add Atom PMC platform clocks

On 12/21/2016 05:07 PM, Pierre-Louis Bossart wrote: > On 12/21/16 5:05 PM, Stephen Boyd wrote: >> >> Ok, by clkdev design if a device is passed but there isn't a >> match in the lookup table it allows it to match based solely on >> the connection id. Given that the connection id is globally >>

Re: "klist" "k" stand for what ?

On 12/21/16 02:23, galcon zhao wrote: > HI ALL: > > I am reading kernel source code ,but I have a question. > > struct klist { > spinlock_t k_lock; > struct list_head k_list; > void (*get)(struct klist_node *); > void (*put)(struct klist_node *); > }

Re: "klist" "k" stand for what ?

On 12/21/16 02:23, galcon zhao wrote: > HI ALL: > > I am reading kernel source code ,but I have a question. > > struct klist { > spinlock_t k_lock; > struct list_head k_list; > void (*get)(struct klist_node *); > void (*put)(struct klist_node *); > }

Re: [PATCH v4 1/3] perf: add PERF_RECORD_NAMESPACES to include namespaces related info

Peter Zijlstra writes: > On Thu, Dec 22, 2016 at 11:19:17PM +1300, Eric W. Biederman wrote: >> Peter Zijlstra writes: >> >> > On Thu, Dec 22, 2016 at 08:21:23PM +1300, Eric W. Biederman wrote: >> >> >> >> And please make the array the last item in

Re: [PATCH v4 1/3] perf: add PERF_RECORD_NAMESPACES to include namespaces related info

Peter Zijlstra writes: > On Thu, Dec 22, 2016 at 11:19:17PM +1300, Eric W. Biederman wrote: >> Peter Zijlstra writes: >> >> > On Thu, Dec 22, 2016 at 08:21:23PM +1300, Eric W. Biederman wrote: >> >> >> >> And please make the array the last item in the structure so that >> >> expanding or

Re: Converting DEVICE_ATTR to DEVICE_ATTR_{RO,RW,WO} and changing function names at the same time

On Thu, Dec 22, 2016 at 04:45:45PM +0100, Julia Lawall wrote: > > > On Thu, 22 Dec 2016, Guenter Roeck wrote: > > > On 12/22/2016 04:29 AM, Julia Lawall wrote: > > > > > > > > > On Wed, 21 Dec 2016, Guenter Roeck wrote: > > > > > > > Hi Julia, > > > > > > > > On Wed, Dec 21, 2016 at 08:39:38PM

Re: Converting DEVICE_ATTR to DEVICE_ATTR_{RO,RW,WO} and changing function names at the same time

On Thu, Dec 22, 2016 at 04:45:45PM +0100, Julia Lawall wrote: > > > On Thu, 22 Dec 2016, Guenter Roeck wrote: > > > On 12/22/2016 04:29 AM, Julia Lawall wrote: > > > > > > > > > On Wed, 21 Dec 2016, Guenter Roeck wrote: > > > > > > > Hi Julia, > > > > > > > > On Wed, Dec 21, 2016 at 08:39:38PM

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, Dec 22, 2016 at 5:59 PM, Hannes Frederic Sowa wrote: > We don't prevent ebpf programs being loaded based on the digest but > just to uniquely identify loaded programs from user space and match up > with their source. Okay, so in that case, a weak hashing

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, Dec 22, 2016 at 5:59 PM, Hannes Frederic Sowa wrote: > We don't prevent ebpf programs being loaded based on the digest but > just to uniquely identify loaded programs from user space and match up > with their source. Okay, so in that case, a weak hashing function like SHA1 could result

Re: [2/3] serial: 8250: Add new port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx

On 12/22/2016 09:21 AM, Franklin S Cooper Jr wrote: On 12/20/2016 02:23 PM, David Lechner wrote: This adds a new UART port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx. These SoCs have standard 8250 registers plus some extra non-standard registers. The UART will not function unless the

Re: [2/3] serial: 8250: Add new port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx

On 12/22/2016 09:21 AM, Franklin S Cooper Jr wrote: On 12/20/2016 02:23 PM, David Lechner wrote: This adds a new UART port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx. These SoCs have standard 8250 registers plus some extra non-standard registers. The UART will not function unless the

Re: [PATCH V2 0/2] PM / Domains / OPP: Introduce domain-performance-state binding

On Mon, Dec 12, 2016 at 04:26:17PM +0530, Viresh Kumar wrote: > Hello, > > Some platforms have the capability to configure the performance state of > their Power Domains. The performance levels are represented by positive > integer values, a lower value represents lower performance state. > > We

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 7:08 PM, Hannes Frederic Sowa wrote: > I wasn't concerned about performance but more about DoS resilience. I > wonder how safe half md4 actually is in terms of allowing users to > generate long hash chains in the filesystem (in terms of length >

Re: [PATCH V2 0/2] PM / Domains / OPP: Introduce domain-performance-state binding

On Mon, Dec 12, 2016 at 04:26:17PM +0530, Viresh Kumar wrote: > Hello, > > Some platforms have the capability to configure the performance state of > their Power Domains. The performance levels are represented by positive > integer values, a lower value represents lower performance state. > > We

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 7:08 PM, Hannes Frederic Sowa wrote: > I wasn't concerned about performance but more about DoS resilience. I > wonder how safe half md4 actually is in terms of allowing users to > generate long hash chains in the filesystem (in terms of length > extension attacks against

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On 22.12.2016 16:54, Theodore Ts'o wrote: > On Thu, Dec 22, 2016 at 02:10:33PM +0100, Jason A. Donenfeld wrote: >> On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa >> wrote: >>> following up on what appears to be a random subject: ;) >>> >>> IIRC, ext4 code by

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On 22.12.2016 16:54, Theodore Ts'o wrote: > On Thu, Dec 22, 2016 at 02:10:33PM +0100, Jason A. Donenfeld wrote: >> On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa >> wrote: >>> following up on what appears to be a random subject: ;) >>> >>> IIRC, ext4 code by default still uses half_md4 for

[PATCH 2/2] random: convert get_random_int/long into get_random_u32/u64

Many times, when a user wants a random number, he wants a random number of a guaranteed size. So, thinking of get_random_int and get_random_long in terms of get_random_u32 and get_random_u64 makes it much easier to achieve this. It also makes the code simpler. On 32-bit platforms, get_random_int

[PATCH 1/2] random: use chacha20 for get_random_int/long

Now that our crng uses chacha20, we can rely on its speedy characteristics for replacing MD5, while simultaneously achieving a higher security guarantee. Before the idea was to use these functions if you wanted random integers that aren't stupidly insecure but aren't necessarily secure either, a

[PATCH 2/2] random: convert get_random_int/long into get_random_u32/u64

Many times, when a user wants a random number, he wants a random number of a guaranteed size. So, thinking of get_random_int and get_random_long in terms of get_random_u32 and get_random_u64 makes it much easier to achieve this. It also makes the code simpler. On 32-bit platforms, get_random_int

[PATCH 1/2] random: use chacha20 for get_random_int/long

Now that our crng uses chacha20, we can rely on its speedy characteristics for replacing MD5, while simultaneously achieving a higher security guarantee. Before the idea was to use these functions if you wanted random integers that aren't stupidly insecure but aren't necessarily secure either, a

Re: [PATCH v4 0/2] power: supply: add sbs-charger driver

Hi, On Tue, Dec 20, 2016 at 04:31:12PM +0100, Nicolas Saenz Julienne wrote: > This series adds support for all SBS compatible battery chargers, as defined > here: http://sbs-forum.org/specs/sbc110.pdf. > > [...] > > Nicolas Saenz Julienne (2): > power: supply: add sbs-charger driver >

Re: [PATCH v4 0/2] power: supply: add sbs-charger driver

Hi, On Tue, Dec 20, 2016 at 04:31:12PM +0100, Nicolas Saenz Julienne wrote: > This series adds support for all SBS compatible battery chargers, as defined > here: http://sbs-forum.org/specs/sbc110.pdf. > > [...] > > Nicolas Saenz Julienne (2): > power: supply: add sbs-charger driver >

Re: [patch 00/10] cpu/hotplug: Final cleanup

Hi Thomas. On Wed, Dec 21, 2016 at 08:19:47PM +0100, Thomas Gleixner wrote: > The following series completes the cpuhotplug rework stage ONE. Just curious - what is the stage TWO (and onwards) plan? lwn had some coverage of this work but I assume the article is somewhat outdated. Sam

Re: [patch 00/10] cpu/hotplug: Final cleanup

Hi Thomas. On Wed, Dec 21, 2016 at 08:19:47PM +0100, Thomas Gleixner wrote: > The following series completes the cpuhotplug rework stage ONE. Just curious - what is the stage TWO (and onwards) plan? lwn had some coverage of this work but I assume the article is somewhat outdated. Sam

Re: [PATCH net-next] ixgbevf: fix 'Etherleak' in ixgbevf

Yes that is much more helpful. So looking at it things are being padded but the last 4 bytes always have this extra data in them. I've been trying to recreate the issue on an 82599 with an SR-IOV VF and I haven't been having much luck reproducing the problem. In your test environment is the

Re: [PATCH net-next] ixgbevf: fix 'Etherleak' in ixgbevf

Yes that is much more helpful. So looking at it things are being padded but the last 4 bytes always have this extra data in them. I've been trying to recreate the issue on an 82599 with an SR-IOV VF and I haven't been having much luck reproducing the problem. In your test environment is the

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, 2016-12-22 at 09:25 -0800, Andy Lutomirski wrote: > On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa > wrote: > > On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote: > > > > > > You mean: > > > > > > commit 7bd509e311f408f7a5132fcdde2069af65fa05ae

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, 2016-12-22 at 09:25 -0800, Andy Lutomirski wrote: > On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa > wrote: > > On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote: > > > > > > You mean: > > > > > > commit 7bd509e311f408f7a5132fcdde2069af65fa05ae > > > Author: Daniel

Re: [PATCHSET v4] blk-mq-scheduling framework

On Thu, 2016-12-22 at 09:12 -0800, Omar Sandoval wrote: > On Thu, Dec 22, 2016 at 04:57:36PM +, Bart Van Assche wrote: > > On Thu, 2016-12-22 at 08:52 -0800, Omar Sandoval wrote: > > > This approach occurred to us, but we couldn't figure out a way to make > > > blk_mq_tag_to_rq() work with it.

Re: [PATCHSET v4] blk-mq-scheduling framework

On Thu, 2016-12-22 at 09:12 -0800, Omar Sandoval wrote: > On Thu, Dec 22, 2016 at 04:57:36PM +, Bart Van Assche wrote: > > On Thu, 2016-12-22 at 08:52 -0800, Omar Sandoval wrote: > > > This approach occurred to us, but we couldn't figure out a way to make > > > blk_mq_tag_to_rq() work with it.

[GIT PULL] LED maintainer's email update

Hi Linus, Please pull a single patch that advertises a change of my email address. This pull request is based on my previous one that has been already merged. The following changes since commit

[GIT PULL] LED maintainer's email update

Hi Linus, Please pull a single patch that advertises a change of my email address. This pull request is based on my previous one that has been already merged. The following changes since commit

Re: Converting DEVICE_ATTR to DEVICE_ATTR_{RO,RW,WO} and changing function names at the same time

On Thu, Dec 22, 2016 at 04:45:45PM +0100, Julia Lawall wrote: > > > On Thu, 22 Dec 2016, Guenter Roeck wrote: > > > On 12/22/2016 04:29 AM, Julia Lawall wrote: > > > > > > > > > On Wed, 21 Dec 2016, Guenter Roeck wrote: > > > > > > > Hi Julia, > > > > > > > > On Wed, Dec 21, 2016 at 08:39:38PM

Re: Converting DEVICE_ATTR to DEVICE_ATTR_{RO,RW,WO} and changing function names at the same time

On Thu, Dec 22, 2016 at 04:45:45PM +0100, Julia Lawall wrote: > > > On Thu, 22 Dec 2016, Guenter Roeck wrote: > > > On 12/22/2016 04:29 AM, Julia Lawall wrote: > > > > > > > > > On Wed, 21 Dec 2016, Guenter Roeck wrote: > > > > > > > Hi Julia, > > > > > > > > On Wed, Dec 21, 2016 at 08:39:38PM

Assalamu`Alaikum.

Dear Sir/Madam. Assalamu`Alaikum. I am Dr mohammad ouattara, I have ($10.6 Million us dollars) to transfer into your account, I will send you more details about this deal and the procedures to follow when I receive a positive response from you, Have a great day, Dr mohammad ouattara.

Re: [PATCH 3/3] lib: Update LZ4 compressor module based on LZ4 v1.7.2.

On Wed, Dec 21, 2016 at 09:04:02PM +0100, Sven Schmidt wrote: > On 12/20/2016 08:52 PM, Joe Perches wrote: > > On Tue, 2016-12-20 at 19:53 +0100, Sven Schmidt wrote: > >> This patch updates LZ4 kernel module to LZ4 v1.7.2 by Yann Collet. > >> The kernel module is inspired by the previous work by

Assalamu`Alaikum.

Dear Sir/Madam. Assalamu`Alaikum. I am Dr mohammad ouattara, I have ($10.6 Million us dollars) to transfer into your account, I will send you more details about this deal and the procedures to follow when I receive a positive response from you, Have a great day, Dr mohammad ouattara.

Re: [PATCH 3/3] lib: Update LZ4 compressor module based on LZ4 v1.7.2.

On Wed, Dec 21, 2016 at 09:04:02PM +0100, Sven Schmidt wrote: > On 12/20/2016 08:52 PM, Joe Perches wrote: > > On Tue, 2016-12-20 at 19:53 +0100, Sven Schmidt wrote: > >> This patch updates LZ4 kernel module to LZ4 v1.7.2 by Yann Collet. > >> The kernel module is inspired by the previous work by

Re: [PATCH 0/3] Update LZ4 compressor module

On Tue, Dec 20, 2016 at 07:53:09PM +0100, Sven Schmidt wrote: > > This patchset is for updating the LZ4 compression module to a version based > on LZ4 v1.7.2 allowing to use the fast compression algorithm aka LZ4 fast > which provides an "acceleration" parameter as a tradeoff between >

Re: [PATCH 0/3] Update LZ4 compressor module

On Tue, Dec 20, 2016 at 07:53:09PM +0100, Sven Schmidt wrote: > > This patchset is for updating the LZ4 compression module to a version based > on LZ4 v1.7.2 allowing to use the fast compression algorithm aka LZ4 fast > which provides an "acceleration" parameter as a tradeoff between >

[PATCH 9/8] cgroup: fix RCU related sparse warnings

>From 9ca76e7e3cb885bc5701e9b1fe90c44f4aef123a Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Thu, 22 Dec 2016 12:28:01 -0500 kn->priv which is a void * is used as a RCU pointer by cgroup. When dereferencing it, it was passing kn->priv to rcu_derefreence() without casting it

[PATCH 9/8] cgroup: fix RCU related sparse warnings

>From 9ca76e7e3cb885bc5701e9b1fe90c44f4aef123a Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Thu, 22 Dec 2016 12:28:01 -0500 kn->priv which is a void * is used as a RCU pointer by cgroup. When dereferencing it, it was passing kn->priv to rcu_derefreence() without casting it into a RCU pointer

Re: [PATCH v2 REGRESSION RESEND] usb: ohci-at91: use descriptor-based gpio APIs correctly

On Thu, Dec 22, 2016 at 08:43:55AM +0100, Peter Rosin wrote: > The gpiod_get* function family does not want the -gpio suffix. > Use devm_gpiod_get_index_optional instead of devm_gpiod_get_optional. > The descriptor based APIs handle active high/low automatically. > The vbus-gpios are output,

Re: [PATCH v2 REGRESSION RESEND] usb: ohci-at91: use descriptor-based gpio APIs correctly

On Thu, Dec 22, 2016 at 08:43:55AM +0100, Peter Rosin wrote: > The gpiod_get* function family does not want the -gpio suffix. > Use devm_gpiod_get_index_optional instead of devm_gpiod_get_optional. > The descriptor based APIs handle active high/low automatically. > The vbus-gpios are output,

[PATCH] MAINTAINERS: Update Jacek Anaszewski's email address

My previous email address is no longer valid. >From now on, jacek.anaszew...@gmail.com should be used instead. Signed-off-by: Jacek Anaszewski --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index

[PATCH] MAINTAINERS: Update Jacek Anaszewski's email address

My previous email address is no longer valid. >From now on, jacek.anaszew...@gmail.com should be used instead. Signed-off-by: Jacek Anaszewski --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1cd38a7..b61650d 100644 ---

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa wrote: > On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote: >> On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa >> wrote: >> > On Thu, 2016-12-22 at 16:41 +0100, Jason A.

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa wrote: > On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote: >> On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa >> wrote: >> > On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote: >> > > Hi Hannes, >> > > >> > > On Thu,

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

On Wed, Dec 21, 2016 at 10:28 PM, Dave Chinner wrote: > > This sort of thing is normally indicative of a memory reclaim or > lock contention problem. Profile showed unusual spinlock contention, > but then I realised there was only one kswapd thread running. > Yup, sure

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

On Wed, Dec 21, 2016 at 10:28 PM, Dave Chinner wrote: > > This sort of thing is normally indicative of a memory reclaim or > lock contention problem. Profile showed unusual spinlock contention, > but then I realised there was only one kswapd thread running. > Yup, sure enough, it's caused by a

[PATCH v2] ARM64: zynqmp: Fix i2c node's compatible string

From: Moritz Fischer The Zynq Ultrascale MP uses version 1.4 of the Cadence IP core which fixes some silicon bugs that needed software workarounds in Version 1.0 that was used on Zynq systems. Signed-off-by: Moritz Fischer Cc: Michal Simek

[PATCH v2] ARM64: zynqmp: Fix i2c node's compatible string

From: Moritz Fischer The Zynq Ultrascale MP uses version 1.4 of the Cadence IP core which fixes some silicon bugs that needed software workarounds in Version 1.0 that was used on Zynq systems. Signed-off-by: Moritz Fischer Cc: Michal Simek Cc: Sören Brinkmann Cc: Rob Herring --- Changes

Re: [PATCH 2/2] HID: intel-ish-hid: format 32-bit integers with %X

On Thu, 2016-12-22 at 11:09 +0100, Nicolas Iooss wrote: > In ishtp_hid_probe(), use %04X instead of %04hX to format __u32 > values, > in order to silent a format error reported by clang: > > drivers/hid/intel-ish-hid/ishtp-hid.c:212:3: error: format > specifies > type 'unsigned short' but

Re: [PATCH 2/2] HID: intel-ish-hid: format 32-bit integers with %X

On Thu, 2016-12-22 at 11:09 +0100, Nicolas Iooss wrote: > In ishtp_hid_probe(), use %04X instead of %04hX to format __u32 > values, > in order to silent a format error reported by clang: > > drivers/hid/intel-ish-hid/ishtp-hid.c:212:3: error: format > specifies > type 'unsigned short' but

Re: [PATCH 1/2] HID: intel-ish-hid: add printf attribute to print_log()

On Thu, 2016-12-22 at 11:09 +0100, Nicolas Iooss wrote: > Structure ishtp_device contains a logging function, print_log(), > which > formats some of its parameters using vsnprintf(). Add a __printf > attribute to this function field (and to ish_event_tracer()) in order > to > detect at compile

Re: [PATCH 1/2] HID: intel-ish-hid: add printf attribute to print_log()

On Thu, 2016-12-22 at 11:09 +0100, Nicolas Iooss wrote: > Structure ishtp_device contains a logging function, print_log(), > which > formats some of its parameters using vsnprintf(). Add a __printf > attribute to this function field (and to ish_event_tracer()) in order > to > detect at compile

Re: [v1] misc: cb710: core:- Handle return NULL error from pcim_iomap_table

Ignore this change. Sorry for the noise. Thanks Arvind On Thursday 22 December 2016 05:28 PM, Arvind Yadav wrote: Here, If pcim_iomap_table will fail. It will return NULL. Kernel can run into a NULL-pointer dereference. This error check will avoid NULL pointer dereference. Signed-off-by:

Re: [v1] misc: cb710: core:- Handle return NULL error from pcim_iomap_table

Ignore this change. Sorry for the noise. Thanks Arvind On Thursday 22 December 2016 05:28 PM, Arvind Yadav wrote: Here, If pcim_iomap_table will fail. It will return NULL. Kernel can run into a NULL-pointer dereference. This error check will avoid NULL pointer dereference. Signed-off-by:

Re: [v1] mmc: host: dw_mmc-pci:- Handle return NULL error from pcim_iomap_table

Ignore this change. Sorry for noise. Thanks -Arvind On Thursday 22 December 2016 05:36 PM, Arvind Yadav wrote: Here, If pcim_iomap_table will fail. It will return NULL. Kernel can run into a NULL-pointer dereference. This error check will avoid NULL pointer dereference. Signed-off-by: Arvind

Re: [v1] mmc: host: dw_mmc-pci:- Handle return NULL error from pcim_iomap_table

Ignore this change. Sorry for noise. Thanks -Arvind On Thursday 22 December 2016 05:36 PM, Arvind Yadav wrote: Here, If pcim_iomap_table will fail. It will return NULL. Kernel can run into a NULL-pointer dereference. This error check will avoid NULL pointer dereference. Signed-off-by: Arvind

Re: [PATCHSET v4] blk-mq-scheduling framework

On Thu, Dec 22, 2016 at 04:57:36PM +, Bart Van Assche wrote: > On Thu, 2016-12-22 at 08:52 -0800, Omar Sandoval wrote: > > This approach occurred to us, but we couldn't figure out a way to make > > blk_mq_tag_to_rq() work with it. From skimming over the patches, I > > didn't see a solution to

Re: [PATCHSET v4] blk-mq-scheduling framework

On Thu, Dec 22, 2016 at 04:57:36PM +, Bart Van Assche wrote: > On Thu, 2016-12-22 at 08:52 -0800, Omar Sandoval wrote: > > This approach occurred to us, but we couldn't figure out a way to make > > blk_mq_tag_to_rq() work with it. From skimming over the patches, I > > didn't see a solution to

Re: [v1] i2c: busses: i2c-designware-pcidrv:- Handle return NULL error from pcim_iomap_table

Yes, It will not fail. Sorry for the noise. Thanks -Arvind On Thursday 22 December 2016 08:05 PM, Andy Shevchenko wrote: On Thu, 2016-12-22 at 17:09 +0530, Arvind Yadav wrote: Here, If pcim_iomap_table will fail. It will return NULL. Kernel can run into a NULL-pointer dereference. This error

Re: [v1] i2c: busses: i2c-designware-pcidrv:- Handle return NULL error from pcim_iomap_table

Yes, It will not fail. Sorry for the noise. Thanks -Arvind On Thursday 22 December 2016 08:05 PM, Andy Shevchenko wrote: On Thu, 2016-12-22 at 17:09 +0530, Arvind Yadav wrote: Here, If pcim_iomap_table will fail. It will return NULL. Kernel can run into a NULL-pointer dereference. This error

Re: [PATCHv6 6/7] printk: use printk_safe buffers in printk

On Thu 2016-12-22 14:31:19, Sergey Senozhatsky wrote: > Hello, > > On (12/21/16 23:36), Sergey Senozhatsky wrote: > > Use printk_safe per-CPU buffers in printk recursion-prone blocks: > > -- around logbuf_lock protected sections in vprintk_emit() and > >console_unlock() > > -- around

Re: [PATCHv6 6/7] printk: use printk_safe buffers in printk

On Thu 2016-12-22 14:31:19, Sergey Senozhatsky wrote: > Hello, > > On (12/21/16 23:36), Sergey Senozhatsky wrote: > > Use printk_safe per-CPU buffers in printk recursion-prone blocks: > > -- around logbuf_lock protected sections in vprintk_emit() and > >console_unlock() > > -- around

Re: [PATCH v2] stmmac: CSR clock configuration fix

Às 4:57 PM de 12/22/2016, Phil Reid escreveu: > On 22/12/2016 23:47, Joao Pinto wrote: >> >> Hello Phil, >> >> Às 3:42 PM de 12/22/2016, Phil Reid escreveu: >>> G'day Joao, >>> >>> On 22/12/2016 20:38, Joao Pinto wrote: When testing stmmac with my QoS reference design I checked a problem in

Re: [PATCH v2] stmmac: CSR clock configuration fix

Às 4:57 PM de 12/22/2016, Phil Reid escreveu: > On 22/12/2016 23:47, Joao Pinto wrote: >> >> Hello Phil, >> >> Às 3:42 PM de 12/22/2016, Phil Reid escreveu: >>> G'day Joao, >>> >>> On 22/12/2016 20:38, Joao Pinto wrote: When testing stmmac with my QoS reference design I checked a problem in

[PATCH 0/2] sched: Introduce rcuwait

Hi, Here's an updated version of the pcpu rwsem writer wait/wake changes with the abstractions wanted by Oleg. Patch 1 adds rcuwait (for a lack of better name), and patch 2 trivially makes use of it. Has survived torture testing, which is actually very handy in this case particularly dealing

[PATCH] staging: rtl8188eu: In core directory, fixed 'missing a balnk line after declarations' warnings.

Fixed checkpatch.pl warnings in rtl8188eu/core directory. Signed-off-by: Yamanappagouda Patil --- drivers/staging/rtl8188eu/core/rtw_efuse.c | 4 drivers/staging/rtl8188eu/core/rtw_ieee80211.c | 5 - drivers/staging/rtl8188eu/core/rtw_led.c | 1 +

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