[PATCH 00/11] drm/vc4: DSI panel support + Raspberry Pi touchscreen

After 9 months of development, I finally got the DSI panel to light up from poweron, and this is the series for enabling it. I've included the whole thing Cced to all the subsystems, as there are some interesting choices we have to make (how the analog PHY clocks are represented in common clocks¸

[PATCH 04/11] drm/vc4: Set up SCALER_DISPCTRL at boot.

We want the HVS on, obviously, and we also want DSP3 (PV1's source) to be muxed from HVS channel 2 like we expect in vc4_crtc.c. The firmware wasn't setting the DSP3 mux up when both the LCD and HDMI were disabled. Signed-off-by: Eric Anholt --- drivers/gpu/drm/vc4/vc4_hvs.c

[PATCH 00/11] drm/vc4: DSI panel support + Raspberry Pi touchscreen

After 9 months of development, I finally got the DSI panel to light up from poweron, and this is the series for enabling it. I've included the whole thing Cced to all the subsystems, as there are some interesting choices we have to make (how the analog PHY clocks are represented in common clocks¸

[PATCH 04/11] drm/vc4: Set up SCALER_DISPCTRL at boot.

We want the HVS on, obviously, and we also want DSP3 (PV1's source) to be muxed from HVS channel 2 like we expect in vc4_crtc.c. The firmware wasn't setting the DSP3 mux up when both the LCD and HDMI were disabled. Signed-off-by: Eric Anholt --- drivers/gpu/drm/vc4/vc4_hvs.c | 14

Re: [PATCH 1/1] infiniband: hw: cxgb4: set errno on failure

On 12/3/2016 8:04 AM, Pan Bian wrote: > From: Pan Bian > > In function c4iw_rdev_open(), the value of return variable err should be > negative on errors. However, when the call to __get_free_page() returns > a NULL pointer, its value is not set to "-ENOMEM" and keeps 0. 0

Re: [PATCH 1/1] infiniband: hw: cxgb4: set errno on failure

On 12/3/2016 8:04 AM, Pan Bian wrote: > From: Pan Bian > > In function c4iw_rdev_open(), the value of return variable err should be > negative on errors. However, when the call to __get_free_page() returns > a NULL pointer, its value is not set to "-ENOMEM" and keeps 0. 0 means > no error. And

[PATCH] vfio-mdev: Fix mtty sample driver building

This sample driver was originally under Documentation/ and was moved to samples, but build support was never adjusted for the new location. Signed-off-by: Alex Williamson --- samples/Kconfig|7 +++ samples/Makefile |3 ++-

[PATCH] vfio-mdev: Fix mtty sample driver building

This sample driver was originally under Documentation/ and was moved to samples, but build support was never adjusted for the new location. Signed-off-by: Alex Williamson --- samples/Kconfig|7 +++ samples/Makefile |3 ++- samples/vfio-mdev/Makefile | 14

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

Hi Hannes, On Wed, Dec 14, 2016 at 8:22 PM, Hannes Frederic Sowa wrote: > I don't think this helps. Did you test it? I don't see reason why > padding could be left out between `d' and `end' because of the flexible > array member? Because the type u8 doesn't require

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

Hi Hannes, On Wed, Dec 14, 2016 at 8:22 PM, Hannes Frederic Sowa wrote: > I don't think this helps. Did you test it? I don't see reason why > padding could be left out between `d' and `end' because of the flexible > array member? Because the type u8 doesn't require any alignment requirements,

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

Hi Tom, On Wed, Dec 14, 2016 at 8:18 PM, Tom Herbert wrote: > "super fast" is relative. My quick test shows that this faster than > Toeplitz (good, but not exactly hard to achieve), but is about 4x > slower than jhash. Fast relative to other cryptographically secure PRFs.

Re: [PATCH 1/1] infiniband: hw: mlx4: fix improper return value

On 12/4/2016 1:45 AM, Pan Bian wrote: > From: Pan Bian > > If uhw->inlen is non-zero, the value of variable err is 0 if the copy > succeeds. Then, if kzalloc() or kmalloc() returns a NULL pointer, it > will return 0 to the callers. As a result, the callers cannot detect the

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

Hi Tom, On Wed, Dec 14, 2016 at 8:18 PM, Tom Herbert wrote: > "super fast" is relative. My quick test shows that this faster than > Toeplitz (good, but not exactly hard to achieve), but is about 4x > slower than jhash. Fast relative to other cryptographically secure PRFs. >> SipHash isn't just

Re: [PATCH 1/1] infiniband: hw: mlx4: fix improper return value

On 12/4/2016 1:45 AM, Pan Bian wrote: > From: Pan Bian > > If uhw->inlen is non-zero, the value of variable err is 0 if the copy > succeeds. Then, if kzalloc() or kmalloc() returns a NULL pointer, it > will return 0 to the callers. As a result, the callers cannot detect the > errors. This patch

Re: [PATCH 1/1] infiniband: hw: ocrdma: fix bad initialization

On 12/4/2016 1:20 AM, Leon Romanovsky wrote: > On Sat, Dec 03, 2016 at 09:10:21PM +0800, Pan Bian wrote: >> From: Pan Bian >> >> In function ocrdma_mbx_create_ah_tbl(), returns the value of status on >> errors. However, because status is initialized with 0, 0 will be >>

Re: [PATCH 1/1] infiniband: hw: ocrdma: fix bad initialization

On 12/4/2016 1:20 AM, Leon Romanovsky wrote: > On Sat, Dec 03, 2016 at 09:10:21PM +0800, Pan Bian wrote: >> From: Pan Bian >> >> In function ocrdma_mbx_create_ah_tbl(), returns the value of status on >> errors. However, because status is initialized with 0, 0 will be >> returned even if on error

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

>> I have found two solutions: > > No we already have algif_rng so let's not confuse things even > further by making hwrng take PRNGs. Even if both the solutions could not be adopted I think there must be a way for applications to use similar API to get true rng or prng. Given the case that no

Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG

>> I have found two solutions: > > No we already have algif_rng so let's not confuse things even > further by making hwrng take PRNGs. Even if both the solutions could not be adopted I think there must be a way for applications to use similar API to get true rng or prng. Given the case that no

Re: [PATCH 1/1] infiniband: nes: return value of skb_linearize should be handled

On 12/7/2016 2:30 AM, Zhouyi Zhou wrote: > Return value of skb_linearize should be handled in function > nes_netdev_start_xmit. > > Compiled in x86_64 > Signed-off-by: Zhouyi Zhou > Reviewed-by: Yuval Shaia > Reviewed-by: Eric Dumazet

Re: [PATCH 1/1] infiniband: nes: return value of skb_linearize should be handled

On 12/7/2016 2:30 AM, Zhouyi Zhou wrote: > Return value of skb_linearize should be handled in function > nes_netdev_start_xmit. > > Compiled in x86_64 > Signed-off-by: Zhouyi Zhou > Reviewed-by: Yuval Shaia > Reviewed-by: Eric Dumazet Applied, thanks. -- Doug Ledford GPG Key ID:

[PATCH] usb: musb: debugfs: allow forcing host mode together with speed in testmode

Based on the musb ug, force_host bit is allowed to be set along with force_hs or force_fs bit. It could help to implement forced host mode via testmode on Nokia N900. Signed-off-by: Pali Rohár --- drivers/usb/musb/musb_debugfs.c | 44

Re: [tip:x86/urgent] x86/boot/64: Use 'push' instead of 'call' in start_cpu()

On December 14, 2016 12:36:58 AM PST, tip-bot for Josh Poimboeuf wrote: >Commit-ID: ec2d86a9b646d93f1948569f368e2c6f5449e6c7 >Gitweb: >http://git.kernel.org/tip/ec2d86a9b646d93f1948569f368e2c6f5449e6c7 >Author: Josh Poimboeuf >AuthorDate: Tue, 13

[PATCH] usb: musb: debugfs: allow forcing host mode together with speed in testmode

Based on the musb ug, force_host bit is allowed to be set along with force_hs or force_fs bit. It could help to implement forced host mode via testmode on Nokia N900. Signed-off-by: Pali Rohár --- drivers/usb/musb/musb_debugfs.c | 44 +-- 1 file changed,

Re: [tip:x86/urgent] x86/boot/64: Use 'push' instead of 'call' in start_cpu()

On December 14, 2016 12:36:58 AM PST, tip-bot for Josh Poimboeuf wrote: >Commit-ID: ec2d86a9b646d93f1948569f368e2c6f5449e6c7 >Gitweb: >http://git.kernel.org/tip/ec2d86a9b646d93f1948569f368e2c6f5449e6c7 >Author: Josh Poimboeuf >AuthorDate: Tue, 13 Dec 2016 21:25:35 -0600 >Committer:

Re: [kernel-hardening] [RFC 0/4] make call_usermodehelper a bit more "safe"

Hi, On Wed, Dec 14, 2016 at 10:50:00AM -0800, Greg KH wrote: > The issue is that if you end up getting write access to kernel memory, > if you change the string '/sbin/hotplug' to point to > '/home/hacked/my_binary', then the next uevent that the system makes > will call this binary instead of

Re: [kernel-hardening] [RFC 0/4] make call_usermodehelper a bit more "safe"

Hi, On Wed, Dec 14, 2016 at 10:50:00AM -0800, Greg KH wrote: > The issue is that if you end up getting write access to kernel memory, > if you change the string '/sbin/hotplug' to point to > '/home/hacked/my_binary', then the next uevent that the system makes > will call this binary instead of

Re: [PATCH v2 01/46] mtdpart: Propagate _get/put_device()

On Wed, Sep 28, 2016 at 8:16 PM, Brian Norris wrote: > On Wed, Sep 21, 2016 at 12:15:31PM +0200, Boris Brezillon wrote: >> On Wed, 21 Sep 2016 11:43:56 +0200 >> Daniel Walter wrote: >> >> > From: Richard Weinberger >> > >> > If

Re: [PATCH v2 01/46] mtdpart: Propagate _get/put_device()

On Wed, Sep 28, 2016 at 8:16 PM, Brian Norris wrote: > On Wed, Sep 21, 2016 at 12:15:31PM +0200, Boris Brezillon wrote: >> On Wed, 21 Sep 2016 11:43:56 +0200 >> Daniel Walter wrote: >> >> > From: Richard Weinberger >> > >> > If the master device has callbacks for _get/put_device() >> > and this

Re: [PATCH] IB/core: fix unmap_sg argument

On 12/2/2016 8:45 AM, Sebastian Ott wrote: > __ib_umem_release calls dma_unmap_sg with a different number of > sg_entries than ib_umem_get uses for dma_map_sg. This might cause > trouble for implementations that merge sglist entries and results > in the following dma debug complaint: > >

Re: [PATCH] IB/core: fix unmap_sg argument

On 12/2/2016 8:45 AM, Sebastian Ott wrote: > __ib_umem_release calls dma_unmap_sg with a different number of > sg_entries than ib_umem_get uses for dma_map_sg. This might cause > trouble for implementations that merge sglist entries and results > in the following dma debug complaint: > >

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

On 14.12.2016 19:06, Jason A. Donenfeld wrote: > Hi David, > > On Wed, Dec 14, 2016 at 6:56 PM, David Miller wrote: >> Just marking the structure __packed, whether necessary or not, makes >> the compiler assume that the members are not aligned and causes >> byte-by-byte

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

On 14.12.2016 19:06, Jason A. Donenfeld wrote: > Hi David, > > On Wed, Dec 14, 2016 at 6:56 PM, David Miller wrote: >> Just marking the structure __packed, whether necessary or not, makes >> the compiler assume that the members are not aligned and causes >> byte-by-byte accesses to be performed

RE: [PATCH] perf tools: ignore zombie process for user profile

. > Em Wed, Dec 14, 2016 at 06:26:02PM +, Liang, Kan escreveu: > > > On Wed, Dec 14, 2016 at 12:48:05PM -0500, kan.li...@intel.com wrote: > > > > From: Kan Liang Zombie process is dead > > > > process. It is meaningless to profile it. > > > > It's better to ignore it

RE: [PATCH] perf tools: ignore zombie process for user profile

. > Em Wed, Dec 14, 2016 at 06:26:02PM +, Liang, Kan escreveu: > > > On Wed, Dec 14, 2016 at 12:48:05PM -0500, kan.li...@intel.com wrote: > > > > From: Kan Liang Zombie process is dead > > > > process. It is meaningless to profile it. > > > > It's better to ignore it for user profile. > >

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

On Wed, Dec 14, 2016 at 10:46 AM, Jason A. Donenfeld wrote: > SipHash is a 64-bit keyed hash function that is actually a > cryptographically secure PRF, like HMAC. Except SipHash is super fast, > and is meant to be used as a hashtable keyed lookup function. > "super fast" is

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

On Wed, Dec 14, 2016 at 10:46 AM, Jason A. Donenfeld wrote: > SipHash is a 64-bit keyed hash function that is actually a > cryptographically secure PRF, like HMAC. Except SipHash is super fast, > and is meant to be used as a hashtable keyed lookup function. > "super fast" is relative. My quick

Re: [f2fs-dev] [GIT PULL] f2fs update for 4.10

On 12/14, Jaegeuk Kim wrote: > On 12/14, Linus Torvalds wrote: > > On Mon, Dec 12, 2016 at 2:15 PM, Jaegeuk Kim wrote: > > > > > > Could you please consider this pull request? > > > > Pulled. Mind double-checking my resolution wrt commit 70fd76140a6c > > ("block,fs: use REQ_*

Re: [f2fs-dev] [GIT PULL] f2fs update for 4.10

On 12/14, Jaegeuk Kim wrote: > On 12/14, Linus Torvalds wrote: > > On Mon, Dec 12, 2016 at 2:15 PM, Jaegeuk Kim wrote: > > > > > > Could you please consider this pull request? > > > > Pulled. Mind double-checking my resolution wrt commit 70fd76140a6c > > ("block,fs: use REQ_* flags directly")? >

RE: [PATCH v3 2/2] FPGA: Add TS-7300 FPGA manager

On Wednesday, December 14, 2016 11:55 AM, Florian Fainelli wrote: > My understanding is that, yes, this triggers the final write. You are > right that ts73xx_fpga_write() can be called multiple times. It sounds > like what my write_complete function does right now is just return that > we

RE: [PATCH v3 2/2] FPGA: Add TS-7300 FPGA manager

On Wednesday, December 14, 2016 11:55 AM, Florian Fainelli wrote: > My understanding is that, yes, this triggers the final write. You are > right that ts73xx_fpga_write() can be called multiple times. It sounds > like what my write_complete function does right now is just return that > we

Re: [PATCH] perf tools: ignore zombie process for user profile

Em Wed, Dec 14, 2016 at 06:26:02PM +, Liang, Kan escreveu: > > On Wed, Dec 14, 2016 at 12:48:05PM -0500, kan.li...@intel.com wrote: > > > From: Kan Liang > > > Zombie process is dead process. It is meaningless to profile it. > > > It's better to ignore it for user

Re: [PATCH] perf tools: ignore zombie process for user profile

Em Wed, Dec 14, 2016 at 06:26:02PM +, Liang, Kan escreveu: > > On Wed, Dec 14, 2016 at 12:48:05PM -0500, kan.li...@intel.com wrote: > > > From: Kan Liang > > > Zombie process is dead process. It is meaningless to profile it. > > > It's better to ignore it for user profile. > > I recently

Re: [kernel-hardening] Re: [PATCH 4/3] random: use siphash24 instead of md5 for get_random_int/long

Hi again, On Wed, Dec 14, 2016 at 5:37 PM, Theodore Ts'o wrote: > [3.606139] random benchmark!! > [3.606276] get_random_int # cycles: 326578 > [3.606317] get_random_int_new # cycles: 95438 > [3.607423] get_random_bytes # cycles: 2653388 Looks to me like my siphash

Re: [kernel-hardening] Re: [PATCH 4/3] random: use siphash24 instead of md5 for get_random_int/long

Hi again, On Wed, Dec 14, 2016 at 5:37 PM, Theodore Ts'o wrote: > [3.606139] random benchmark!! > [3.606276] get_random_int # cycles: 326578 > [3.606317] get_random_int_new # cycles: 95438 > [3.607423] get_random_bytes # cycles: 2653388 Looks to me like my siphash implementation

Re: [kernel-hardening] [PATCH 3/4] Make static usermode helper binaries constant

On Wed, Dec 14, 2016 at 10:50:52AM -0800, Greg KH wrote: > > There are a number of usermode helper binaries that are "hard coded" in > the kernel today, so mark them as "const" to make it harder for someone > to change where the variables point to. > > Signed-off-by: Greg Kroah-Hartman

Re: [kernel-hardening] [PATCH 3/4] Make static usermode helper binaries constant

On Wed, Dec 14, 2016 at 10:50:52AM -0800, Greg KH wrote: > > There are a number of usermode helper binaries that are "hard coded" in > the kernel today, so mark them as "const" to make it harder for someone > to change where the variables point to. > > Signed-off-by: Greg Kroah-Hartman > --- >

Applied "ASoC: dwc: Fix PIO mode initialization" to the asoc tree

The patch ASoC: dwc: Fix PIO mode initialization has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus

Applied "ASoC: dwc: Fix PIO mode initialization" to the asoc tree

The patch ASoC: dwc: Fix PIO mode initialization has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus

Re: [PATCH v3 2/2] FPGA: Add TS-7300 FPGA manager

On 12/14/2016 10:58 AM, Hartley Sweeten wrote: > On Wednesday, December 14, 2016 11:55 AM, Florian Fainelli wrote: >> My understanding is that, yes, this triggers the final write. You are >> right that ts73xx_fpga_write() can be called multiple times. It sounds >> like what my write_complete

Re: [PATCH v3 2/2] FPGA: Add TS-7300 FPGA manager

On 12/14/2016 10:58 AM, Hartley Sweeten wrote: > On Wednesday, December 14, 2016 11:55 AM, Florian Fainelli wrote: >> My understanding is that, yes, this triggers the final write. You are >> right that ts73xx_fpga_write() can be called multiple times. It sounds >> like what my write_complete

[v3] net: ethernet: cavium: octeon: octeon_mgmt: Handle return NULL error from devm_ioremap

Here, If devm_ioremap 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 Yadav --- drivers/net/ethernet/cavium/octeon/octeon_mgmt.c | 6 ++ 1 file changed, 6

Re: [v2] net:ethernet:cavium:octeon:octeon_mgmt: Handle return NULL error from devm_ioremap

Hi, As per your suggestion, I have change the subject. Thanks On Thursday 15 December 2016 12:24 AM, Florian Fainelli wrote: On 12/14/2016 10:39 AM, arvind Yadav wrote: Hi David, I have gave my comment. Thanks Arvind On Wednesday 14 December 2016 11:44 PM, David Daney wrote: On

[v3] net: ethernet: cavium: octeon: octeon_mgmt: Handle return NULL error from devm_ioremap

Here, If devm_ioremap 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 Yadav --- drivers/net/ethernet/cavium/octeon/octeon_mgmt.c | 6 ++ 1 file changed, 6 insertions(+) diff --git

Re: [v2] net:ethernet:cavium:octeon:octeon_mgmt: Handle return NULL error from devm_ioremap

Hi, As per your suggestion, I have change the subject. Thanks On Thursday 15 December 2016 12:24 AM, Florian Fainelli wrote: On 12/14/2016 10:39 AM, arvind Yadav wrote: Hi David, I have gave my comment. Thanks Arvind On Wednesday 14 December 2016 11:44 PM, David Daney wrote: On

Re: [PATCH 1/3] mm, trace: extract COMPACTION_STATUS and ZONE_TYPE to a common header

On Thu 15-12-16 01:32:06, kbuild test robot wrote: > Hi Michal, > > [auto build test ERROR on tip/perf/core] > [also build test ERROR on v4.9 next-20161214] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url:

Re: [PATCH 1/3] mm, trace: extract COMPACTION_STATUS and ZONE_TYPE to a common header

On Thu 15-12-16 01:32:06, kbuild test robot wrote: > Hi Michal, > > [auto build test ERROR on tip/perf/core] > [also build test ERROR on v4.9 next-20161214] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url:

Re: Question about regulator API

On Wed, Dec 14, 2016 at 03:52:54PM +0100, Harald Geyer wrote: > Thus the following constraints should be met: > * When user space asks the driver to read a device, it needs to "claim" > the supply and ensure that it has been up for at least 2 seconds > before proceeding to read the HW. The

Re: Question about regulator API

On Wed, Dec 14, 2016 at 03:52:54PM +0100, Harald Geyer wrote: > Thus the following constraints should be met: > * When user space asks the driver to read a device, it needs to "claim" > the supply and ensure that it has been up for at least 2 seconds > before proceeding to read the HW. The

Re: [PATCH v2 3/3] kvm: svm: Use the hardware provided GPA instead of page walk

On 12/14/2016 11:23 AM, Paolo Bonzini wrote: On 14/12/2016 18:07, Brijesh Singh wrote: Since now we are going to perform multiple conditional checks before concluding that its safe to use HW provided GPA. How about if we add two functions "emulator_is_rep_string_op" and

Re: [PATCH v2 3/3] kvm: svm: Use the hardware provided GPA instead of page walk

On 12/14/2016 11:23 AM, Paolo Bonzini wrote: On 14/12/2016 18:07, Brijesh Singh wrote: Since now we are going to perform multiple conditional checks before concluding that its safe to use HW provided GPA. How about if we add two functions "emulator_is_rep_string_op" and

Re: [v2] net:ethernet:cavium:octeon:octeon_mgmt: Handle return NULL error from devm_ioremap

On 12/14/2016 10:39 AM, arvind Yadav wrote: > Hi David, > > I have gave my comment. > > Thanks > Arvind > > On Wednesday 14 December 2016 11:44 PM, David Daney wrote: >> On 12/14/2016 10:06 AM, arvind Yadav wrote: >>> Yes, I have seen this error. We have a device with very less memory. >>>

Re: [v2] net:ethernet:cavium:octeon:octeon_mgmt: Handle return NULL error from devm_ioremap

On 12/14/2016 10:39 AM, arvind Yadav wrote: > Hi David, > > I have gave my comment. > > Thanks > Arvind > > On Wednesday 14 December 2016 11:44 PM, David Daney wrote: >> On 12/14/2016 10:06 AM, arvind Yadav wrote: >>> Yes, I have seen this error. We have a device with very less memory. >>>

Re: [GIT PULL] ext4 updates for 4.10

On Wed, Dec 14, 2016 at 09:20:43AM -0800, Linus Torvalds wrote: > [ Johannes added to participants due to radix tree changes ] > > On Tue, Dec 13, 2016 at 12:00 PM, Theodore Ts'o wrote: > > > > This merge request includes the dax-4.0-iomap-pmd branch which is > > needed for both

Re: [GIT PULL] ext4 updates for 4.10

On Wed, Dec 14, 2016 at 09:20:43AM -0800, Linus Torvalds wrote: > [ Johannes added to participants due to radix tree changes ] > > On Tue, Dec 13, 2016 at 12:00 PM, Theodore Ts'o wrote: > > > > This merge request includes the dax-4.0-iomap-pmd branch which is > > needed for both ext4 and xfs dax

[PATCH 2/4] drbd: rename "usermode_helper" to "drbd_usermode_helper"

Nothing like having a very generic global variable in a tiny driver subsystem to make a mess of the global namespace... Anyway, clean it up in anticipation of making drbd_usermode_helper read-only in a future patch. Note, there are many other "generic" named global variables in the drbd

[PATCH 2/4] drbd: rename "usermode_helper" to "drbd_usermode_helper"

Nothing like having a very generic global variable in a tiny driver subsystem to make a mess of the global namespace... Anyway, clean it up in anticipation of making drbd_usermode_helper read-only in a future patch. Note, there are many other "generic" named global variables in the drbd

[RFC 4/4] Introduce CONFIG_READONLY_USERMODEHELPER

If you can write to kernel memory, an "easy" way to get the kernel to run any application is to change the pointer of one of the usermode helper program names. To try to mitigate this, create a new config option, CONFIG_READONLY_USERMODEHELPER. This option only allows "predefined" binaries to be

[PATCH 3/4] Make static usermode helper binaries constant

There are a number of usermode helper binaries that are "hard coded" in the kernel today, so mark them as "const" to make it harder for someone to change where the variables point to. Signed-off-by: Greg Kroah-Hartman --- drivers/macintosh/windfarm_core.c |

[RFC 4/4] Introduce CONFIG_READONLY_USERMODEHELPER

If you can write to kernel memory, an "easy" way to get the kernel to run any application is to change the pointer of one of the usermode helper program names. To try to mitigate this, create a new config option, CONFIG_READONLY_USERMODEHELPER. This option only allows "predefined" binaries to be

[PATCH 3/4] Make static usermode helper binaries constant

There are a number of usermode helper binaries that are "hard coded" in the kernel today, so mark them as "const" to make it harder for someone to change where the variables point to. Signed-off-by: Greg Kroah-Hartman --- drivers/macintosh/windfarm_core.c | 2 +-

[RFC 0/4] make call_usermodehelper a bit more "safe"

Hi all, Here's a proof-of-concept patch series that tries to work to address the issue of call_usermodehelper being abused to have the kernel call any userspace binary with full root permissions. The issue is that if you end up getting write access to kernel memory, if you change the string

[RFC 0/4] make call_usermodehelper a bit more "safe"

Hi all, Here's a proof-of-concept patch series that tries to work to address the issue of call_usermodehelper being abused to have the kernel call any userspace binary with full root permissions. The issue is that if you end up getting write access to kernel memory, if you change the string

[PATCH 1/4] kmod: make usermodehelper path a const string

This is in preparation for making it so that usermode helper programs can't be changed, if desired, by userspace. We will tackle the mess of cleaning up the write-ability of argv and env later, that's going to take more work, for much less gain... Signed-off-by: Greg Kroah-Hartman

[PATCH 1/4] kmod: make usermodehelper path a const string

This is in preparation for making it so that usermode helper programs can't be changed, if desired, by userspace. We will tackle the mess of cleaning up the write-ability of argv and env later, that's going to take more work, for much less gain... Signed-off-by: Greg Kroah-Hartman ---

[PATCH v3 2/3] secure_seq: use siphash24 instead of md5_transform

This gives a clear speed and security improvement. Siphash is both faster and is more solid crypto than the aging MD5. Rather than manually filling MD5 buffers, we simply create a layout by a simple anonymous struct, for which gcc generates rather efficient code. Signed-off-by: Jason A.

[PATCH v3 2/3] secure_seq: use siphash24 instead of md5_transform

This gives a clear speed and security improvement. Siphash is both faster and is more solid crypto than the aging MD5. Rather than manually filling MD5 buffers, we simply create a layout by a simple anonymous struct, for which gcc generates rather efficient code. Signed-off-by: Jason A.

Re: [PATCH v2 3/3] kvm: svm: Use the hardware provided GPA instead of page walk

On 14/12/2016 19:39, Brijesh Singh wrote: > > On 12/14/2016 11:23 AM, Paolo Bonzini wrote: >> >> >> On 14/12/2016 18:07, Brijesh Singh wrote: >>> >>> Since now we are going to perform multiple conditional checks before >>> concluding that its safe to use HW provided GPA. How about if we

Re: [PATCH v3 1/2] ARM: ep93xx: Register ts73xx-fpga manager driver for TS-7300

On 12/13/2016 10:14 PM, Moritz Fischer wrote: > Hi Florian, > > On Tue, Dec 13, 2016 at 6:35 PM, Florian Fainelli > wrote: >> Register the TS-7300 FPGA manager device drivers which allows us to load >> bitstreams into the on-board Altera Cyclone II FPGA. >> >>

Re: [PATCH v2 3/3] kvm: svm: Use the hardware provided GPA instead of page walk

On 14/12/2016 19:39, Brijesh Singh wrote: > > On 12/14/2016 11:23 AM, Paolo Bonzini wrote: >> >> >> On 14/12/2016 18:07, Brijesh Singh wrote: >>> >>> Since now we are going to perform multiple conditional checks before >>> concluding that its safe to use HW provided GPA. How about if we

Re: [PATCH v3 1/2] ARM: ep93xx: Register ts73xx-fpga manager driver for TS-7300

On 12/13/2016 10:14 PM, Moritz Fischer wrote: > Hi Florian, > > On Tue, Dec 13, 2016 at 6:35 PM, Florian Fainelli > wrote: >> Register the TS-7300 FPGA manager device drivers which allows us to load >> bitstreams into the on-board Altera Cyclone II FPGA. >> >> Signed-off-by: Florian Fainelli

[PATCH v3 1/3] siphash: add cryptographically secure hashtable function

SipHash is a 64-bit keyed hash function that is actually a cryptographically secure PRF, like HMAC. Except SipHash is super fast, and is meant to be used as a hashtable keyed lookup function. SipHash isn't just some new trendy hash function. It's been around for a while, and there really isn't

[PATCH v3 3/3] random: use siphash24 instead of md5 for get_random_int/long

This duplicates the current algorithm for get_random_int/long, but uses siphash24 instead. This comes with several benefits. It's certainly faster and more cryptographically secure than MD5. This patch also hashes the pid, entropy, and timestamp as fixed width fields, in order to increase

[PATCH v3 3/3] random: use siphash24 instead of md5 for get_random_int/long

This duplicates the current algorithm for get_random_int/long, but uses siphash24 instead. This comes with several benefits. It's certainly faster and more cryptographically secure than MD5. This patch also hashes the pid, entropy, and timestamp as fixed width fields, in order to increase

[PATCH v3 1/3] siphash: add cryptographically secure hashtable function

SipHash is a 64-bit keyed hash function that is actually a cryptographically secure PRF, like HMAC. Except SipHash is super fast, and is meant to be used as a hashtable keyed lookup function. SipHash isn't just some new trendy hash function. It's been around for a while, and there really isn't

Re: [GIT PULL] f2fs update for 4.10

On 12/14, Linus Torvalds wrote: > On Mon, Dec 12, 2016 at 2:15 PM, Jaegeuk Kim wrote: > > > > Could you please consider this pull request? > > Pulled. Mind double-checking my resolution wrt commit 70fd76140a6c > ("block,fs: use REQ_* flags directly")? Thank you, and the

Re: [GIT PULL] f2fs update for 4.10

On 12/14, Linus Torvalds wrote: > On Mon, Dec 12, 2016 at 2:15 PM, Jaegeuk Kim wrote: > > > > Could you please consider this pull request? > > Pulled. Mind double-checking my resolution wrt commit 70fd76140a6c > ("block,fs: use REQ_* flags directly")? Thank you, and the resolution looks good to

Re: [v2] net:ethernet:cavium:octeon:octeon_mgmt: Handle return NULL error from devm_ioremap

Hi David, I have gave my comment. Thanks Arvind On Wednesday 14 December 2016 11:44 PM, David Daney wrote: On 12/14/2016 10:06 AM, arvind Yadav wrote: Yes, I have seen this error. We have a device with very less memory. Basically it's OMAP2 board. We have to port Android L on this. It's has

Re: [v2] net:ethernet:cavium:octeon:octeon_mgmt: Handle return NULL error from devm_ioremap

Hi David, I have gave my comment. Thanks Arvind On Wednesday 14 December 2016 11:44 PM, David Daney wrote: On 12/14/2016 10:06 AM, arvind Yadav wrote: Yes, I have seen this error. We have a device with very less memory. Basically it's OMAP2 board. We have to port Android L on this. It's has

Re: [RFC] perf/x86/intel: Account interrupts for PEBS errors

On Wed, Dec 14, 2016 at 05:50:36PM +0100, Jiri Olsa wrote: > > I also fail to reproduce on other than snb_x (model 45) server reproduces on my ivb-ep as well model 62. > thoughts? cute find :-) > +++ b/arch/x86/events/intel/ds.c > @@ -1389,9 +1389,13 @@ static void

Re: [RFC] perf/x86/intel: Account interrupts for PEBS errors

On Wed, Dec 14, 2016 at 05:50:36PM +0100, Jiri Olsa wrote: > > I also fail to reproduce on other than snb_x (model 45) server reproduces on my ivb-ep as well model 62. > thoughts? cute find :-) > +++ b/arch/x86/events/intel/ds.c > @@ -1389,9 +1389,13 @@ static void

RE: [PATCH] perf tools: ignore zombie process for user profile

> > On Wed, Dec 14, 2016 at 12:48:05PM -0500, kan.li...@intel.com wrote: > > From: Kan Liang > > > > If user has zombie process, the perf record -u will error out. > > Here is an example. > > $ ./testd & > > [1] 23796 > > $ sudo perf record -e cycles -u kan > > Error:

RE: [PATCH] perf tools: ignore zombie process for user profile

> > On Wed, Dec 14, 2016 at 12:48:05PM -0500, kan.li...@intel.com wrote: > > From: Kan Liang > > > > If user has zombie process, the perf record -u will error out. > > Here is an example. > > $ ./testd & > > [1] 23796 > > $ sudo perf record -e cycles -u kan > > Error: > > The

[GIT PULL] Audit patches for v4.10

Hi Linus, After the small number of patches for v4.9, we've got a much bigger pile for v4.10. The bulk of these patches involve a rework of the audit backlog queue to enable us to move the netlink multicasting out of the task/thread that generates the audit record and into the kernel thread

[GIT PULL] Audit patches for v4.10

Hi Linus, After the small number of patches for v4.9, we've got a much bigger pile for v4.10. The bulk of these patches involve a rework of the audit backlog queue to enable us to move the netlink multicasting out of the task/thread that generates the audit record and into the kernel thread

Re: [PATCH v2] infiniband: remove WARN that is not kernel bug

On Wed, Dec 14, 2016 at 01:16:45PM -0500, Doug Ledford wrote: > On 11/21/2016 12:38 PM, Leon Romanovsky wrote: > > On Mon, Nov 21, 2016 at 09:52:53AM -0700, Jason Gunthorpe wrote: > >> On Mon, Nov 21, 2016 at 02:14:08PM +0200, Leon Romanovsky wrote: > > In ib_ucm_write function there is

Re: [PATCH v2] infiniband: remove WARN that is not kernel bug

On Wed, Dec 14, 2016 at 01:16:45PM -0500, Doug Ledford wrote: > On 11/21/2016 12:38 PM, Leon Romanovsky wrote: > > On Mon, Nov 21, 2016 at 09:52:53AM -0700, Jason Gunthorpe wrote: > >> On Mon, Nov 21, 2016 at 02:14:08PM +0200, Leon Romanovsky wrote: > > In ib_ucm_write function there is

Re: [PATCH] Input: evdev: fix queueing of SYN_DROPPED event for EVIOCG[type] IOCTL case

Hello Mr. Torokhov, Would you kindly update about this patch? Thanks! Best Regards, Aniroop Mathur On Fri, Nov 25, 2016 at 1:41 AM, Aniroop Mathur wrote: > Currently, when EVIOCG[type] ioctl call is issued and bits_to_user fails, > then SYN_DROPPED event is inserted in

Re: [PATCH] Input: evdev: fix queueing of SYN_DROPPED event for EVIOCG[type] IOCTL case

Hello Mr. Torokhov, Would you kindly update about this patch? Thanks! Best Regards, Aniroop Mathur On Fri, Nov 25, 2016 at 1:41 AM, Aniroop Mathur wrote: > Currently, when EVIOCG[type] ioctl call is issued and bits_to_user fails, > then SYN_DROPPED event is inserted in the event queue always.

Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800

On Tue, Dec 13, 2016 at 04:18:05PM -0300, Javier Martinez Canillas wrote: > Hello Bartlomiej, > > On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote: > > Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP > > (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal

Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800

On Tue, Dec 13, 2016 at 04:18:05PM -0300, Javier Martinez Canillas wrote: > Hello Bartlomiej, > > On 12/13/2016 01:52 PM, Bartlomiej Zolnierkiewicz wrote: > > Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP > > (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal

<    4   5   6   7   8   9   10   11   12   13   >