Re: [PATCH v3 2/2] ARM64: dts: bcm: Use a symlink to R-Pi dtsi files from arch=arm

On Thu, Aug 18, 2016 at 11:42:06AM +0100, Ian Campbell wrote: > The ../../../arm... style cross-references added by commit 9d56c22a7861 > ("ARM: bcm2835: Add devicetree for the Raspberry Pi 3.") do not work in the > context of the split device-tree repository[0] (where the directory > structure

Re: [PATCH v3 2/2] ARM64: dts: bcm: Use a symlink to R-Pi dtsi files from arch=arm

On Thu, Aug 18, 2016 at 11:42:06AM +0100, Ian Campbell wrote: > The ../../../arm... style cross-references added by commit 9d56c22a7861 > ("ARM: bcm2835: Add devicetree for the Raspberry Pi 3.") do not work in the > context of the split device-tree repository[0] (where the directory > structure

Re: [PATCH 1/2] net/mlx5e: shut up maybe-uninitialized warning

From: Arnd Bergmann Date: Fri, 30 Sep 2016 18:17:09 +0200 > Build-testing this driver with -Wmaybe-uninitialized gives a new > false-positive > warning that I can't really explain: > > drivers/net/ethernet/mellanox/mlx5/core/en_tc.c: In function > 'mlx5e_configure_flower': >

Re: [PATCH 1/2] net/mlx5e: shut up maybe-uninitialized warning

From: Arnd Bergmann Date: Fri, 30 Sep 2016 18:17:09 +0200 > Build-testing this driver with -Wmaybe-uninitialized gives a new > false-positive > warning that I can't really explain: > > drivers/net/ethernet/mellanox/mlx5/core/en_tc.c: In function > 'mlx5e_configure_flower': >

Re: [PATCH 2/2] mlxsw: spectrum_router: avoid potential uninitialized data usage

From: Arnd Bergmann Date: Fri, 30 Sep 2016 18:17:10 +0200 > If fi->fib_nhs is zero, the router interface pointer is uninitialized, as > shown by > this warning: > > drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c: In function > 'mlxsw_sp_router_fib_event': >

Re: [PATCH 2/2] mlxsw: spectrum_router: avoid potential uninitialized data usage

From: Arnd Bergmann Date: Fri, 30 Sep 2016 18:17:10 +0200 > If fi->fib_nhs is zero, the router interface pointer is uninitialized, as > shown by > this warning: > > drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c: In function > 'mlxsw_sp_router_fib_event': >

Re: [Nouveau] [PATCH v4 3/3] drm/nouveau/fb/nv50: defer DMA mapping of scratch page to init() hook

On Mon, Sep 26, 2016 at 9:32 PM, Ard Biesheuvel wrote: > The 100c08 scratch page is mapped using dma_map_page() before the TTM > layer has had a chance to set the DMA mask. This means we are still > running with the default of 32 when this code executes, and this causes

Re: [Nouveau] [PATCH v4 3/3] drm/nouveau/fb/nv50: defer DMA mapping of scratch page to init() hook

On Mon, Sep 26, 2016 at 9:32 PM, Ard Biesheuvel wrote: > The 100c08 scratch page is mapped using dma_map_page() before the TTM > layer has had a chance to set the DMA mask. This means we are still > running with the default of 32 when this code executes, and this causes > problems for platforms

Re: [Nouveau] [PATCH v4 2/3] drm/nouveau/fb/gf100: defer DMA mapping of scratch page to init() hook

On Mon, Sep 26, 2016 at 9:32 PM, Ard Biesheuvel wrote: > The 100c10 scratch page is mapped using dma_map_page() before the TTM > layer has had a chance to set the DMA mask. This means we are still > running with the default of 32 when this code executes, and this causes

Re: [Nouveau] [PATCH v4 2/3] drm/nouveau/fb/gf100: defer DMA mapping of scratch page to init() hook

On Mon, Sep 26, 2016 at 9:32 PM, Ard Biesheuvel wrote: > The 100c10 scratch page is mapped using dma_map_page() before the TTM > layer has had a chance to set the DMA mask. This means we are still > running with the default of 32 when this code executes, and this causes > problems for platforms

Re: [Nouveau] [PATCH v4 1/3] drm/nouveau: set streaming DMA mask early

On Mon, Sep 26, 2016 at 9:32 PM, Ard Biesheuvel wrote: > Some subdevices (i.e., fb/nv50.c and fb/gf100.c) map a scratch page using > dma_map_page() way before the TTM layer has had a chance to set the DMA > mask. This may prevent the driver from loading at all on

Re: [Nouveau] [PATCH v4 1/3] drm/nouveau: set streaming DMA mask early

On Mon, Sep 26, 2016 at 9:32 PM, Ard Biesheuvel wrote: > Some subdevices (i.e., fb/nv50.c and fb/gf100.c) map a scratch page using > dma_map_page() way before the TTM layer has had a chance to set the DMA > mask. This may prevent the driver from loading at all on platforms whose > system memory

[PATCH V3 1/2] PCI: add CRS support to error handling path

The PCIE spec allows an endpoint device to extend the initialization time beyond 1 second by issuing Configuration Request Retry Status (CRS) for a vendor ID read request. This basically means "I'm busy now, please call me back later". There are two moving parts to CRS support from the SW

[PATCH V3 2/2] PCI: handle CRS returned by device after FLR

An endpoint is allowed to issue CRS following an FLR request to indicate that it is not ready to accept new requests. Changing the polling mechanism in FLR wait function to go read the vendor ID instead of the command/status register. A CRS indication will only be given if the address to be read

[PATCH V3 0/2] PCI: add CRS support after hot reset and FLR

The PCIE spec allows an endpoint device to extend the initialization time beyond 1 second by issuing Configuration Request Retry Status (CRS) for a vendor ID read request. This basically means "I'm busy now, please call me back later". There are two moving parts to CRS support from the SW

[PATCH V3 0/2] PCI: add CRS support after hot reset and FLR

The PCIE spec allows an endpoint device to extend the initialization time beyond 1 second by issuing Configuration Request Retry Status (CRS) for a vendor ID read request. This basically means "I'm busy now, please call me back later". There are two moving parts to CRS support from the SW

[PATCH V3 1/2] PCI: add CRS support to error handling path

The PCIE spec allows an endpoint device to extend the initialization time beyond 1 second by issuing Configuration Request Retry Status (CRS) for a vendor ID read request. This basically means "I'm busy now, please call me back later". There are two moving parts to CRS support from the SW

[PATCH V3 2/2] PCI: handle CRS returned by device after FLR

An endpoint is allowed to issue CRS following an FLR request to indicate that it is not ready to accept new requests. Changing the polling mechanism in FLR wait function to go read the vendor ID instead of the command/status register. A CRS indication will only be given if the address to be read

Re: [PATCH] cxgb4: unexport cxgb4_dcb_enabled

From: Arnd Bergmann Date: Fri, 30 Sep 2016 18:15:33 +0200 > A recent cleanup marked cxgb4_dcb_enabled as 'static', which is correct, but > this ignored > how the symbol is also exported. In addition, the export can be compiled out > when modules > are disabled, causing a

Re: [PATCH] cxgb4: unexport cxgb4_dcb_enabled

From: Arnd Bergmann Date: Fri, 30 Sep 2016 18:15:33 +0200 > A recent cleanup marked cxgb4_dcb_enabled as 'static', which is correct, but > this ignored > how the symbol is also exported. In addition, the export can be compiled out > when modules > are disabled, causing a harmless compiler

Re: [PATCH] net: rtnl: avoid uninitialized data in IFLA_VF_VLAN_LIST handling

From: Arnd Bergmann Date: Fri, 30 Sep 2016 18:13:49 +0200 > With the newly added support for IFLA_VF_VLAN_LIST netlink messages, > we get a warning about potential uninitialized variable use in > the parsing of the user input when enabling the -Wmaybe-uninitialized > warning: > >

Re: [PATCH] net: rtnl: avoid uninitialized data in IFLA_VF_VLAN_LIST handling

From: Arnd Bergmann Date: Fri, 30 Sep 2016 18:13:49 +0200 > With the newly added support for IFLA_VF_VLAN_LIST netlink messages, > we get a warning about potential uninitialized variable use in > the parsing of the user input when enabling the -Wmaybe-uninitialized > warning: > >

Re: [PATCH] net: ethernet: mediatek: mark symbols static where possible

From: Baoyou Xie Date: Fri, 30 Sep 2016 15:48:50 +0800 > We get 2 warnings when building kernel with W=1: > drivers/net/ethernet/mediatek/mtk_eth_soc.c:2041:5: warning: no previous > prototype for 'mtk_get_link_ksettings' [-Wmissing-prototypes] >

Re: [PATCH] net: ethernet: mediatek: mark symbols static where possible

From: Baoyou Xie Date: Fri, 30 Sep 2016 15:48:50 +0800 > We get 2 warnings when building kernel with W=1: > drivers/net/ethernet/mediatek/mtk_eth_soc.c:2041:5: warning: no previous > prototype for 'mtk_get_link_ksettings' [-Wmissing-prototypes] >

Re: [PATCH] cxgb4: mark cxgb_setup_tc() static

From: Baoyou Xie Date: Fri, 30 Sep 2016 15:34:25 +0800 > We get 1 warning when building kernel with W=1: > drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:2715:5: warning: no previous > prototype for 'cxgb_setup_tc' [-Wmissing-prototypes] > > In fact, this function is

Re: [PATCH] cxgb4: mark cxgb_setup_tc() static

From: Baoyou Xie Date: Fri, 30 Sep 2016 15:34:25 +0800 > We get 1 warning when building kernel with W=1: > drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:2715:5: warning: no previous > prototype for 'cxgb_setup_tc' [-Wmissing-prototypes] > > In fact, this function is only used in the file in

Re: [lustre-devel] [PATCH] staging: lustre: ko2iblbd: handle ib_dereg_mr removal

On Oct 2, 2016, at 20:22, James Simmons wrote: > > In the rdma-next tree to be merged for 4.9-rc1 removes > the IB core function ib_get_dma_mr. This patch migrates > us way from this former function. > > Signed-off-by: James Simmons > --- >

Re: [lustre-devel] [PATCH] staging: lustre: ko2iblbd: handle ib_dereg_mr removal

On Oct 2, 2016, at 20:22, James Simmons wrote: > > In the rdma-next tree to be merged for 4.9-rc1 removes > the IB core function ib_get_dma_mr. This patch migrates > us way from this former function. > > Signed-off-by: James Simmons > --- > .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c|

Re: [PATCH v4 0/2] Avoid selftests on some Asus models

On Sat, Oct 01, 2016 at 07:56:37AM -0300, Marcos Paulo de Souza wrote: > ping? Sorry for the delay, I was trying to wrap my mind around the new always/never/sometimes logic. Does the version below still work for you? Thanks. -- Dmitry Input: i8042 - skip selftest on ASUS laptops From:

Re: [PATCH v4 0/2] Avoid selftests on some Asus models

On Sat, Oct 01, 2016 at 07:56:37AM -0300, Marcos Paulo de Souza wrote: > ping? Sorry for the delay, I was trying to wrap my mind around the new always/never/sometimes logic. Does the version below still work for you? Thanks. -- Dmitry Input: i8042 - skip selftest on ASUS laptops From:

linux-next: Tree for Oct 3

Hi all, Changes since 20160930: The net-next tree gained conflicts against Linus' tree. The mac80211-next tree gained conflicts against Linus' tree. The xen-tip tree gained conflicts againt the tip tree. The tty tree lost its build failure. Non-merge commits (relative to Linus' tree): 13450

linux-next: Tree for Oct 3

Hi all, Changes since 20160930: The net-next tree gained conflicts against Linus' tree. The mac80211-next tree gained conflicts against Linus' tree. The xen-tip tree gained conflicts againt the tip tree. The tty tree lost its build failure. Non-merge commits (relative to Linus' tree): 13450

Re: [PATCH] fs/block_dev.c: always return error in thaw_bdev()

On Thu, Aug 20, 2015 at 12:07:49PM +0200, Pierre Morel wrote: > When triggering thaw-filesystems via magic sysrq, the system enters a > loop in do_thaw_one(), as thaw_bdev() still returns success if > bd_fsfreeze_count == 0. To fix this, let thaw_bdev() always return > error (and simplify the code

Re: [PATCH] fs/block_dev.c: always return error in thaw_bdev()

On Thu, Aug 20, 2015 at 12:07:49PM +0200, Pierre Morel wrote: > When triggering thaw-filesystems via magic sysrq, the system enters a > loop in do_thaw_one(), as thaw_bdev() still returns success if > bd_fsfreeze_count == 0. To fix this, let thaw_bdev() always return > error (and simplify the code

Re: [PATCH V2 3/5] PCI: save and restore bus on parent bus reset

On 9/29/2016 7:50 PM, Sinan Kaya wrote: > Hi Bjorn, > > On 9/29/2016 5:49 PM, Bjorn Helgaas wrote: >>> + } >> This pattern of "unlock, do something, relock" needs some >> justification. In general it's unsafe because the lock is protecting >> *something*, and you have to assume that something

Re: [PATCH V2 3/5] PCI: save and restore bus on parent bus reset

On 9/29/2016 7:50 PM, Sinan Kaya wrote: > Hi Bjorn, > > On 9/29/2016 5:49 PM, Bjorn Helgaas wrote: >>> + } >> This pattern of "unlock, do something, relock" needs some >> justification. In general it's unsafe because the lock is protecting >> *something*, and you have to assume that something

Re: [PATCH V4 04/10] dmaengine: qcom_hidma: configure DMA and MSI for OF

On Sat, Oct 01, 2016 at 11:15:00AM -0400, Sinan Kaya wrote: > On 10/1/2016 2:17 AM, Vinod Koul wrote: > > On Wed, Sep 28, 2016 at 10:12:41PM -0400, Sinan Kaya wrote: > >> Configure the DMA bindings for the device tree based firmware. > >> > >> Signed-off-by: Sinan Kaya > >>

Re: [PATCH V4 04/10] dmaengine: qcom_hidma: configure DMA and MSI for OF

On Sat, Oct 01, 2016 at 11:15:00AM -0400, Sinan Kaya wrote: > On 10/1/2016 2:17 AM, Vinod Koul wrote: > > On Wed, Sep 28, 2016 at 10:12:41PM -0400, Sinan Kaya wrote: > >> Configure the DMA bindings for the device tree based firmware. > >> > >> Signed-off-by: Sinan Kaya > >> --- > >>

Re: [PATCH V4 05/10] dmaengine: qcom_hidma: make pending_tre_count atomic

On Sat, Oct 01, 2016 at 11:19:43AM -0400, Sinan Kaya wrote: > On 10/1/2016 2:19 AM, Vinod Koul wrote: > >> Making it atomic so that it can be updated from multiple contexts. > > How is it multiple contexts? It's either existing context of MSI, not both! > > > > I was trying to mean multiple

Re: [PATCH V4 05/10] dmaengine: qcom_hidma: make pending_tre_count atomic

On Sat, Oct 01, 2016 at 11:19:43AM -0400, Sinan Kaya wrote: > On 10/1/2016 2:19 AM, Vinod Koul wrote: > >> Making it atomic so that it can be updated from multiple contexts. > > How is it multiple contexts? It's either existing context of MSI, not both! > > > > I was trying to mean multiple

[ANNOUNCE] BFS CPU scheduler v0.512 for linux-4.8, 4.8-ck1

This is to announce an updated stable version of the Brain Fuck Scheduler, version 0.512 for the current stable linux kernel for improved responsiveness and interactivity. http://ck.kolivas.org/patches/bfs/4.0/4.8/4.8-sched-bfs-512.patch A -ck branded release with minor tweaks and the

[ANNOUNCE] BFS CPU scheduler v0.512 for linux-4.8, 4.8-ck1

This is to announce an updated stable version of the Brain Fuck Scheduler, version 0.512 for the current stable linux kernel for improved responsiveness and interactivity. http://ck.kolivas.org/patches/bfs/4.0/4.8/4.8-sched-bfs-512.patch A -ck branded release with minor tweaks and the

Re: [RESEND PATCH v2 0/3] Broadcom AVS CPUfreq driver

On 30-09-16, 14:55, Markus Mayer wrote: > This series contains the CPUfreq driver for Broadcom SoCs that use "AVS > Firmware" for voltage and frequency scaling. All voltage and frequency > transitions are performed by the firmware and are therefore hidden from > Linux. > > The driver provides a

Re: [RESEND PATCH v2 0/3] Broadcom AVS CPUfreq driver

On 30-09-16, 14:55, Markus Mayer wrote: > This series contains the CPUfreq driver for Broadcom SoCs that use "AVS > Firmware" for voltage and frequency scaling. All voltage and frequency > transitions are performed by the firmware and are therefore hidden from > Linux. > > The driver provides a

Re: [PATCH] netfilter: bridge: clarify bridge/netfilter message

From: Stefan Agner Date: Wed, 28 Sep 2016 15:05:28 -0700 > When using bridge without bridge netfilter enabled the message > displayed is rather confusing and leads to belive that a deprecated > feature is in use. Use IS_MODULE to be explicit that the message only > affects users

Re: [PATCH] netfilter: bridge: clarify bridge/netfilter message

From: Stefan Agner Date: Wed, 28 Sep 2016 15:05:28 -0700 > When using bridge without bridge netfilter enabled the message > displayed is rather confusing and leads to belive that a deprecated > feature is in use. Use IS_MODULE to be explicit that the message only > affects users which use bridge

Re: [PATCH v2 net-next 1/2] net: centralize net_device min/max MTU checking

From: Jakub Sitnicki Date: Fri, 30 Sep 2016 11:37:24 +0200 > On Wed, Sep 28, 2016 at 10:20 PM GMT, Jarod Wilson wrote: >> While looking into an MTU issue with sfc, I started noticing that almost >> every NIC driver with an ndo_change_mtu function implemented almost >> exactly

Re: [PATCH v2 net-next 1/2] net: centralize net_device min/max MTU checking

From: Jakub Sitnicki Date: Fri, 30 Sep 2016 11:37:24 +0200 > On Wed, Sep 28, 2016 at 10:20 PM GMT, Jarod Wilson wrote: >> While looking into an MTU issue with sfc, I started noticing that almost >> every NIC driver with an ndo_change_mtu function implemented almost >> exactly the same range

[PATCH 20/41] staging: lustre: remove Size on MDS support

From: John L. Hammond Remove unused definitions related to Size on MDS support from lustre/include/lustre/lustre_idl.h. Remove unused code from several places in lustre/. Signed-off-by: John L. Hammond Intel-bug-id:

[PATCH 03/41] staging: lustre: llite: remove client Size on MDS support

From: John L. Hammond Size on MDS support have been in preview since at least 2.0.0. Remove support for it from lustre/llite/. Signed-off-by: John L. Hammond Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6047 Reviewed-on:

[PATCH 22/41] staging: lustre: obd: remove unused LSM parameters

From: John L. Hammond Remove unused struct lov_stripe_md * parameters from obd_get_info(), mgc_enqueue(), and osc_brw_prep_request(). Signed-off-by: John L. Hammond Signed-off-by: Jinshan Xiong Intel-bug-id:

[PATCH 20/41] staging: lustre: remove Size on MDS support

From: John L. Hammond Remove unused definitions related to Size on MDS support from lustre/include/lustre/lustre_idl.h. Remove unused code from several places in lustre/. Signed-off-by: John L. Hammond Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6047 Reviewed-on:

[PATCH 03/41] staging: lustre: llite: remove client Size on MDS support

From: John L. Hammond Size on MDS support have been in preview since at least 2.0.0. Remove support for it from lustre/llite/. Signed-off-by: John L. Hammond Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6047 Reviewed-on: http://review.whamcloud.com/13126 Reviewed-by: Andreas Dilger

[PATCH 22/41] staging: lustre: obd: remove unused LSM parameters

From: John L. Hammond Remove unused struct lov_stripe_md * parameters from obd_get_info(), mgc_enqueue(), and osc_brw_prep_request(). Signed-off-by: John L. Hammond Signed-off-by: Jinshan Xiong Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5814 Reviewed-on:

[PATCH 06/41] staging: lustre: ldlm: remove unnecessary EXPORT_SYMBOL

From: frank zago A lot of symbols don't need to be exported at all because they are only used in the module they belong to. Signed-off-by: frank zago Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5829 Reviewed-on: http://review.whamcloud.com/13324

[PATCH 11/41] staging: lustre: ptlrpc: Add OBD_CONNECT_MULTIMODRPCS flag

From: Gregoire Pichon The new OBD_CONNECT_MULTIMODRPCS connection flag indicates the support of multiple modify RPCs in parallel. It can be specified by the client within the connection request and by the server within the connection reply. The new ocd_maxmodrpcs

[PATCH 14/41] staging: lustre: ptlrpc: Add a tag field to ptlrpc messages

From: Gregoire Pichon The new tag field is used as a virtual index for multiple modifying RPCs management. It is set by the client and allows the target to release in-memory reply data when the tag is reused by a new RPC. The tag field replaces the unused last_seen

[PATCH 13/41] staging: lustre: clio: use CIT_SETATTR for FSFILT_IOC_SETFLAGS

From: John L. Hammond Add handling of inode flags to the handlers of CIT_SETATTR in lov and osc. In the FSFILT_IOC_SETFLAGS case of ll_iocontrol() use cl_setattr_ost() rather than obd_setattr_rqset() to set inode flags on OST objects. Remove the then unused OBD API

[PATCH 15/41] staging: lustre: osc: fix bug when setting max_pages_per_rpc

From: Wu Libin After setting like "lctl set_param -P osc.*.max_pages_per_rpc", it is possible that the function osc_obd_max_pages_per_rpc_seq_write will be called before ocd_brw_size has been set when mount. ocd_brw_size is meaningless when it is zero. So it should not be the limit

[PATCH 17/41] staging: lustre: ptlrpc: remove old protocol compatibility

From: Andreas Dilger Some old protocol compatibility workarounds are still present in master that should have been removed when LUSTRE_MSG_MAGIC_V1 was. In particular, the process for upgrading LUSTRE_MSG_MAGIC_V1 to LUSTRE_MSG_MAGIC_V2 had the client to connect to the

[PATCH 08/41] staging: lustre: ptlrpc: ret -ECONNREFUSED if not context found in req

From: Sebastien Buisson Return -ECONNREFUSED instead of -ENOMEM in sptlrpc_req_get_ctx() if no context is found in req. It is more graceful. Signed-off-by: Sebastien Buisson Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6356

[PATCH 15/41] staging: lustre: osc: fix bug when setting max_pages_per_rpc

From: Wu Libin After setting like "lctl set_param -P osc.*.max_pages_per_rpc", it is possible that the function osc_obd_max_pages_per_rpc_seq_write will be called before ocd_brw_size has been set when mount. ocd_brw_size is meaningless when it is zero. So it should not be the limit at that time.

[PATCH 17/41] staging: lustre: ptlrpc: remove old protocol compatibility

From: Andreas Dilger Some old protocol compatibility workarounds are still present in master that should have been removed when LUSTRE_MSG_MAGIC_V1 was. In particular, the process for upgrading LUSTRE_MSG_MAGIC_V1 to LUSTRE_MSG_MAGIC_V2 had the client to connect to the server with the V1

[PATCH 08/41] staging: lustre: ptlrpc: ret -ECONNREFUSED if not context found in req

From: Sebastien Buisson Return -ECONNREFUSED instead of -ENOMEM in sptlrpc_req_get_ctx() if no context is found in req. It is more graceful. Signed-off-by: Sebastien Buisson Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6356 Reviewed-on: http://review.whamcloud.com/14043 Reviewed-by:

[PATCH 06/41] staging: lustre: ldlm: remove unnecessary EXPORT_SYMBOL

From: frank zago A lot of symbols don't need to be exported at all because they are only used in the module they belong to. Signed-off-by: frank zago Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5829 Reviewed-on: http://review.whamcloud.com/13324 Reviewed-by: James Simmons Reviewed-by:

[PATCH 11/41] staging: lustre: ptlrpc: Add OBD_CONNECT_MULTIMODRPCS flag

From: Gregoire Pichon The new OBD_CONNECT_MULTIMODRPCS connection flag indicates the support of multiple modify RPCs in parallel. It can be specified by the client within the connection request and by the server within the connection reply. The new ocd_maxmodrpcs connection data specifies the

[PATCH 14/41] staging: lustre: ptlrpc: Add a tag field to ptlrpc messages

From: Gregoire Pichon The new tag field is used as a virtual index for multiple modifying RPCs management. It is set by the client and allows the target to release in-memory reply data when the tag is reused by a new RPC. The tag field replaces the unused last_seen field of ptlrpcd_body

[PATCH 13/41] staging: lustre: clio: use CIT_SETATTR for FSFILT_IOC_SETFLAGS

From: John L. Hammond Add handling of inode flags to the handlers of CIT_SETATTR in lov and osc. In the FSFILT_IOC_SETFLAGS case of ll_iocontrol() use cl_setattr_ost() rather than obd_setattr_rqset() to set inode flags on OST objects. Remove the then unused OBD API methods obd_setattr_rqset()

[PATCH 09/41] staging: lustre: llite: default dir stripe index only for mkdir

From: wang di Default dir stripe index should only work during mkdir, otherwise it will cause other open/create request being sent to the wrong MDT. Signed-off-by: wang di Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6373 Reviewed-on:

[PATCH 24/41] staging: lustre: clio: add CIT_DATA_VERSION and remove IOC_LOV_GETINFO

From: John L. Hammond During development a new api, cl_object_obd_info_get() and cl_object_data_version() which then were later replaced by a better solution CIT_DATA_VERSION. For the case of the upstream client their is no point in introducing a API to only have it

[PATCH 09/41] staging: lustre: llite: default dir stripe index only for mkdir

From: wang di Default dir stripe index should only work during mkdir, otherwise it will cause other open/create request being sent to the wrong MDT. Signed-off-by: wang di Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6373 Reviewed-on: http://review.whamcloud.com/14096 Reviewed-by: Alex

[PATCH 24/41] staging: lustre: clio: add CIT_DATA_VERSION and remove IOC_LOV_GETINFO

From: John L. Hammond During development a new api, cl_object_obd_info_get() and cl_object_data_version() which then were later replaced by a better solution CIT_DATA_VERSION. For the case of the upstream client their is no point in introducing a API to only have it removed later. Due to the way

[PATCH 21/41] staging: lustre: mdc: Removed unneeded NULL check

From: Henri Doreau Do not bother checking the return value of changelog_kuc_hdr() against NULL since this value was dereferenced earlier. Signed-off-by: Henri Doreau Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4189 Reviewed-on:

[PATCH 37/41] staging: lustre: lov: copy_to_user uses wrong casting

With certain version of gcc lov_obd.c failes to compile with the following warning. In function copy_to_user, inlined from lov_iocontrol at lustre/lustre/lov/lov_obd.c:1168: ./arch/x86/include/asm/uaccess.h:735: error: call to __copy_to_user_overflow declared with attribute warning:

[PATCH 29/41] staging: lustre: ptlrpc: Move NRS structures out of lustre_net.h

From: Chris Horn NRS specific structures are not needed in the rest of the PtlRPC code. It is more appropriate for these structures to be defined in a separate header. This commit creates a lustre_nrs.h header for the generic NRS structures, and policy-specific headers for the

[PATCH 35/41] staging: lustre: hsm: Use file lease to implement migration

From: Henri Doreau Implement non-blocking migration based on exclusive open instead of group lock. Implemented exclusive close operation to atomically put a lease, swap two layouts and close a file. This allows race-free migrations. Make the caller responsible for retrying

[PATCH 38/41] staging: lustre: mdc: add max modify RPCs in flight variable

From: Gregoire Pichon This patch introduces the maximum modify RPCs in flight variable of a mdc client obd device. Its value is set from connection flag and and connection data. It can later be tuned through the max_mod_rpcs_in_flight procfs file. Signed-off-by:

[PATCH 33/41] staging: lustre: lov: use obd_get_info() to get def/max LOV EA sizes

From: John L. Hammond Use obd_get_info() to get the default and maximum LOV EA sizes (along with maximum cookiesize) from LOV. Remove the then unused function obd_size_diskmd() and the unused get info key KEY_LOVDESC. When computing the maximum LOV EA size use the active

[PATCH 39/41] staging: lustre: osc: remove remaining bits for capa support

From: John L. Hammond With capa support removed from the OSC layer a few more bits can be cleaned up. Convert the OBD getattr and setattr paths to use struct obdo rather than struct obd_info. Remove the oi_policy, oi_oa, and oi_capa members from struct obd_info.

[PATCH 38/41] staging: lustre: mdc: add max modify RPCs in flight variable

From: Gregoire Pichon This patch introduces the maximum modify RPCs in flight variable of a mdc client obd device. Its value is set from connection flag and and connection data. It can later be tuned through the max_mod_rpcs_in_flight procfs file. Signed-off-by: Gregoire Pichon Intel-bug-id:

[PATCH 33/41] staging: lustre: lov: use obd_get_info() to get def/max LOV EA sizes

From: John L. Hammond Use obd_get_info() to get the default and maximum LOV EA sizes (along with maximum cookiesize) from LOV. Remove the then unused function obd_size_diskmd() and the unused get info key KEY_LOVDESC. When computing the maximum LOV EA size use the active OST count

[PATCH 39/41] staging: lustre: osc: remove remaining bits for capa support

From: John L. Hammond With capa support removed from the OSC layer a few more bits can be cleaned up. Convert the OBD getattr and setattr paths to use struct obdo rather than struct obd_info. Remove the oi_policy, oi_oa, and oi_capa members from struct obd_info. Signed-off-by: John L. Hammond

[PATCH 21/41] staging: lustre: mdc: Removed unneeded NULL check

From: Henri Doreau Do not bother checking the return value of changelog_kuc_hdr() against NULL since this value was dereferenced earlier. Signed-off-by: Henri Doreau Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4189 Reviewed-on: http://review.whamcloud.com/12919 Reviewed-by: John L.

[PATCH 37/41] staging: lustre: lov: copy_to_user uses wrong casting

With certain version of gcc lov_obd.c failes to compile with the following warning. In function copy_to_user, inlined from lov_iocontrol at lustre/lustre/lov/lov_obd.c:1168: ./arch/x86/include/asm/uaccess.h:735: error: call to __copy_to_user_overflow declared with attribute warning:

[PATCH 29/41] staging: lustre: ptlrpc: Move NRS structures out of lustre_net.h

From: Chris Horn NRS specific structures are not needed in the rest of the PtlRPC code. It is more appropriate for these structures to be defined in a separate header. This commit creates a lustre_nrs.h header for the generic NRS structures, and policy-specific headers for the various NRS

[PATCH 35/41] staging: lustre: hsm: Use file lease to implement migration

From: Henri Doreau Implement non-blocking migration based on exclusive open instead of group lock. Implemented exclusive close operation to atomically put a lease, swap two layouts and close a file. This allows race-free migrations. Make the caller responsible for retrying on failure (EBUSY,

[PATCH 27/41] staging: lustre: llite: add cl_object_maxbytes()

From: John L. Hammond Add cl_object_maxbytes() to return the maximum supported size of a cl_object. Remove the lli_maxbytes member from struct ll_inode_info. Change the lsm_maxbytes member of struct lov_stripe_md from __u64 to loff_t. Correct the computation of

[PATCH 40/41] staging: lustre: lov: move LSM to LOV layer

From: John L. Hammond Move the definition of struct lov_stripe_md along with supporting functions from obd.h to lov_internal.h. Remove the unused functions obd_packmd() and obd_free_diskmd(). Simplify lov_obd_packmd() according to the reduced use cases and rename it

[PATCH 36/41] staging: lustre: ldlm: interval tree search in ldlm_lock_match()

From: Vitaly Fertman replace the linear search by interval_tree one for granted list in ldlm_lock_match() Signed-off-by: Vitaly Fertman Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5739 Xyratex-bug-id: MRP-2089 Reviewed-on:

[PATCH 23/41] staging: lustre: mgc: MGC should retry for invalid import

From: wang di After http://review.whamcloud.com/#/c/9967/ is landed, mgc does not wait the import connected(state = FULL), then enqueue and retrieve config log, which will cause the mount process to fail, especially if the mgc is shared by multiple targets. So once mgc enqueue

[PATCH 32/41] staging: lustre: llite: restart short read/write for normal IO

From: Bobi Jam If normal IO got short read/write, we'd restart the IO from where we've accomplished until we meet EOF or error happens. Signed-off-by: Bobi Jam Signed-off-by: Jinshan Xiong Intel-bug-id:

[PATCH 28/41] staging: lustre: hsm: make HSM modification requests replayable

From: Mikhail Pershin There are several HSM requests which modify data on server and reply on Lustre recovery, e.g. they should replay changes in case of recovery. Patch allows such requests to be replayed in recovery time and they are issued from client using

[PATCH 27/41] staging: lustre: llite: add cl_object_maxbytes()

From: John L. Hammond Add cl_object_maxbytes() to return the maximum supported size of a cl_object. Remove the lli_maxbytes member from struct ll_inode_info. Change the lsm_maxbytes member of struct lov_stripe_md from __u64 to loff_t. Correct the computation of lsm_maxbytes in the released

[PATCH 40/41] staging: lustre: lov: move LSM to LOV layer

From: John L. Hammond Move the definition of struct lov_stripe_md along with supporting functions from obd.h to lov_internal.h. Remove the unused functions obd_packmd() and obd_free_diskmd(). Simplify lov_obd_packmd() according to the reduced use cases and rename it lov_packmd(). Signed-off-by:

[PATCH 36/41] staging: lustre: ldlm: interval tree search in ldlm_lock_match()

From: Vitaly Fertman replace the linear search by interval_tree one for granted list in ldlm_lock_match() Signed-off-by: Vitaly Fertman Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5739 Xyratex-bug-id: MRP-2089 Reviewed-on: http://review.whamcloud.com/12294 Reviewed-by: Andreas Dilger

[PATCH 23/41] staging: lustre: mgc: MGC should retry for invalid import

From: wang di After http://review.whamcloud.com/#/c/9967/ is landed, mgc does not wait the import connected(state = FULL), then enqueue and retrieve config log, which will cause the mount process to fail, especially if the mgc is shared by multiple targets. So once mgc enqueue is failed, it will

[PATCH 32/41] staging: lustre: llite: restart short read/write for normal IO

From: Bobi Jam If normal IO got short read/write, we'd restart the IO from where we've accomplished until we meet EOF or error happens. Signed-off-by: Bobi Jam Signed-off-by: Jinshan Xiong Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6389 Reviewed-on: http://review.whamcloud.com/14123

[PATCH 28/41] staging: lustre: hsm: make HSM modification requests replayable

From: Mikhail Pershin There are several HSM requests which modify data on server and reply on Lustre recovery, e.g. they should replay changes in case of recovery. Patch allows such requests to be replayed in recovery time and they are issued from client using mdc_rpc_lock to serialize them and

Re: [LKP] [lkp] [sctp] a6c2f79287: netperf.Throughput_Mbps -37.2% regression

On Fri, Sep 30, 2016 at 3:05 PM, Aaron Lu wrote: > On 08/23/2016 05:44 AM, Marcelo Ricardo Leitner wrote: >> Em 19-08-2016 04:24, Aaron Lu escreveu: >>> On Fri, Aug 19, 2016 at 04:19:39AM -0300, Marcelo Ricardo Leitner wrote: Hi, Em 19-08-2016 02:29, Aaron Lu

[PATCH 41/41] staging: lustre: echo: request pages in batches

From: Alex Zhuravlev rather than fetch them one by one. Signed-off-by: Alex Zhuravlev Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5278 Reviewed-on: http://review.whamcloud.com/13612 Reviewed-by: Nathaniel Clark

  1   2   3   4   >