Re: [PATCH] Btrfs: use BUG_ON
On Thu, 10 Jul 2014, Satoru Takeuchi wrote:
> Hi Himangi,
>
> (2014/07/09 7:21), Himangi Saraogi wrote:
> > Use BUG_ON(x) rather than if(x) BUG();
> >
> > The semantic patch that fixes this problem is as follows:
> >
> > //
> > @@ identifier x; @@
> > -if (x) BUG();
> > +BUG_ON(x);
> > //
>
> Strictly speaking, BUG_ON() is "if (unlikely(x)) BUG".
> Anyway, I consider that put this condition in unlikely()
> in this case is good.
>
> BTW, there are many "if BUG()" case under fs/btrfs.
> How about fix all of them?
>
> ===
> $ grep -rnH -B 1 "BUG()" fs/btrfs | grep -A 1 'if.*('
> fs/btrfs/inode.c-6318-} else if (create &&
> PageUptodate(page)) {
In the past, BUG_ON (and BUG) could have a definition that would just do
nothing. In that case, the call to PageUptodate would go away. The
function may do a read barrier, so that could be undesirable.
But now I don't see any definition of BUG_ON that discards the condition.
So Himangi, you can discard the requirement that the tested expression be
an identifier in the semantic patch, and just allow any expression:
-if(e) BUG();
+BUG_ON(e);
julia
> fs/btrfs/inode.c:6319:BUG();
> --
> fs/btrfs/volumes.c-2626- else if (ret)
> fs/btrfs/volumes.c:2627: BUG(); # <- your patch
> fixes it.
> --
> fs/btrfs/volumes.c-3092- if (ret == 0)
> fs/btrfs/volumes.c:3093: BUG(); /* FIXME break ? */
> --
> fs/btrfs/raid56.c-2048- if (rbio->faila == -1) {
> fs/btrfs/raid56.c:2049: BUG();
> ===
>
> Thanks,
> Satoru
>
> >
> > Signed-off-by: Himangi Saraogi
> > Acked-by: Julia Lawall
> > ---
> > fs/btrfs/volumes.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> > index 6104676..63e746e 100644
> > --- a/fs/btrfs/volumes.c
> > +++ b/fs/btrfs/volumes.c
> > @@ -2623,8 +2623,8 @@ again:
> >found_key.offset);
> > if (ret == -ENOSPC)
> > failed++;
> > - else if (ret)
> > - BUG();
> > + else
> > + BUG_ON(ret);
> > }
> >
> > if (found_key.offset == 0)
> >
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] staging: rtl8723au: core: rtw_ap.c - removed NULL pointer check before kfree()
From: Anil Belur - as kfree() internally check for NULL, additional check it not required. Signed-off-by: Anil Belur --- drivers/staging/rtl8723au/core/rtw_ap.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/rtl8723au/core/rtw_ap.c b/drivers/staging/rtl8723au/core/rtw_ap.c index c8700b3..8714ae3 100644 --- a/drivers/staging/rtl8723au/core/rtw_ap.c +++ b/drivers/staging/rtl8723au/core/rtw_ap.c @@ -1270,8 +1270,7 @@ static void update_bcn_wps_ie(struct rtw_adapter *padapter) pnetwork->IELength = wps_offset + (wps_ielen+2) + remainder_ielen; } - if (pbackup_remainder_ie) - kfree(pbackup_remainder_ie); + kfree(pbackup_remainder_ie); } static void update_bcn_p2p_ie(struct rtw_adapter *padapter) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] staging: rtl8723au: core: rtw_cmd.c - removed NULL pointer check before kfree()
From: Anil Belur
- as kfree() internally checks for NULL, additional check it not
required.
Signed-off-by: Anil Belur
---
drivers/staging/rtl8723au/core/rtw_cmd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8723au/core/rtw_cmd.c
b/drivers/staging/rtl8723au/core/rtw_cmd.c
index 1696cb8..b160780 100644
--- a/drivers/staging/rtl8723au/core/rtw_cmd.c
+++ b/drivers/staging/rtl8723au/core/rtw_cmd.c
@@ -516,8 +516,7 @@ int rtw_joinbss_cmd23a(struct rtw_adapter *padapter,
psecnetwork = >sec_bss;
if (!psecnetwork) {
- if (pcmd)
- kfree(pcmd);
+ kfree(pcmd);
res = _FAIL;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] phy: phy-samsung-usb2: Change phy power on/power off sequence
On Thursday 10 July 2014 03:06 AM, Greg KH wrote: > On Tue, Jul 08, 2014 at 11:42:42AM +0530, Kishon Vijay Abraham I wrote: >> Hi Greg, >> >> On Tuesday 08 July 2014 07:14 AM, Greg KH wrote: >>> On Mon, Jul 07, 2014 at 12:18:20PM +0530, Kishon Vijay Abraham I wrote: From: Kamil Debski The Exynos4412 USB 2.0 PHY hardware differs from the description provided in the documentation. Some register bits have different function. This patch fixes the defines of register bits and changes the way how phys are powered on and off. Signed-off-by: Kamil Debski Tested-by: Marek Szyprowski Tested-by: Daniel Drake Signed-off-by: Kishon Vijay Abraham I --- drivers/phy/phy-exynos4x12-usb2.c | 112 + drivers/phy/phy-exynos5250-usb2.c |2 - drivers/phy/phy-samsung-usb2.h|3 +- 3 files changed, 77 insertions(+), 40 deletions(-) >>> >>> This doesn't look like a regression fix for 3.16-final, it looks like a >>> "new feature" to me :( >> >> This patch was primarily due to the incorrectly documented register bits in >> the >> manual. So thought this would qualify as fix and should be in 3.16. > > Sorry, that's really big for a patch so late in the -rc cycle. There > should only be real regressions or reported bugfixes now. Okay sure. Will send it. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 2/8] Drivers: scsi: storvsc: Set cmd_per_lun to reflect value supported by the Host
Set cmd_per_lun to reflect value supported by the Host.
In this version of the patch I have addressed comments from
Christoph Hellwig
Signed-off-by: K. Y. Srinivasan
Cc:
---
drivers/scsi/storvsc_drv.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 8938b13..cebcef7 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1690,7 +1690,7 @@ static struct scsi_host_template scsi_driver = {
.slave_alloc = storvsc_device_alloc,
.slave_destroy =storvsc_device_destroy,
.slave_configure = storvsc_device_configure,
- .cmd_per_lun = 1,
+ .cmd_per_lun = 255,
.can_queue =STORVSC_MAX_IO_REQUESTS*STORVSC_MAX_TARGETS,
.this_id = -1,
/* no use setting to 0 since ll_blk_rw reset it to 1 */
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 3/8] Drivers: scsi: storvsc: Filter commands based on the storage protocol version
Going forward it is possible that some of the commands that are not currently
implemented will be implemented on future Windows hosts. Even if they are not
implemented, we are told the host will corrrectly handle unsupported
commands (by returning appropriate return code and sense information).
Make command filtering depend on the host version.
In this version of the patch I have addressed comments from
Christoph Hellwig
Signed-off-by: K. Y. Srinivasan
Cc:
---
drivers/scsi/storvsc_drv.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index cebcef7..8f8847e 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1553,9 +1553,19 @@ static int storvsc_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *scmnd)
struct vmscsi_request *vm_srb;
struct stor_mem_pools *memp = scmnd->device->hostdata;
- if (!storvsc_scsi_cmd_ok(scmnd)) {
- scmnd->scsi_done(scmnd);
- return 0;
+ if (vmstor_current_major <= VMSTOR_WIN8_MAJOR) {
+ /*
+* On legacy hosts filter unimplemented commands.
+* Future hosts are expected to correctly handle
+* unsupported commands. Furthermore, it is
+* possible that some of the currently
+* unsupported commands maybe supported in
+* future versions of the host.
+*/
+ if (!storvsc_scsi_cmd_ok(scmnd)) {
+ scmnd->scsi_done(scmnd);
+ return 0;
+ }
}
request_size = sizeof(struct storvsc_cmd_request);
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm: LLVMLinux: use static inline in ARM ftrace.h
From: Behan Webster
With compilers which follow the C99 standard (like modern versions of gcc and
clang), "extern inline" does the wrong thing (emits code for an externally
linkable version of the inline function). In this case using static inline
and removing the NULL version of return_address in return_address.c does
the right thing.
Signed-off-by: Behan Webster
Reviewed-by: Mark Charlebois
Acked-by: Steven Rostedt
CC: li...@arm.linux.org.uk
---
arch/arm/include/asm/ftrace.h| 2 +-
arch/arm/kernel/return_address.c | 5 -
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h
index 39eb16b..bfe2a2f 100644
--- a/arch/arm/include/asm/ftrace.h
+++ b/arch/arm/include/asm/ftrace.h
@@ -45,7 +45,7 @@ void *return_address(unsigned int);
#else
-extern inline void *return_address(unsigned int level)
+static inline void *return_address(unsigned int level)
{
return NULL;
}
diff --git a/arch/arm/kernel/return_address.c b/arch/arm/kernel/return_address.c
index fafedd8..f6aa84d 100644
--- a/arch/arm/kernel/return_address.c
+++ b/arch/arm/kernel/return_address.c
@@ -63,11 +63,6 @@ void *return_address(unsigned int level)
#warning "TODO: return_address should use unwind tables"
#endif
-void *return_address(unsigned int level)
-{
- return NULL;
-}
-
#endif /* if defined(CONFIG_FRAME_POINTER) && !defined(CONFIG_ARM_UNWIND) /
else */
EXPORT_SYMBOL_GPL(return_address);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 6/8] Drivers: scsi: storvsc: Implement an abort handler
Implement a simple abort handler. The host does not support "Abort"; just
ensure that all inflight I/Os have been accounted for.
In this version of the patch I have addressed comments from
Christoph Hellwig
Signed-off-by: K. Y. Srinivasan
---
drivers/scsi/storvsc_drv.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 7b99f38..443a1c2 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1521,6 +1521,27 @@ static int storvsc_host_reset_handler(struct scsi_cmnd
*scmnd)
return SUCCESS;
}
+static int storvsc_host_abort_handler(struct scsi_cmnd *scmnd)
+{
+ struct hv_host_device *host_dev = shost_priv(scmnd->device->host);
+ struct hv_device *device = host_dev->dev;
+
+ struct storvsc_device *stor_device;
+
+
+ stor_device = get_out_stor_device(device);
+ if (!stor_device)
+ return FAILED;
+
+ /*
+* Just wait for all in flight I/O's to complete.
+*/
+
+ storvsc_wait_to_drain(stor_device);
+
+ return SUCCESS;
+}
+
static bool storvsc_scsi_cmd_ok(struct scsi_cmnd *scmnd)
{
bool allowed = true;
@@ -1700,6 +1721,7 @@ static struct scsi_host_template scsi_driver = {
.bios_param = storvsc_get_chs,
.queuecommand = storvsc_queuecommand,
.eh_host_reset_handler =storvsc_host_reset_handler,
+ .eh_abort_handler = storvsc_host_abort_handler,
.slave_alloc = storvsc_device_alloc,
.slave_destroy =storvsc_device_destroy,
.slave_configure = storvsc_device_configure,
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 5/8] Drivers: scsi: storvsc: Fix a bug in the handling of SRB status flags
SRB status can have additional information. Mask these out before processing
SRB status.
In this version of the patch I have addressed comments from
Christoph Hellwig
Signed-off-by: K. Y. Srinivasan
Cc:
---
drivers/scsi/storvsc_drv.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 7e8a642..7b99f38 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -299,11 +299,14 @@ enum storvsc_request_type {
*/
#define SRB_STATUS_AUTOSENSE_VALID 0x80
+#define SRB_STATUS_QUEUE_FROZEN0x40
#define SRB_STATUS_INVALID_LUN 0x20
#define SRB_STATUS_SUCCESS 0x01
#define SRB_STATUS_ABORTED 0x02
#define SRB_STATUS_ERROR 0x04
+#define SRB_STATUS(status) \
+ (status & ~(SRB_STATUS_AUTOSENSE_VALID | SRB_STATUS_QUEUE_FROZEN))
/*
* This is the end of Protocol specific defines.
*/
@@ -1004,7 +1007,7 @@ static void storvsc_handle_error(struct vmscsi_request
*vm_srb,
void (*process_err_fn)(struct work_struct *work);
bool do_work = false;
- switch (vm_srb->srb_status) {
+ switch (SRB_STATUS(vm_srb->srb_status)) {
case SRB_STATUS_ERROR:
/*
* If there is an error; offline the device since all
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 4/8] Drivers: scsi: storvsc: Fix a bug in handling VMBUS protocol version
Based on the negotiated VMBUS protocol version, we adjust the size of the
storage
protocol messages. The two sizes we currently handle are pre-win8 and post-win8.
In WS2012 R2, we are negotiating higher VMBUS protocol version than the win8
version. Make adjustments to correctly handle this.
In this version of the patch I have addressed comments from
Christoph Hellwig
Signed-off-by: K. Y. Srinivasan
Cc:
---
drivers/scsi/storvsc_drv.c | 17 ++---
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 8f8847e..7e8a642 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1752,19 +1752,22 @@ static int storvsc_probe(struct hv_device *device,
* set state to properly communicate with the host.
*/
- if (vmbus_proto_version == VERSION_WIN8) {
- sense_buffer_size = POST_WIN7_STORVSC_SENSE_BUFFER_SIZE;
- vmscsi_size_delta = 0;
- vmstor_current_major = VMSTOR_WIN8_MAJOR;
- vmstor_current_minor = VMSTOR_WIN8_MINOR;
- } else {
+ switch (vmbus_proto_version) {
+ case VERSION_WS2008:
+ case VERSION_WIN7:
sense_buffer_size = PRE_WIN8_STORVSC_SENSE_BUFFER_SIZE;
vmscsi_size_delta = sizeof(struct vmscsi_win8_extension);
vmstor_current_major = VMSTOR_WIN7_MAJOR;
vmstor_current_minor = VMSTOR_WIN7_MINOR;
+ break;
+ default:
+ sense_buffer_size = POST_WIN7_STORVSC_SENSE_BUFFER_SIZE;
+ vmscsi_size_delta = 0;
+ vmstor_current_major = VMSTOR_WIN8_MAJOR;
+ vmstor_current_minor = VMSTOR_WIN8_MINOR;
+ break;
}
-
if (dev_id->driver_data == SFC_GUID)
scsi_driver.can_queue = (STORVSC_MAX_IO_REQUESTS *
STORVSC_FC_MAX_TARGETS);
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 8/8] drivers: scsi: storvsc: Correctly handle TEST_UNIT_READY failure
On some Windows hosts on FC SANs, TEST_UNIT_READY can return SRB_STATUS_ERROR. Correctly handle this. In this version of the patch I have addressed comments from Christoph Hellwig Signed-off-by: K. Y. Srinivasan Cc: --- drivers/scsi/storvsc_drv.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index 84b9b39..6fed0dd 100644 --- a/drivers/scsi/storvsc_drv.c +++ b/drivers/scsi/storvsc_drv.c @@ -1020,6 +1020,13 @@ static void storvsc_handle_error(struct vmscsi_request *vm_srb, case ATA_12: set_host_byte(scmnd, DID_PASSTHROUGH); break; + /* +* On Some Windows hosts TEST_UNIT_READY command can return +* SRB_STATUS_ERROR, let the upper level code deal with it +* based on the sense information. +*/ + case TEST_UNIT_READY: + break; default: set_host_byte(scmnd, DID_TARGET_FAILURE); } -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 7/8] drivers: scsi: storvsc: Set srb_flags in all cases
Correctly set SRB flags for all valid I/O directions. Some IHV drivers on the
Windows host require this.
Signed-off-by: K. Y. Srinivasan
Cc:
---
drivers/scsi/storvsc_drv.c | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 443a1c2..84b9b39 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1614,26 +1614,24 @@ static int storvsc_queuecommand(struct Scsi_Host *host,
struct scsi_cmnd *scmnd)
vm_srb = _request->vstor_packet.vm_srb;
vm_srb->win8_extension.time_out_value = 60;
+ vm_srb->win8_extension.srb_flags |=
+ (SRB_FLAGS_QUEUE_ACTION_ENABLE |
+ SRB_FLAGS_DISABLE_SYNCH_TRANSFER);
/* Build the SRB */
switch (scmnd->sc_data_direction) {
case DMA_TO_DEVICE:
vm_srb->data_in = WRITE_TYPE;
vm_srb->win8_extension.srb_flags |= SRB_FLAGS_DATA_OUT;
- vm_srb->win8_extension.srb_flags |=
- (SRB_FLAGS_QUEUE_ACTION_ENABLE |
- SRB_FLAGS_DISABLE_SYNCH_TRANSFER);
break;
case DMA_FROM_DEVICE:
vm_srb->data_in = READ_TYPE;
vm_srb->win8_extension.srb_flags |= SRB_FLAGS_DATA_IN;
- vm_srb->win8_extension.srb_flags |=
- (SRB_FLAGS_QUEUE_ACTION_ENABLE |
- SRB_FLAGS_DISABLE_SYNCH_TRANSFER);
break;
default:
vm_srb->data_in = UNKNOWN_TYPE;
- vm_srb->win8_extension.srb_flags = 0;
+ vm_srb->win8_extension.srb_flags |= (SRB_FLAGS_DATA_IN |
+SRB_FLAGS_DATA_OUT);
break;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 1/8] Drivers: scsi: storvsc: Change the limits to reflect the values on the host
Hyper-V hosts can support multiple targets and multiple channels and larger
number of
LUNs per target. Update the code to reflect this. With this patch we can
correctly
enumerate all the paths in a multi-path storage environment.
In this version of the patch I have addressed comments from
Christoph Hellwig
Signed-off-by: K. Y. Srinivasan
Cc:
---
drivers/scsi/storvsc_drv.c | 47 +---
1 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 9969fa1..8938b13 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -330,17 +330,17 @@ static int storvsc_timeout = 180;
static void storvsc_on_channel_callback(void *context);
-/*
- * In Hyper-V, each port/path/target maps to 1 scsi host adapter. In
- * reality, the path/target is not used (ie always set to 0) so our
- * scsi host adapter essentially has 1 bus with 1 target that contains
- * up to 256 luns.
- */
-#define STORVSC_MAX_LUNS_PER_TARGET64
-#define STORVSC_MAX_TARGETS1
-#define STORVSC_MAX_CHANNELS 1
+#define STORVSC_MAX_LUNS_PER_TARGET255
+#define STORVSC_MAX_TARGETS2
+#define STORVSC_MAX_CHANNELS 8
+#define STORVSC_FC_MAX_LUNS_PER_TARGET 255
+#define STORVSC_FC_MAX_TARGETS 128
+#define STORVSC_FC_MAX_CHANNELS8
+#define STORVSC_IDE_MAX_LUNS_PER_TARGET64
+#define STORVSC_IDE_MAX_TARGETS1
+#define STORVSC_IDE_MAX_CHANNELS 1
struct storvsc_cmd_request {
struct list_head entry;
@@ -1691,7 +1691,6 @@ static struct scsi_host_template scsi_driver = {
.slave_destroy =storvsc_device_destroy,
.slave_configure = storvsc_device_configure,
.cmd_per_lun = 1,
- /* 64 max_queue * 1 target */
.can_queue =STORVSC_MAX_IO_REQUESTS*STORVSC_MAX_TARGETS,
.this_id = -1,
/* no use setting to 0 since ll_blk_rw reset it to 1 */
@@ -1756,6 +1755,9 @@ static int storvsc_probe(struct hv_device *device,
}
+ if (dev_id->driver_data == SFC_GUID)
+ scsi_driver.can_queue = (STORVSC_MAX_IO_REQUESTS *
+STORVSC_FC_MAX_TARGETS);
host = scsi_host_alloc(_driver,
sizeof(struct hv_host_device));
if (!host)
@@ -1789,12 +1791,25 @@ static int storvsc_probe(struct hv_device *device,
host_dev->path = stor_device->path_id;
host_dev->target = stor_device->target_id;
- /* max # of devices per target */
- host->max_lun = STORVSC_MAX_LUNS_PER_TARGET;
- /* max # of targets per channel */
- host->max_id = STORVSC_MAX_TARGETS;
- /* max # of channels */
- host->max_channel = STORVSC_MAX_CHANNELS - 1;
+ switch (dev_id->driver_data) {
+ case SFC_GUID:
+ host->max_lun = STORVSC_FC_MAX_LUNS_PER_TARGET;
+ host->max_id = STORVSC_FC_MAX_TARGETS;
+ host->max_channel = STORVSC_FC_MAX_CHANNELS - 1;
+ break;
+
+ case SCSI_GUID:
+ host->max_lun = STORVSC_MAX_LUNS_PER_TARGET;
+ host->max_id = STORVSC_MAX_TARGETS;
+ host->max_channel = STORVSC_MAX_CHANNELS - 1;
+ break;
+
+ default:
+ host->max_lun = STORVSC_IDE_MAX_LUNS_PER_TARGET;
+ host->max_id = STORVSC_IDE_MAX_TARGETS;
+ host->max_channel = STORVSC_IDE_MAX_CHANNELS - 1;
+ break;
+ }
/* max cmd length */
host->max_cmd_len = STORVSC_MAX_CMD_LEN;
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 0/8] Drivers: scsi: storvsc: Bug fixes and improvements
In this patch set I have fixed a few bugs and implemented some enhancements. In this version of the patch I have addressed comments from Christoph Hellwig K. Y. Srinivasan (8): Drivers: scsi: storvsc: Change the limits to reflect the values on the host Drivers: scsi: storvsc: Set cmd_per_lun to reflect value supported by the Host Drivers: scsi: storvsc: Filter commands based on the storage protocol version Drivers: scsi: storvsc: Fix a bug in handling VMBUS protocol version Drivers: scsi: storvsc: Fix a bug in the handling of SRB status flags Drivers: scsi: storvsc: Implement an abort handler drivers: scsi: storvsc: Set srb_flags in all cases drivers: scsi: storvsc: Correctly handle TEST_UNIT_READY failure drivers/scsi/storvsc_drv.c | 128 1 files changed, 93 insertions(+), 35 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] ARM: SPEAr1310 PCIe updates
On 10 July 2014 10:47, Olof Johansson wrote: >> I didn't sign-off because I haven't even looked closed at many of the >> patches around PCI and Acked whatever I could understand. > > Thanks, good to know that the series hasn't been fully reviewed. That > makes me even more hesitant to apply it at the moment, given all the > other issues around it. Its not that the series hasn't been fully reviewed, it is. Arnd has reviewed and Acked the complete series. I have Acked SPEAr specific parts and Bjorn have Acked PCI specific stuff. >> But yeah, this committer thing is what I missed. Because of that I might >> be required to signoff it. > > Anyone touching the patch, forwarding it or applying it needs to sign > off. It's quite simple, and well documented. Yeah, my mistake. Accepted. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] usb: usb3503: add PM functions
The usb3503 needs to switch to standby mode while suspending and should
switch to hub mode when resumed. Also we can control clock on PM
function.
Signed-off-by: Joonyoung Shim
---
drivers/usb/misc/usb3503.c | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index 652855b..47cb143 100644
--- a/drivers/usb/misc/usb3503.c
+++ b/drivers/usb/misc/usb3503.c
@@ -149,8 +149,6 @@ static int usb3503_switch_mode(struct usb3503 *hub, enum
usb3503_mode mode)
case USB3503_MODE_STANDBY:
usb3503_reset(hub, 0);
-
- hub->mode = mode;
dev_info(dev, "switched to STANDBY mode\n");
break;
@@ -347,6 +345,37 @@ static int usb3503_platform_probe(struct platform_device
*pdev)
return usb3503_probe(hub);
}
+#ifdef CONFIG_PM_SLEEP
+static int usb3503_i2c_suspend(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct usb3503 *hub = i2c_get_clientdata(client);
+
+ usb3503_switch_mode(hub, USB3503_MODE_STANDBY);
+
+ if (hub->clk)
+ clk_disable_unprepare(hub->clk);
+
+ return 0;
+}
+
+static int usb3503_i2c_resume(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct usb3503 *hub = i2c_get_clientdata(client);
+
+ if (hub->clk)
+ clk_prepare_enable(hub->clk);
+
+ usb3503_switch_mode(hub, hub->mode);
+
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(usb3503_i2c_pm_ops, usb3503_i2c_suspend,
+ usb3503_i2c_resume);
+
static const struct i2c_device_id usb3503_id[] = {
{ USB3503_I2C_NAME, 0 },
{ }
@@ -365,6 +394,7 @@ MODULE_DEVICE_TABLE(of, usb3503_of_match);
static struct i2c_driver usb3503_i2c_driver = {
.driver = {
.name = USB3503_I2C_NAME,
+ .pm = _i2c_pm_ops,
.of_match_table = of_match_ptr(usb3503_of_match),
},
.probe = usb3503_i2c_probe,
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] USB: add reset resume quirk for usb3503
The usb device will autoresume from choose_wakeup() if it is
autosuspended with the wrong wakeup setting, but below errors occur
because usb3503 misc driver will switch to standby mode when suspended.
As add USB_QUIRK_RESET_RESUME, it can stop setting wrong wakeup from
autosuspend_check().
[7.734717] usb 1-3: reset high-speed USB device number 3 using exynos-ehci
[7.854658] usb 1-3: device descriptor read/64, error -71
[8.079657] usb 1-3: device descriptor read/64, error -71
[8.294664] usb 1-3: reset high-speed USB device number 3 using exynos-ehci
[8.414658] usb 1-3: device descriptor read/64, error -71
[8.639657] usb 1-3: device descriptor read/64, error -71
[8.854667] usb 1-3: reset high-speed USB device number 3 using exynos-ehci
[9.264598] usb 1-3: device not accepting address 3, error -71
[9.374655] usb 1-3: reset high-speed USB device number 3 using exynos-ehci
[9.784601] usb 1-3: device not accepting address 3, error -71
[9.784838] usb usb1-port3: device 1-3 not suspended yet
Signed-off-by: Joonyoung Shim
---
drivers/usb/core/quirks.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 739ee8e..2c9ba407 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -152,6 +152,9 @@ static const struct usb_device_id usb_quirk_list[] = {
/* INTEL VALUE SSD */
{ USB_DEVICE(0x8086, 0xf1a5), .driver_info = USB_QUIRK_RESET_RESUME },
+ /* USB3503 */
+ { USB_DEVICE(0x0424, 0x3503), .driver_info = USB_QUIRK_RESET_RESUME },
+
{ } /* terminating entry must be last */
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Wed, Jul 9, 2014
Greetings, I am a Financial Consultant with the Capital One United State I am in control of privately owned funds placed for long term investments. Our interest is to fund projects in form of Loan. Viable projects ranging from any amount would be funded at a guaranteed 3% Fixed Interest Rate per annum. If you have credible projects for investments or business clients in need of funds to expand existing projects, we would be obliged to work with you. Regards, --- Stacey G Lippel + 1 917 765 0459 === Grüße, Ich bin eine finanzielle Berater mit der Capital One United State Ich habe unter Kontrolle der Privatbesitz Gelder für langfristige Investitionen. Unser Interesse ist es, Projekte in Form von Darlehen zu finanzieren. Tragfähige Projekte von jede Menge würde bei einer garantierten 3 % finanziert werden Fixed Zinssatz pro Jahr. Haben Sie glaubwürdige Projekte für Investitionen oder Businesskunden benötigen Mittel, bestehende Projekte zu erweitern, würden wir verpfl ichtet, arbeiten mit Ihnen. Grüße, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] Fix permission checking by NFS client for open-create with mode 000
> On Thu, Jul 10, 2014 at 12:26 AM, Frank Filz
> wrote:
> >> On Wed, Jul 9, 2014 at 7:06 PM, Trond Myklebust
> >> wrote:
> >> > On Wed, Jul 9, 2014 at 6:42 PM, Frank Filz
> >> >
> >> wrote:
> >> >>> On Wed, Jul 9, 2014 at 5:54 PM, Frank S. Filz
> >> >>>
> >> >>> wrote:
> >> >>> > From: "Frank S. Filz"
> >> >>> >
> >> >>> > The NFS v4 client sends a COMPOUND with an OPEN and an
> ACCESS.
> >> >>> >
> >> >>> > The ACCESS is required to verify an open for read is actually
> >> >>> > allowed because RFC 3530 indicates OPEN for read only must
> >> >>> > succeed for an execute only file.
> >> >>> >
> >> >>> > The old code expected to have read access if the requested
> >> >>> > access was O_RDWR.
> >> >>> >
> >> >>> > We can expect the OPEN to properly permission check as long as
> >> >>> > the open is O_WRONLY or O_RDWR.
> >> >>> >
> >> >>> > Signed-off-by: Frank S. Filz
> >> >>> > ---
> >> >>> > fs/nfs/nfs4proc.c | 25 -
> >> >>> > 1 file changed, 20 insertions(+), 5 deletions(-)
> >> >>> >
> >> >>> > diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index
> >> >>> > 4bf3d97..9742054 100644
> >> >>> > --- a/fs/nfs/nfs4proc.c
> >> >>> > +++ b/fs/nfs/nfs4proc.c
> >> >>> > @@ -1966,15 +1966,30 @@ static int nfs4_opendata_access(struct
> >> >>> rpc_cred *cred,
> >> >>> > return 0;
> >> >>> >
> >> >>> > mask = 0;
> >> >>> > - /* don't check MAY_WRITE - a newly created file may not have
> >> >>> > -* write mode bits, but POSIX allows the creating process to
> write.
> >> >>> > -* use openflags to check for exec, because fmode won't
> >> >>> > -* always have FMODE_EXEC set when file open for exec. */
> >> >>> > + /* Don't trust the permission check on OPEN if open for
> >> >>> > + exec or
> >> for
> >> >>> > +* read only. Since FMODE_EXEC doesn't go across the
> >> >>> > + wire, the
> >> server
> >> >>> > +* has no way to distinguish between an open to read an
> >> >>> > + executable
> >> >>> file
> >> >>> > +* and an open to read a readable file. Write access is
> >> >>> > + properly
> >> checked
> >> >>> > +* and permission SHOULD always be granted if the file
> >> >>> > + was created as
> >> >>> a
> >> >>> > +* result of this OPEN, no matter what mode the file
> >> >>> > + was created
> >> with.
> >> >>> > +*
> >> >>> > +* NOTE: If the case of a OPEN CREATE READ-ONLY with a
> >> >>> > + mode that
> >> >>> does
> >> >>> > +* not allow read access, this test will produce an
> >> >>> > incorrect
> >> >>> > +* EACCES error.
> >> >>> > +*/
> >> >>> > if (openflags & __FMODE_EXEC) {
> >> >>> > /* ONLY check for exec rights */
> >> >>> > mask = MAY_EXEC;
> >> >>> > - } else if (fmode & FMODE_READ)
> >> >>> > + } else if (!(fmode & FMODE_WRITE)) {
> >> >>> > + /* In case the file was execute only, check for read
> permission
> >> >>> > +* ONLY if write access was not requested. It is
> >> >>> > expected
> that
> >> >>> > +* an OPEN for write will fail if the file is
> >> >>> > execute only.
> >> >>> > +* Note that if the file was newly created, the fmode
> SHOULD
> >> >>> > +* include FMODE_WRITE, especially if the file will
> >> >>> > be
> created
> >> >>> > +* with a restrictive mode.
> >> >>> > +*/
> >> >>> > mask = MAY_READ;
> >> >>> > + }
> >> >>>
> >> >>> This looks wrong. AFAICS it will allow you to open an existing
> >> >>> file which has - wx permissions (i.e. no read permissions) for
> O_RDWR.
> >> >>> That should not be permitted under POSIX rules.
> >> >>
> >> >> The server permission checks the OPEN, this only affects the
> >> >> subsequent
> >> ACCESS.
> >> >>
> >> >> The server will fail the OPEN with NFS4_ERR_ACCESS if the open is
> >> >> for
> >> read/write and the file has write-execute permission.
> >> >
> >> > RFC3530bis draft 33 (6.2.1.3.1. Discussion of Mask Attributes)
> >> > states that for both the OPEN and the READ operations, "Servers
> >> > SHOULD allow a user the ability to read the data of the file when
> >> > only the ACE4_EXECUTE access mask bit is allowed". RFC5561 has the
> >> > same language.
> >>
> >> Oops. Sorry, the correct sub-sub-sub-sub-paragraph is this one:
> >>
> >> Permission to execute a file.
> >>
> >> Servers SHOULD allow a user the ability to read the data of the
> >> file when only the ACE4_EXECUTE access mask bit is allowed.
> >> This is because there is no way to execute a file without
> >> reading the contents. Though a server may treat ACE4_EXECUTE
> >> and ACE4_READ_DATA bits identically when deciding to permit a
> >> READ operation, it SHOULD still allow the two bits to be set
> >> independently in ACLs, and MUST distinguish
Re: [GIT PULL] ARM: SPEAr1310 PCIe updates
On Wed, Jul 9, 2014 at 5:18 PM, Viresh Kumar wrote: > On 9 July 2014 23:39, Olof Johansson wrote: >> * Why are you sending a pull request for a repo that is not yours? > > Because Mohit/Pratyush were facing some issues in pushing patches > to the SPEAr public git repo. And so I tried to help them out publicly > and nobody objected then: > > https://lkml.org/lkml/2014/7/8/10 This is completely done wrong on so many levels. I am not going to merge code from someone who doesn't have the basic skills down when there's already a maintainer for the platform. Luckily, you can deal with it -- be it coaching the ST employees on how to work with the community the right way, or doing the work yourself to send the code up. Probably a combination in this case. >> * Why is Viresh the git committer but hasn't signed off on the patches? > > I didn't sign-off because I haven't even looked closed at many of the > patches around PCI and Acked whatever I could understand. Thanks, good to know that the series hasn't been fully reviewed. That makes me even more hesitant to apply it at the moment, given all the other issues around it. > But yeah, this committer thing is what I missed. Because of that I might > be required to signoff it. Anyone touching the patch, forwarding it or applying it needs to sign off. It's quite simple, and well documented. >> Are you sharing accounts on kernel.org? (Adding kernel.org admin on cc >> just in case). > > Obviously not. I am alone the user of this account. Good. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] usb: usb3503: fix build warning
On 07/10/2014 02:05 PM, Greg Kroah-Hartman wrote: > On Thu, Jul 10, 2014 at 10:22:46AM +0530, Sachin Kamat wrote: >> Hi Joonyoung, >> >> On Thu, Jul 10, 2014 at 9:53 AM, Joonyoung Shim >> wrote: >>> This fixes below build warning. >>> >>> drivers/usb/misc/usb3503.c: In function ‘usb3503_probe’: >>> drivers/usb/misc/usb3503.c:195:11: warning: ‘err’ may be used uninitialized >>> in this function [-Wmaybe-uninitialized] >>> dev_err(dev, "unable to request refclk (%d)\n", err); >>>^ >> >> This has been fixed and availabe in Greg's usb-next tree. >> https://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next=ec5734c41bee2ee7c938a8f34853d31cada7e67a > > Yes, Joonyoung, can you refresh this against my latest tree and resend > anything that is still needed in this series? > Aha, i missed it, ok i will resend. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] usb: usb3503: fix build warning
On Thu, Jul 10, 2014 at 10:22:46AM +0530, Sachin Kamat wrote: > Hi Joonyoung, > > On Thu, Jul 10, 2014 at 9:53 AM, Joonyoung Shim > wrote: > > This fixes below build warning. > > > > drivers/usb/misc/usb3503.c: In function ‘usb3503_probe’: > > drivers/usb/misc/usb3503.c:195:11: warning: ‘err’ may be used uninitialized > > in this function [-Wmaybe-uninitialized] > > dev_err(dev, "unable to request refclk (%d)\n", err); > >^ > > This has been fixed and availabe in Greg's usb-next tree. > https://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next=ec5734c41bee2ee7c938a8f34853d31cada7e67a Yes, Joonyoung, can you refresh this against my latest tree and resend anything that is still needed in this series? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] usb: usb3503: fix build warning
Hi Joonyoung, On Thu, Jul 10, 2014 at 9:53 AM, Joonyoung Shim wrote: > This fixes below build warning. > > drivers/usb/misc/usb3503.c: In function ‘usb3503_probe’: > drivers/usb/misc/usb3503.c:195:11: warning: ‘err’ may be used uninitialized > in this function [-Wmaybe-uninitialized] > dev_err(dev, "unable to request refclk (%d)\n", err); >^ This has been fixed and availabe in Greg's usb-next tree. https://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next=ec5734c41bee2ee7c938a8f34853d31cada7e67a -- Regards, Sachin. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Procfs race condition bug
Alexey Dobriyan writes: > [broken email] > > On Wed, Jul 9, 2014 at 3:17 PM, Alexey Dobriyan wrote: >>> I originally posted this two years ago (*) but received no response. >>> I just had a look and the problem still exists on the 3.14 kernel >>> I am currently running. >>> >>> I *think* I've uncovered a race condition bug in procfs. >>> If I attempt to open a file in /proc/net, eg "/proc/net/tcp" >>> it works fine, but if I spawn a POSIX thread and attempt to do it >>> from there, it *usually* fails with a "No such file or directory", >>> but some times succeeds. If I do a system call inside the thread >>> to look up the thread ID and then open "/proc/THREADID/net/tcp" >>> instead, it works fine. >>> >>> There are more details and some example code >>> so you can replicate the problem on a stack overflow question >>> I asked previously here: >>> http://stackoverflow.com/questions/11580020/opening-proc-net-tcp-in-c-from-a-posix-thread-fails-most-of-the-time >>> >>> (*) https://lkml.org/lkml/2012/7/20/331 >> >> Mike, >> >> as was correctly notes on SO, what's happening is that original thread exits >> before spawned thread does open(). >> >> ->lookup >> proc_tgid_net_lookup >> get_proc_task_net >> nsproxy = NULL <== thread is dead >> ENOENT >> >> This was probably broken when /proc/net became symlink: >> >> commit e9720acd728a46cb40daa52c99a979f7c4ff195c >> Author: Pavel Emelyanov >> Date: Fri Mar 7 11:08:40 2008 -0800 >> >> [NET]: Make /proc/net a symlink on /proc/self/net (v3) >> >> >> So, userspace has two solutions: >> 1) original thread doesn't exit too early >> 2) spawned thread uses /proc/$TID >> >> >> So, >> we definitely broke /proc/net/tcp somewhere after netns concept was >> introduced. >> >> But, >> you'd have very same problem with other /proc files (anything under >> /proc/$PID/). Agreed it is a /proc/$TGID vs /proc/$TID issue. In principle this is fixable by creating a /proc/current symlink that always points to the proc directory for the current thread and then pointing /proc/net and /proc/mounts at it. This is one of those weird cases it so that /proc/net or /proc/mounts resolves may actually break an existing userspace application, because different threads can point at different values. (I very much dislike what the linux pthread support did to /proc/self). I tilted at that windmill once and ran out of steam. While I can write the patch I don't have the energy to test and see if there are any pthread programs that will break if /proc/net points to /proc/current/net instead of /proc/self/net. Frankly new applications should be using netlink and not /proc/net so I personally don't think this is worth fixing for the /proc/net case. Are there real world applications that are broken by the kernel change in behavior? The stackoverflow discussion sounds like it was just an investigation into weird kernel behavior. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[f2fs-dev][PATCH 1/2 v2] f2fs: check name_len of dir entry to prevent from deadloop
We assume that modification of some special application could result in zeroed name_len, or it is consciously made by somebody. We will deadloop in find_in_block when name_len of dir entry is zero. This patch is added for preventing deadloop in above scenario. change log from v1: o use f2fs_bug_on rather than break out from searching dir entry suggested by Jaegeuk Kim. Jaegeuk describe: "Well, IMO, it would be good to add f2fs_bug_on() here with a specific comment. In the current phase of f2fs, it is more important to investigate the file system bugs, rather than workarounds for any corrupted images. And, definitely it needs to stop the kernel if any corrupted image was mounted, so that we can figure out where the bugs are occurred." Suggested-by: Jaegeuk Kim Signed-off-by: Chao Yu --- fs/f2fs/dir.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c index e84e880..bcf893c 100644 --- a/fs/f2fs/dir.c +++ b/fs/f2fs/dir.c @@ -121,6 +121,13 @@ static struct f2fs_dir_entry *find_in_block(struct page *dentry_page, *max_slots = max_len; max_len = 0; } + + /* +* For the most part, it should be a bug when name_len is zero. +* We stop here for figuring out where the bugs are occurred. +*/ + f2fs_bug_on(!de->name_len); + bit_pos += GET_DENTRY_SLOTS(le16_to_cpu(de->name_len)); } -- 2.0.1.474.g72c7794 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm/vmalloc.c: clean up map_vm_area third argument
On Thu, Jul 10, 2014 at 12:26:07PM +0800, WANG Chao wrote: > Currently map_vm_area() takes (struct page *** pages) as third argument, > and after mapping, it moves (*pages) to point to (*pages + nr_mappped_pages). > > It looks like this kind of increment is useless to its caller these > days. The callers don't care about the increments and actually they're > trying to avoid this by passing another copy to map_vm_area(). > > The caller can always guarantee all the pages can be mapped into > vm_area as specified in first argument and the caller only cares about > whether map_vm_area() fails or not. > > This patch cleans up the pointer movement in map_vm_area() and updates > its callers accordingly. > > v2: Fix arch/tile/kernel/module.c::module_alloc(). > > Signed-off-by: WANG Chao > --- > arch/tile/kernel/module.c| 2 +- > drivers/lguest/core.c| 7 ++- > drivers/staging/android/binder.c | 4 +--- > include/linux/vmalloc.h | 2 +- > mm/vmalloc.c | 14 +- > mm/zsmalloc.c| 2 +- > 6 files changed, 11 insertions(+), 20 deletions(-) Staging code: Acked-by: Greg Kroah-Hartman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH v4 2/2] arm64: Add seccomp support
Will,
> (1) Updating syscallno based on w8, but this ties us to the current ABI
> and could get messy if this register changes in the future.
So, is this the conclusion that I should follow?
-Takahiro AKASHI
On 07/09/2014 01:12 PM, Will Deacon wrote:
Hi Akashi,
On Fri, Jul 04, 2014 at 08:31:55AM +0100, AKASHI Takahiro wrote:
secure_computing() should always be called first in syscall_trace_enter().
If it returns non-zero, we should stop further handling. Then that system
call may eventually fail, be trapped or the process itself be killed
depending on loaded rules.
In this case, syscall_trace_enter() returns a dedicated value in order to
skip a normal syscall table lookup because a seccomp rule may have already
overridden errno.
[...]
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 70526cf..baab5fc 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -21,12 +21,14 @@
#include
#include
+#include
#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -1109,6 +,10 @@ static void tracehook_report_syscall(struct pt_regs
*regs,
asmlinkage int syscall_trace_enter(struct pt_regs *regs)
{
+ if (secure_computing(regs->syscallno) == -1)
+ /* seccomp failures shouldn't expose any additional code. */
+ return -EPERM;
+
if (test_thread_flag(TIF_SYSCALL_TRACE))
tracehook_report_syscall(regs, PTRACE_SYSCALL_ENTER);
We return regs->syscallno immediately after this, so we have the same issue
that Kees identified for arch/arm/. Did you follow the discussion I had with
Andy?
Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] Fix permission checking by NFS client for open-create with mode 000
On Thu, Jul 10, 2014 at 12:26 AM, Frank Filz wrote:
>> On Wed, Jul 9, 2014 at 7:06 PM, Trond Myklebust
>> wrote:
>> > On Wed, Jul 9, 2014 at 6:42 PM, Frank Filz
>> wrote:
>> >>> On Wed, Jul 9, 2014 at 5:54 PM, Frank S. Filz
>> >>>
>> >>> wrote:
>> >>> > From: "Frank S. Filz"
>> >>> >
>> >>> > The NFS v4 client sends a COMPOUND with an OPEN and an ACCESS.
>> >>> >
>> >>> > The ACCESS is required to verify an open for read is actually
>> >>> > allowed because RFC 3530 indicates OPEN for read only must succeed
>> >>> > for an execute only file.
>> >>> >
>> >>> > The old code expected to have read access if the requested access
>> >>> > was O_RDWR.
>> >>> >
>> >>> > We can expect the OPEN to properly permission check as long as the
>> >>> > open is O_WRONLY or O_RDWR.
>> >>> >
>> >>> > Signed-off-by: Frank S. Filz
>> >>> > ---
>> >>> > fs/nfs/nfs4proc.c | 25 -
>> >>> > 1 file changed, 20 insertions(+), 5 deletions(-)
>> >>> >
>> >>> > diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index
>> >>> > 4bf3d97..9742054 100644
>> >>> > --- a/fs/nfs/nfs4proc.c
>> >>> > +++ b/fs/nfs/nfs4proc.c
>> >>> > @@ -1966,15 +1966,30 @@ static int nfs4_opendata_access(struct
>> >>> rpc_cred *cred,
>> >>> > return 0;
>> >>> >
>> >>> > mask = 0;
>> >>> > - /* don't check MAY_WRITE - a newly created file may not have
>> >>> > -* write mode bits, but POSIX allows the creating process to
>> >>> > write.
>> >>> > -* use openflags to check for exec, because fmode won't
>> >>> > -* always have FMODE_EXEC set when file open for exec. */
>> >>> > + /* Don't trust the permission check on OPEN if open for exec or
>> for
>> >>> > +* read only. Since FMODE_EXEC doesn't go across the wire, the
>> server
>> >>> > +* has no way to distinguish between an open to read an
>> >>> > + executable
>> >>> file
>> >>> > +* and an open to read a readable file. Write access is
>> >>> > properly
>> checked
>> >>> > +* and permission SHOULD always be granted if the file was
>> >>> > + created as
>> >>> a
>> >>> > +* result of this OPEN, no matter what mode the file was
>> >>> > created
>> with.
>> >>> > +*
>> >>> > +* NOTE: If the case of a OPEN CREATE READ-ONLY with a
>> >>> > + mode that
>> >>> does
>> >>> > +* not allow read access, this test will produce an
>> >>> > incorrect
>> >>> > +* EACCES error.
>> >>> > +*/
>> >>> > if (openflags & __FMODE_EXEC) {
>> >>> > /* ONLY check for exec rights */
>> >>> > mask = MAY_EXEC;
>> >>> > - } else if (fmode & FMODE_READ)
>> >>> > + } else if (!(fmode & FMODE_WRITE)) {
>> >>> > + /* In case the file was execute only, check for read
>> >>> > permission
>> >>> > +* ONLY if write access was not requested. It is
>> >>> > expected that
>> >>> > +* an OPEN for write will fail if the file is execute
>> >>> > only.
>> >>> > +* Note that if the file was newly created, the fmode
>> >>> > SHOULD
>> >>> > +* include FMODE_WRITE, especially if the file will be
>> >>> > created
>> >>> > +* with a restrictive mode.
>> >>> > +*/
>> >>> > mask = MAY_READ;
>> >>> > + }
>> >>>
>> >>> This looks wrong. AFAICS it will allow you to open an existing file
>> >>> which has - wx permissions (i.e. no read permissions) for O_RDWR.
>> >>> That should not be permitted under POSIX rules.
>> >>
>> >> The server permission checks the OPEN, this only affects the subsequent
>> ACCESS.
>> >>
>> >> The server will fail the OPEN with NFS4_ERR_ACCESS if the open is for
>> read/write and the file has write-execute permission.
>> >
>> > RFC3530bis draft 33 (6.2.1.3.1. Discussion of Mask Attributes) states
>> > that for both the OPEN and the READ operations, "Servers SHOULD allow
>> > a user the ability to read the data of the file when only the
>> > ACE4_EXECUTE access mask bit is allowed". RFC5561 has the same
>> > language.
>>
>> Oops. Sorry, the correct sub-sub-sub-sub-paragraph is this one:
>>
>> Permission to execute a file.
>>
>> Servers SHOULD allow a user the ability to read the data of the
>> file when only the ACE4_EXECUTE access mask bit is allowed.
>> This is because there is no way to execute a file without
>> reading the contents. Though a server may treat ACE4_EXECUTE
>> and ACE4_READ_DATA bits identically when deciding to permit a
>> READ operation, it SHOULD still allow the two bits to be set
>> independently in ACLs, and MUST distinguish between them when
>> replying to ACCESS operations. In particular, servers SHOULD
>> NOT silently turn on one of the two bits when the other is set,
>> as that would make it impossible for the client to correctly
>>
[PATCH v2] mm/vmalloc.c: clean up map_vm_area third argument
Currently map_vm_area() takes (struct page *** pages) as third argument,
and after mapping, it moves (*pages) to point to (*pages + nr_mappped_pages).
It looks like this kind of increment is useless to its caller these
days. The callers don't care about the increments and actually they're
trying to avoid this by passing another copy to map_vm_area().
The caller can always guarantee all the pages can be mapped into
vm_area as specified in first argument and the caller only cares about
whether map_vm_area() fails or not.
This patch cleans up the pointer movement in map_vm_area() and updates
its callers accordingly.
v2: Fix arch/tile/kernel/module.c::module_alloc().
Signed-off-by: WANG Chao
---
arch/tile/kernel/module.c| 2 +-
drivers/lguest/core.c| 7 ++-
drivers/staging/android/binder.c | 4 +---
include/linux/vmalloc.h | 2 +-
mm/vmalloc.c | 14 +-
mm/zsmalloc.c| 2 +-
6 files changed, 11 insertions(+), 20 deletions(-)
diff --git a/arch/tile/kernel/module.c b/arch/tile/kernel/module.c
index 4918d91..d19b13e 100644
--- a/arch/tile/kernel/module.c
+++ b/arch/tile/kernel/module.c
@@ -58,7 +58,7 @@ void *module_alloc(unsigned long size)
area->nr_pages = npages;
area->pages = pages;
- if (map_vm_area(area, prot_rwx, )) {
+ if (map_vm_area(area, prot_rwx, pages)) {
vunmap(area->addr);
goto error;
}
diff --git a/drivers/lguest/core.c b/drivers/lguest/core.c
index 0bf1e4e..6590558 100644
--- a/drivers/lguest/core.c
+++ b/drivers/lguest/core.c
@@ -42,7 +42,6 @@ DEFINE_MUTEX(lguest_lock);
static __init int map_switcher(void)
{
int i, err;
- struct page **pagep;
/*
* Map the Switcher in to high memory.
@@ -110,11 +109,9 @@ static __init int map_switcher(void)
* This code actually sets up the pages we've allocated to appear at
* switcher_addr. map_vm_area() takes the vma we allocated above, the
* kind of pages we're mapping (kernel pages), and a pointer to our
-* array of struct pages. It increments that pointer, but we don't
-* care.
+* array of struct pages.
*/
- pagep = lg_switcher_pages;
- err = map_vm_area(switcher_vma, PAGE_KERNEL_EXEC, );
+ err = map_vm_area(switcher_vma, PAGE_KERNEL_EXEC, lg_switcher_pages);
if (err) {
printk("lguest: map_vm_area failed: %i\n", err);
goto free_vma;
diff --git a/drivers/staging/android/binder.c b/drivers/staging/android/binder.c
index a741da7..0ca9785 100644
--- a/drivers/staging/android/binder.c
+++ b/drivers/staging/android/binder.c
@@ -586,7 +586,6 @@ static int binder_update_page_range(struct binder_proc
*proc, int allocate,
for (page_addr = start; page_addr < end; page_addr += PAGE_SIZE) {
int ret;
- struct page **page_array_ptr;
page = >pages[(page_addr - proc->buffer) / PAGE_SIZE];
@@ -599,8 +598,7 @@ static int binder_update_page_range(struct binder_proc
*proc, int allocate,
}
tmp_area.addr = page_addr;
tmp_area.size = PAGE_SIZE + PAGE_SIZE /* guard page? */;
- page_array_ptr = page;
- ret = map_vm_area(_area, PAGE_KERNEL, _array_ptr);
+ ret = map_vm_area(_area, PAGE_KERNEL, page);
if (ret) {
pr_err("%d: binder_alloc_buf failed to map page at %p
in kernel\n",
proc->pid, page_addr);
diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index 4b8a891..b87696f 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -113,7 +113,7 @@ extern struct vm_struct *remove_vm_area(const void *addr);
extern struct vm_struct *find_vm_area(const void *addr);
extern int map_vm_area(struct vm_struct *area, pgprot_t prot,
- struct page ***pages);
+ struct page **pages);
#ifdef CONFIG_MMU
extern int map_kernel_range_noflush(unsigned long start, unsigned long size,
pgprot_t prot, struct page **pages);
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index f64632b..c36547f 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1270,19 +1270,15 @@ void unmap_kernel_range(unsigned long addr, unsigned
long size)
}
EXPORT_SYMBOL_GPL(unmap_kernel_range);
-int map_vm_area(struct vm_struct *area, pgprot_t prot, struct page ***pages)
+int map_vm_area(struct vm_struct *area, pgprot_t prot, struct page **pages)
{
unsigned long addr = (unsigned long)area->addr;
unsigned long end = addr + get_vm_area_size(area);
int err;
- err = vmap_page_range(addr, end, prot, *pages);
- if (err > 0) {
- *pages += err;
- err = 0;
- }
+ err = vmap_page_range(addr, end, prot, pages);
- return err;
+
RE: [PATCH 1/1] Fix permission checking by NFS client for open-create with mode 000
> On Wed, Jul 9, 2014 at 7:06 PM, Trond Myklebust
> wrote:
> > On Wed, Jul 9, 2014 at 6:42 PM, Frank Filz
> wrote:
> >>> On Wed, Jul 9, 2014 at 5:54 PM, Frank S. Filz
> >>>
> >>> wrote:
> >>> > From: "Frank S. Filz"
> >>> >
> >>> > The NFS v4 client sends a COMPOUND with an OPEN and an ACCESS.
> >>> >
> >>> > The ACCESS is required to verify an open for read is actually
> >>> > allowed because RFC 3530 indicates OPEN for read only must succeed
> >>> > for an execute only file.
> >>> >
> >>> > The old code expected to have read access if the requested access
> >>> > was O_RDWR.
> >>> >
> >>> > We can expect the OPEN to properly permission check as long as the
> >>> > open is O_WRONLY or O_RDWR.
> >>> >
> >>> > Signed-off-by: Frank S. Filz
> >>> > ---
> >>> > fs/nfs/nfs4proc.c | 25 -
> >>> > 1 file changed, 20 insertions(+), 5 deletions(-)
> >>> >
> >>> > diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index
> >>> > 4bf3d97..9742054 100644
> >>> > --- a/fs/nfs/nfs4proc.c
> >>> > +++ b/fs/nfs/nfs4proc.c
> >>> > @@ -1966,15 +1966,30 @@ static int nfs4_opendata_access(struct
> >>> rpc_cred *cred,
> >>> > return 0;
> >>> >
> >>> > mask = 0;
> >>> > - /* don't check MAY_WRITE - a newly created file may not have
> >>> > -* write mode bits, but POSIX allows the creating process to
> >>> > write.
> >>> > -* use openflags to check for exec, because fmode won't
> >>> > -* always have FMODE_EXEC set when file open for exec. */
> >>> > + /* Don't trust the permission check on OPEN if open for exec or
> for
> >>> > +* read only. Since FMODE_EXEC doesn't go across the wire, the
> server
> >>> > +* has no way to distinguish between an open to read an
> >>> > + executable
> >>> file
> >>> > +* and an open to read a readable file. Write access is properly
> checked
> >>> > +* and permission SHOULD always be granted if the file was
> >>> > + created as
> >>> a
> >>> > +* result of this OPEN, no matter what mode the file was created
> with.
> >>> > +*
> >>> > +* NOTE: If the case of a OPEN CREATE READ-ONLY with a
> >>> > + mode that
> >>> does
> >>> > +* not allow read access, this test will produce an
> >>> > incorrect
> >>> > +* EACCES error.
> >>> > +*/
> >>> > if (openflags & __FMODE_EXEC) {
> >>> > /* ONLY check for exec rights */
> >>> > mask = MAY_EXEC;
> >>> > - } else if (fmode & FMODE_READ)
> >>> > + } else if (!(fmode & FMODE_WRITE)) {
> >>> > + /* In case the file was execute only, check for read
> >>> > permission
> >>> > +* ONLY if write access was not requested. It is
> >>> > expected that
> >>> > +* an OPEN for write will fail if the file is execute
> >>> > only.
> >>> > +* Note that if the file was newly created, the fmode
> >>> > SHOULD
> >>> > +* include FMODE_WRITE, especially if the file will be
> >>> > created
> >>> > +* with a restrictive mode.
> >>> > +*/
> >>> > mask = MAY_READ;
> >>> > + }
> >>>
> >>> This looks wrong. AFAICS it will allow you to open an existing file
> >>> which has - wx permissions (i.e. no read permissions) for O_RDWR.
> >>> That should not be permitted under POSIX rules.
> >>
> >> The server permission checks the OPEN, this only affects the subsequent
> ACCESS.
> >>
> >> The server will fail the OPEN with NFS4_ERR_ACCESS if the open is for
> read/write and the file has write-execute permission.
> >
> > RFC3530bis draft 33 (6.2.1.3.1. Discussion of Mask Attributes) states
> > that for both the OPEN and the READ operations, "Servers SHOULD allow
> > a user the ability to read the data of the file when only the
> > ACE4_EXECUTE access mask bit is allowed". RFC5561 has the same
> > language.
>
> Oops. Sorry, the correct sub-sub-sub-sub-paragraph is this one:
>
> Permission to execute a file.
>
> Servers SHOULD allow a user the ability to read the data of the
> file when only the ACE4_EXECUTE access mask bit is allowed.
> This is because there is no way to execute a file without
> reading the contents. Though a server may treat ACE4_EXECUTE
> and ACE4_READ_DATA bits identically when deciding to permit a
> READ operation, it SHOULD still allow the two bits to be set
> independently in ACLs, and MUST distinguish between them when
> replying to ACCESS operations. In particular, servers SHOULD
> NOT silently turn on one of the two bits when the other is set,
> as that would make it impossible for the client to correctly
> enforce the distinction between read and execute permissions.
>
>
> > To me that translates as saying that the server SHOULD accept an
> > OPEN(SHARE_ACCESS_READ|SHARE_ACCESS_WRITE)
[PATCH 2/3] usb: usb3503: add PM functions
The usb3503 needs to switch to standby mode while suspending and should
switch to hub mode when resumed. Also we can control clock on PM
function.
Signed-off-by: Joonyoung Shim
---
drivers/usb/misc/usb3503.c | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index 652855b..47cb143 100644
--- a/drivers/usb/misc/usb3503.c
+++ b/drivers/usb/misc/usb3503.c
@@ -149,8 +149,6 @@ static int usb3503_switch_mode(struct usb3503 *hub, enum
usb3503_mode mode)
case USB3503_MODE_STANDBY:
usb3503_reset(hub, 0);
-
- hub->mode = mode;
dev_info(dev, "switched to STANDBY mode\n");
break;
@@ -347,6 +345,37 @@ static int usb3503_platform_probe(struct platform_device
*pdev)
return usb3503_probe(hub);
}
+#ifdef CONFIG_PM_SLEEP
+static int usb3503_i2c_suspend(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct usb3503 *hub = i2c_get_clientdata(client);
+
+ usb3503_switch_mode(hub, USB3503_MODE_STANDBY);
+
+ if (hub->clk)
+ clk_disable_unprepare(hub->clk);
+
+ return 0;
+}
+
+static int usb3503_i2c_resume(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct usb3503 *hub = i2c_get_clientdata(client);
+
+ if (hub->clk)
+ clk_prepare_enable(hub->clk);
+
+ usb3503_switch_mode(hub, hub->mode);
+
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(usb3503_i2c_pm_ops, usb3503_i2c_suspend,
+ usb3503_i2c_resume);
+
static const struct i2c_device_id usb3503_id[] = {
{ USB3503_I2C_NAME, 0 },
{ }
@@ -365,6 +394,7 @@ MODULE_DEVICE_TABLE(of, usb3503_of_match);
static struct i2c_driver usb3503_i2c_driver = {
.driver = {
.name = USB3503_I2C_NAME,
+ .pm = _i2c_pm_ops,
.of_match_table = of_match_ptr(usb3503_of_match),
},
.probe = usb3503_i2c_probe,
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] usb: usb3503: fix build warning
This fixes below build warning.
drivers/usb/misc/usb3503.c: In function ‘usb3503_probe’:
drivers/usb/misc/usb3503.c:195:11: warning: ‘err’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
dev_err(dev, "unable to request refclk (%d)\n", err);
^
Signed-off-by: Joonyoung Shim
---
drivers/usb/misc/usb3503.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index f43c619..652855b 100644
--- a/drivers/usb/misc/usb3503.c
+++ b/drivers/usb/misc/usb3503.c
@@ -192,7 +192,8 @@ static int usb3503_probe(struct usb3503 *hub)
clk = devm_clk_get(dev, "refclk");
if (IS_ERR(clk) && PTR_ERR(clk) != -ENOENT) {
- dev_err(dev, "unable to request refclk (%d)\n", err);
+ dev_err(dev, "unable to request refclk (%ld)\n",
+ PTR_ERR(clk));
return PTR_ERR(clk);
}
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] usb: fix and support PM for usb3503
Hello, This patchset is simple just to fix and support PM for usb3503. They was tested on odroid U3 board. Thanks. Joonyoung Shim (3): usb: usb3503: fix build warning usb: usb3503: add PM functions USB: add reset resume quirk for usb3503 drivers/usb/core/quirks.c | 3 +++ drivers/usb/misc/usb3503.c | 37 ++--- 2 files changed, 37 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] USB: add reset resume quirk for usb3503
The usb device will autoresume from choose_wakeup() if it is
autosuspended with the wrong wakeup setting, but below errors occur
because usb3503 misc driver will switch to standby mode when suspended.
As add USB_QUIRK_RESET_RESUME, it can stop setting wrong wakeup from
autosuspend_check().
[7.734717] usb 1-3: reset high-speed USB device number 3 using exynos-ehci
[7.854658] usb 1-3: device descriptor read/64, error -71
[8.079657] usb 1-3: device descriptor read/64, error -71
[8.294664] usb 1-3: reset high-speed USB device number 3 using exynos-ehci
[8.414658] usb 1-3: device descriptor read/64, error -71
[8.639657] usb 1-3: device descriptor read/64, error -71
[8.854667] usb 1-3: reset high-speed USB device number 3 using exynos-ehci
[9.264598] usb 1-3: device not accepting address 3, error -71
[9.374655] usb 1-3: reset high-speed USB device number 3 using exynos-ehci
[9.784601] usb 1-3: device not accepting address 3, error -71
[9.784838] usb usb1-port3: device 1-3 not suspended yet
Signed-off-by: Joonyoung Shim
---
drivers/usb/core/quirks.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 739ee8e..2c9ba407 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -152,6 +152,9 @@ static const struct usb_device_id usb_quirk_list[] = {
/* INTEL VALUE SSD */
{ USB_DEVICE(0x8086, 0xf1a5), .driver_info = USB_QUIRK_RESET_RESUME },
+ /* USB3503 */
+ { USB_DEVICE(0x0424, 0x3503), .driver_info = USB_QUIRK_RESET_RESUME },
+
{ } /* terminating entry must be last */
};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [f2fs-dev][PATCH 1/2] f2fs: check name_len of dir entry to prevent from deadloop
Hi Jaegeuk, > -Original Message- > From: Jaegeuk Kim [mailto:jaeg...@kernel.org] > Sent: Wednesday, July 09, 2014 9:48 PM > To: Chao Yu > Cc: 'Changman Lee'; linux-f2fs-de...@lists.sourceforge.net; > linux-fsde...@vger.kernel.org; > linux-kernel@vger.kernel.org > Subject: Re: [f2fs-dev][PATCH 1/2] f2fs: check name_len of dir entry to > prevent from deadloop > > Hi Chao, > > On Wed, Jul 09, 2014 at 10:57:43AM +0800, Chao Yu wrote: > > Hi, > > > > > -Original Message- > > > From: Jaegeuk Kim [mailto:jaeg...@kernel.org] > > > Sent: Tuesday, July 08, 2014 1:56 PM > > > To: Chao Yu > > > Cc: 'Changman Lee'; linux-f2fs-de...@lists.sourceforge.net; > > > linux-fsde...@vger.kernel.org; > > > linux-kernel@vger.kernel.org > > > Subject: Re: [f2fs-dev][PATCH 1/2] f2fs: check name_len of dir entry to > > > prevent from deadloop > > > > > > On Mon, Jul 07, 2014 at 09:24:05AM +0800, Chao Yu wrote: > > > > Hi Jaegeuk, > > > > > > > > > -Original Message- > > > > > From: Jaegeuk Kim [mailto:jaeg...@kernel.org] > > > > > Sent: Saturday, July 05, 2014 2:43 PM > > > > > To: Chao Yu > > > > > Cc: Changman Lee; linux-f2fs-de...@lists.sourceforge.net; > linux-fsde...@vger.kernel.org; > > > > > linux-kernel@vger.kernel.org > > > > > Subject: Re: [f2fs-dev][PATCH 1/2] f2fs: check name_len of dir entry > > > > > to prevent from > deadloop > > > > > > > > > > Hi Chao, > > > > > > > > > > On Wed, Jul 02, 2014 at 01:23:47PM +0800, Chao Yu wrote: > > > > > > We assume that modification of some special application could > > > > > > result in zeroed > > > > > > name_len, or it is consciously made by somebody. We will deadloop in > > > > > > find_in_block when name_len of dir entry is zero. > > > > > > > > > > Could you explain this a little bit more? > > > > > I'm not sure how it can happen. > > > > > > > > IMO, > > > > On one hand, programs like mkfs/fsck/img2simg and f2fs could directly > > > > operate > > > > the raw device, so bugs of these software may be triggered to generate > > > > the > > > > corrupt data such as zeroed name_len. > > > > > > Well... > > > If such the programs try to corrupt the f2fs image crucially, the bug > > > should be > > > fixed inside the programs, not from the workaround through f2fs. > > > > IMO, software should have ability of self fault-tolerant, but not depend on > > correctness > > of other related software. And I will hope there are no more other software > > which could > > directly operate the raw device, to provide us such corrupted data as input. > > > > How about swifting to BUG_ON here? > > Well, IMO, it would be good to add f2fs_bug_on() here with a specific comment. Ok, I will modify this patch and resend it. > > In the current phase of f2fs, it is more important to investigate the file > system bugs, rather than workarounds for any corrupted images. > And, definitely it needs to stop the kernel if any corrupted image was > mounted, > so that we can figure out where the bugs are occurred. All right, I got it. Thanks for the review and explanation in patience. :) Regards, Yu > > Thanks, > > > > > > > > > As I mentioned, even though f2fs avoids such the dead loop whatever at > > > that > > > moment, it will be operating with inconsistent file system status, > > > resulting > > > in system crash in the near furture finally. > > > > Agreed, we should avoid this. Previous solution with "break" is not > > suitable here. > > Thanks for you reminder. > > > > > > > > Why should we avoid this specific case only? > > > > Hmm... I just found this case could cause some issue when I review Gu's > > last patch. > > As I check, several error cases of find_data_page in find_in_level could > > also cause > > inconsistent status of fs as you said. > > > > > It seems that it is a kinda intentional user-made case. > > > Is it really normal? > > > > It's really rare. > > > > > > > > > On the other hand, it' could be treated as a potential security > > > > problem, because > > > > user could crafted such a malicious image include zeroed name_len for > > > > hacking purpose. > > > > > > If user can try to do something like that, why do they write zeroed > > > name_len only? > > > To crash the system, they can do everything. > > > > If they have the whole right to access the system, certainly they do not > > have to do such > > thing. I just assume that they only have the right to upload the crafted > > image, then use > > social engineering in next "do mount" step. Or it's no need to worry about > > this? > > > > Thanks, > > Yu > > > > > > > > Thanks, > > > > > > > Once such special image is being mounted, deadloop could be triggered, > > > > finally will > > > > result in effecting on linux system's running. > > > > > > > > Thanks, > > > > Yu > > > > > > > > > I think the zeroed name_len would cause some problems in > > > > > f2fs_add_link. > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > This patch is added for preventing deadloop in
Re: [PATCH] thermal: samsung: Add TMU support for Exynos3250 SoC
On Wed, Jul 9, 2014 at 8:30 AM, Chanwoo Choi wrote:
> On 07/01/2014 09:33 AM, Chanwoo Choi wrote:
>> This patch add registers, bit fields and compatible strings for Exynos3250
>> TMU
>> (Thermal Management Unit). Exynos3250 uses the Cortex-A7 dual cores and has
>> a target speed of 1.0 GHz.
>>
>> Signed-off-by: Chanwoo Choi
>> [Add MUX address setting bits by Jonghwa Lee]
>> Signed-off-by: Jonghwa Lee
>> Acked-by: Kyungmin Park
Changes look fine to me.
Reviewed-by: Amit Daniel Kachhap
>> ---
>> .../devicetree/bindings/thermal/exynos-thermal.txt | 1 +
>> drivers/thermal/samsung/exynos_tmu.c | 7 +-
>> drivers/thermal/samsung/exynos_tmu.h | 3 +-
>> drivers/thermal/samsung/exynos_tmu_data.c | 89
>> ++
>> drivers/thermal/samsung/exynos_tmu_data.h | 7 ++
>> 5 files changed, 105 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> index c949092..ae738f5 100644
>> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> @@ -3,6 +3,7 @@
>> ** Required properties:
>>
>> - compatible : One of the following:
>> +"samsung,exynos3250-tmu"
>> "samsung,exynos4412-tmu"
>> "samsung,exynos4210-tmu"
>> "samsung,exynos5250-tmu"
>> diff --git a/drivers/thermal/samsung/exynos_tmu.c
>> b/drivers/thermal/samsung/exynos_tmu.c
>> index 2412090..97ebc1e 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.c
>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>> @@ -501,6 +501,10 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
>>
>> static const struct of_device_id exynos_tmu_match[] = {
>> {
>> + .compatible = "samsung,exynos3250-tmu",
>> + .data = (void *)EXYNOS3250_TMU_DRV_DATA,
>> + },
>> + {
>> .compatible = "samsung,exynos4210-tmu",
>> .data = (void *)EXYNOS4210_TMU_DRV_DATA,
>> },
>> @@ -675,7 +679,8 @@ static int exynos_tmu_probe(struct platform_device *pdev)
>> goto err_clk_sec;
>> }
>>
>> - if (pdata->type == SOC_ARCH_EXYNOS4210 ||
>> + if (pdata->type == SOC_ARCH_EXYNOS3250 ||
>> + pdata->type == SOC_ARCH_EXYNOS4210 ||
>> pdata->type == SOC_ARCH_EXYNOS4412 ||
>> pdata->type == SOC_ARCH_EXYNOS5250 ||
>> pdata->type == SOC_ARCH_EXYNOS5260 ||
>> diff --git a/drivers/thermal/samsung/exynos_tmu.h
>> b/drivers/thermal/samsung/exynos_tmu.h
>> index edd08cf..1b4a644 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.h
>> +++ b/drivers/thermal/samsung/exynos_tmu.h
>> @@ -40,7 +40,8 @@ enum calibration_mode {
>> };
>>
>> enum soc_type {
>> - SOC_ARCH_EXYNOS4210 = 1,
>> + SOC_ARCH_EXYNOS3250 = 1,
>> + SOC_ARCH_EXYNOS4210,
>> SOC_ARCH_EXYNOS4412,
>> SOC_ARCH_EXYNOS5250,
>> SOC_ARCH_EXYNOS5260,
>> diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
>> b/drivers/thermal/samsung/exynos_tmu_data.c
>> index c1d81dc..aa8e0de 100644
>> --- a/drivers/thermal/samsung/exynos_tmu_data.c
>> +++ b/drivers/thermal/samsung/exynos_tmu_data.c
>> @@ -90,6 +90,95 @@ struct exynos_tmu_init_data const
>> exynos4210_default_tmu_data = {
>> };
>> #endif
>>
>> +#if defined(CONFIG_SOC_EXYNOS3250)
>> +static const struct exynos_tmu_registers exynos3250_tmu_registers = {
>> + .triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
>> + .triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
>> + .triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
>> + .tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
>> + .test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
>> + .buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
>> + .buf_vref_sel_mask = EXYNOS_TMU_REF_VOLTAGE_MASK,
>> + .therm_trip_mode_shift = EXYNOS_TMU_TRIP_MODE_SHIFT,
>> + .therm_trip_mode_mask = EXYNOS_TMU_TRIP_MODE_MASK,
>> + .therm_trip_en_shift = EXYNOS_TMU_THERM_TRIP_EN_SHIFT,
>> + .buf_slope_sel_shift = EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT,
>> + .buf_slope_sel_mask = EXYNOS_TMU_BUF_SLOPE_SEL_MASK,
>> + .core_en_shift = EXYNOS_TMU_CORE_EN_SHIFT,
>> + .tmu_status = EXYNOS_TMU_REG_STATUS,
>> + .tmu_cur_temp = EXYNOS_TMU_REG_CURRENT_TEMP,
>> + .threshold_th0 = EXYNOS_THD_TEMP_RISE,
>> + .threshold_th1 = EXYNOS_THD_TEMP_FALL,
>> + .tmu_inten = EXYNOS_TMU_REG_INTEN,
>> + .inten_rise0_shift = EXYNOS_TMU_INTEN_RISE0_SHIFT,
>> + .inten_rise1_shift = EXYNOS_TMU_INTEN_RISE1_SHIFT,
>> + .inten_rise2_shift = EXYNOS_TMU_INTEN_RISE2_SHIFT,
>> + .inten_fall0_shift = EXYNOS_TMU_INTEN_FALL0_SHIFT,
>> + .tmu_intstat = EXYNOS_TMU_REG_INTSTAT,
>> + .tmu_intclear = EXYNOS_TMU_REG_INTCLEAR,
>> + .intclr_fall_shift = EXYNOS_TMU_CLEAR_FALL_INT_SHIFT,
>> + .intclr_rise_shift = EXYNOS_TMU_RISE_INT_SHIFT,
>> + .intclr_rise_mask =
[PATCH v2] mmc: dw_mmc: add support for RK3288
This patch focuses on clock setting for RK3288 mmc controller.
In RK3288 mmc controller, CLKDIV register can only be set 0 or 1,
and if DDR 8bit mode, CLKDIV register must be set 1.
Signed-off-by: Addy Ke
---
changes since v1:
- dw_mci_rk3288_setup_clock: do not call clk_get_rate(), just use the
host->bus_hz which is already called by dw_mmc.c, suggested by Jaehoon Chung
.../devicetree/bindings/mmc/rockchip-dw-mshc.txt | 4 +-
drivers/mmc/host/dw_mmc-pltfm.c| 50 +-
2 files changed, 51 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
index c559f3f..e3f95cd 100644
--- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
@@ -10,7 +10,9 @@ extensions to the Synopsys Designware Mobile Storage Host
Controller.
Required Properties:
* compatible: should be
- - "rockchip,rk2928-dw-mshc": for Rockchip RK2928 and following
+ - "rockchip,rk2928-dw-mshc": for Rockchip RK2928 and following,
+ before RK3288
+ - "rockchip,rk3288-dw-mshc": for Rockchip RK3288
Example:
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index d4a47a9..809c28b 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -21,17 +21,61 @@
#include
#include
#include
+#include
#include "dw_mmc.h"
#include "dw_mmc-pltfm.h"
+#define RK3288_CLKGEN_DIV 2
+
static void dw_mci_pltfm_prepare_command(struct dw_mci *host, u32 *cmdr)
{
*cmdr |= SDMMC_CMD_USE_HOLD_REG;
}
-static const struct dw_mci_drv_data rockchip_drv_data = {
+static int dw_mci_rk3288_setup_clock(struct dw_mci *host)
+{
+ host->bus_hz /= RK3288_CLKGEN_DIV;
+
+ return 0;
+}
+
+static void dw_mci_rk3288_set_ios(struct dw_mci *host, struct mmc_ios *ios)
+{
+ int ret;
+ unsigned int cclkin;
+
+ /*
+* cclkin: source clock of mmc controller.
+* bus_hz: card interface clock generated by CLKGEN.
+* bus_hz = cclkin / RK3288_CLKGEN_DIV;
+* ios->clock = (div == 0) ? bus_hz : (bus_hz / (2 * div))
+*
+* Note: div can only be 0 or 1
+* if DDR50 8bit mode, div must be set 1
+*/
+ if ((ios->bus_width == MMC_BUS_WIDTH_8) &&
+ (ios->timing == MMC_TIMING_UHS_DDR50 ||
+ios->timing == MMC_TIMING_MMC_DDR52))
+ cclkin = 2 * ios->clock * RK3288_CLKGEN_DIV;
+ else
+ cclkin = ios->clock * RK3288_CLKGEN_DIV;
+
+ ret = clk_set_rate(host->ciu_clk, cclkin);
+ if (ret)
+ dev_warn(host->dev, "failed to set rate %uHz\n", ios->clock);
+
+ host->bus_hz = clk_get_rate(host->ciu_clk) / RK3288_CLKGEN_DIV;
+}
+
+static const struct dw_mci_drv_data rk2928_drv_data = {
+ .prepare_command= dw_mci_pltfm_prepare_command,
+};
+
+static const struct dw_mci_drv_data rk3288_drv_data = {
.prepare_command= dw_mci_pltfm_prepare_command,
+ .set_ios= dw_mci_rk3288_set_ios,
+ .setup_clock= dw_mci_rk3288_setup_clock,
};
static const struct dw_mci_drv_data socfpga_drv_data = {
@@ -95,7 +139,9 @@ EXPORT_SYMBOL_GPL(dw_mci_pltfm_pmops);
static const struct of_device_id dw_mci_pltfm_match[] = {
{ .compatible = "snps,dw-mshc", },
{ .compatible = "rockchip,rk2928-dw-mshc",
- .data = _drv_data },
+ .data = _drv_data },
+ { .compatible = "rockchip,rk3288-dw-mshc",
+ .data = _drv_data },
{ .compatible = "altr,socfpga-dw-mshc",
.data = _drv_data },
{},
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2] staging: dgap: removes redundant null check and change paramter for dgap_maxcps_room()
Null checks for tty, un and ch are already done by caller,
so replace parameter "tty" with "ch" and "un".
Signed-off-by: Daeseok Youn
---
V2: revert return type from int to void.
leave it originally.
drivers/staging/dgap/dgap.c | 21 -
1 files changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index cc21dd2..9affc5b 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -2507,22 +2507,9 @@ static int dgap_wait_for_drain(struct tty_struct *tty)
* returns the new bytes_available. This only affects printer
* output.
*/
-static int dgap_maxcps_room(struct tty_struct *tty, int bytes_available)
+static int dgap_maxcps_room(struct channel_t *ch, struct un_t *un,
+ int bytes_available)
{
- struct channel_t *ch;
- struct un_t *un;
-
- if (!tty)
- return bytes_available;
-
- un = tty->driver_data;
- if (!un || un->magic != DGAP_UNIT_MAGIC)
- return bytes_available;
-
- ch = un->un_ch;
- if (!ch || ch->magic != DGAP_CHANNEL_MAGIC)
- return bytes_available;
-
/*
* If its not the Transparent print device, return
* the full data amount.
@@ -2624,7 +2611,7 @@ static int dgap_tty_write_room(struct tty_struct *tty)
ret += ch->ch_tsize;
/* Limit printer to maxcps */
- ret = dgap_maxcps_room(tty, ret);
+ ret = dgap_maxcps_room(ch, un, ret);
/*
* If we are printer device, leave space for
@@ -2729,7 +2716,7 @@ static int dgap_tty_write(struct tty_struct *tty, const
unsigned char *buf,
* Limit printer output to maxcps overall, with bursts allowed
* up to bufsize characters.
*/
- bufcount = dgap_maxcps_room(tty, bufcount);
+ bufcount = dgap_maxcps_room(ch, un, bufcount);
/*
* Take minimum of what the user wants to send, and the
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] regulator: s2mps11: Optimize the regulator description macro
Adding MFD maintainers
On Tue, Jul 8, 2014 at 5:58 PM, Amit Daniel Kachhap
wrote:
> This patch makes the regulator description macro take minimum and
> steps voltage as parameter. In this way many repeated macros can be
> removed. Now these macros are repeated only if the the LDO/BUCK ctrl
> registers have non-linear positions. The good thing is these ctrl registers
> are mostly linear so they are not passed as parameters.
>
> This patch reduces the code size and also allow easy addition of more
> s2mpxxx PMIC drivers which differs a lot in minimum/step voltages.
>
> Signed-off-by: Amit Daniel Kachhap
> ---
> drivers/regulator/s2mps11.c | 261
> +++-
> 1 file changed, 86 insertions(+), 175 deletions(-)
>
> diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
> index 2098c3e..ea94f47 100644
> --- a/drivers/regulator/s2mps11.c
> +++ b/drivers/regulator/s2mps11.c
> @@ -250,28 +250,14 @@ static struct regulator_ops s2mps11_buck_ops = {
> .set_ramp_delay = s2mps11_set_ramp_delay,
> };
>
> -#define regulator_desc_s2mps11_ldo1(num) { \
> +#define regulator_desc_s2mps11_ldo(num, min, step) { \
> .name = "LDO"#num,\
> .id = S2MPS11_LDO##num, \
> .ops= _ldo_ops, \
> .type = REGULATOR_VOLTAGE,\
> .owner = THIS_MODULE, \
> - .min_uV = MIN_800_MV, \
> - .uV_step= STEP_50_MV, \
> - .n_voltages = S2MPS11_LDO_N_VOLTAGES, \
> - .vsel_reg = S2MPS11_REG_L1CTRL + num - 1, \
> - .vsel_mask = S2MPS11_LDO_VSEL_MASK,\
> - .enable_reg = S2MPS11_REG_L1CTRL + num - 1, \
> - .enable_mask= S2MPS11_ENABLE_MASK \
> -}
> -#define regulator_desc_s2mps11_ldo2(num) { \
> - .name = "LDO"#num,\
> - .id = S2MPS11_LDO##num, \
> - .ops= _ldo_ops, \
> - .type = REGULATOR_VOLTAGE,\
> - .owner = THIS_MODULE, \
> - .min_uV = MIN_800_MV, \
> - .uV_step= STEP_25_MV, \
> + .min_uV = min, \
> + .uV_step= step, \
> .n_voltages = S2MPS11_LDO_N_VOLTAGES, \
> .vsel_reg = S2MPS11_REG_L1CTRL + num - 1, \
> .vsel_mask = S2MPS11_LDO_VSEL_MASK,\
> @@ -311,14 +297,14 @@ static struct regulator_ops s2mps11_buck_ops = {
> .enable_mask= S2MPS11_ENABLE_MASK \
> }
>
> -#define regulator_desc_s2mps11_buck6_8(num) { \
> +#define regulator_desc_s2mps11_buck6_10(num, min, step) { \
> .name = "BUCK"#num, \
> .id = S2MPS11_BUCK##num,\
> .ops= _buck_ops,\
> .type = REGULATOR_VOLTAGE,\
> .owner = THIS_MODULE, \
> - .min_uV = MIN_600_MV, \
> - .uV_step= STEP_6_25_MV, \
> + .min_uV = min, \
> + .uV_step= step, \
> .n_voltages = S2MPS11_BUCK_N_VOLTAGES, \
> .ramp_delay = S2MPS11_RAMP_DELAY, \
> .vsel_reg = S2MPS11_REG_B6CTRL2 + (num - 6) * 2, \
> @@ -327,87 +313,55 @@ static struct regulator_ops s2mps11_buck_ops = {
> .enable_mask= S2MPS11_ENABLE_MASK \
> }
>
> -#define regulator_desc_s2mps11_buck9 { \
> - .name = "BUCK9", \
> - .id = S2MPS11_BUCK9,\
> - .ops= _buck_ops,\
> - .type = REGULATOR_VOLTAGE,\
> - .owner = THIS_MODULE, \
> - .min_uV = MIN_3000_MV, \
> - .uV_step= STEP_25_MV, \
> - .n_voltages = S2MPS11_BUCK_N_VOLTAGES, \
> - .ramp_delay = S2MPS11_RAMP_DELAY, \
> - .vsel_reg = S2MPS11_REG_B9CTRL2, \
> - .vsel_mask = S2MPS11_BUCK_VSEL_MASK, \
> - .enable_reg = S2MPS11_REG_B9CTRL1, \
> - .enable_mask= S2MPS11_ENABLE_MASK \
> -}
> -
> -#define regulator_desc_s2mps11_buck10 {\
> - .name = "BUCK10",
Re: [PATCH 2/3] regulator: s2mpa01: Optimize the regulator description macro
Adding MFD maintainers.
On Tue, Jul 8, 2014 at 5:57 PM, Amit Daniel Kachhap
wrote:
> This patch makes the regulator description macro take minimum and
> steps voltage as parameter. In this way many repeated macros can be
> removed. Now these macros are repeated only if the the LDO/BUCK ctrl
> registers have non-linear positions. The good thing is these ctrl registers
> are mostly linear so they are not passed as parameters.
>
> This patch reduces the code size and also allow easy addition of more
> s2mpxxx PMIC drivers which differs a lot in minimum/step voltages.
>
> Signed-off-by: Amit Daniel Kachhap
> ---
> drivers/regulator/s2mpa01.c | 136
>
> 1 file changed, 37 insertions(+), 99 deletions(-)
>
> diff --git a/drivers/regulator/s2mpa01.c b/drivers/regulator/s2mpa01.c
> index 962c5f1..8073466 100644
> --- a/drivers/regulator/s2mpa01.c
> +++ b/drivers/regulator/s2mpa01.c
> @@ -235,28 +235,14 @@ static struct regulator_ops s2mpa01_buck_ops = {
> .set_ramp_delay = s2mpa01_set_ramp_delay,
> };
>
> -#define regulator_desc_ldo1(num) { \
> +#define regulator_desc_ldo(num, min, step) { \
> .name = "LDO"#num,\
> .id = S2MPA01_LDO##num, \
> .ops= _ldo_ops, \
> .type = REGULATOR_VOLTAGE,\
> .owner = THIS_MODULE, \
> - .min_uV = MIN_800_MV, \
> - .uV_step= STEP_50_MV, \
> - .n_voltages = S2MPA01_LDO_N_VOLTAGES, \
> - .vsel_reg = S2MPA01_REG_L1CTRL + num - 1, \
> - .vsel_mask = S2MPA01_LDO_VSEL_MASK,\
> - .enable_reg = S2MPA01_REG_L1CTRL + num - 1, \
> - .enable_mask= S2MPA01_ENABLE_MASK \
> -}
> -#define regulator_desc_ldo2(num) { \
> - .name = "LDO"#num,\
> - .id = S2MPA01_LDO##num, \
> - .ops= _ldo_ops, \
> - .type = REGULATOR_VOLTAGE,\
> - .owner = THIS_MODULE, \
> - .min_uV = MIN_800_MV, \
> - .uV_step= STEP_25_MV, \
> + .min_uV = min, \
> + .uV_step= step, \
> .n_voltages = S2MPA01_LDO_N_VOLTAGES, \
> .vsel_reg = S2MPA01_REG_L1CTRL + num - 1, \
> .vsel_mask = S2MPA01_LDO_VSEL_MASK,\
> @@ -296,14 +282,14 @@ static struct regulator_ops s2mpa01_buck_ops = {
> .enable_mask= S2MPA01_ENABLE_MASK \
> }
>
> -#define regulator_desc_buck6_7(num){ \
> +#define regulator_desc_buck6_10(num, min, step){ \
> .name = "BUCK"#num, \
> .id = S2MPA01_BUCK##num,\
> .ops= _buck_ops,\
> .type = REGULATOR_VOLTAGE,\
> .owner = THIS_MODULE, \
> - .min_uV = MIN_600_MV, \
> - .uV_step= STEP_6_25_MV, \
> + .min_uV = min, \
> + .uV_step= step, \
> .n_voltages = S2MPA01_BUCK_N_VOLTAGES, \
> .ramp_delay = S2MPA01_RAMP_DELAY, \
> .vsel_reg = S2MPA01_REG_B6CTRL2 + (num - 6) * 2, \
> @@ -312,91 +298,43 @@ static struct regulator_ops s2mpa01_buck_ops = {
> .enable_mask= S2MPA01_ENABLE_MASK \
> }
>
> -#define regulator_desc_buck8 { \
> - .name = "BUCK8", \
> - .id = S2MPA01_BUCK8,\
> - .ops= _buck_ops,\
> - .type = REGULATOR_VOLTAGE,\
> - .owner = THIS_MODULE, \
> - .min_uV = MIN_800_MV, \
> - .uV_step= STEP_12_5_MV, \
> - .n_voltages = S2MPA01_BUCK_N_VOLTAGES, \
> - .ramp_delay = S2MPA01_RAMP_DELAY, \
> - .vsel_reg = S2MPA01_REG_B8CTRL2, \
> - .vsel_mask = S2MPA01_BUCK_VSEL_MASK, \
> - .enable_reg = S2MPA01_REG_B8CTRL1, \
> - .enable_mask= S2MPA01_ENABLE_MASK \
> -}
> -
> -#define regulator_desc_buck9 { \
> - .name = "BUCK9",
Re: [PATCH 1/3] regulator: s2mpxxx: Move regulator min/step voltages in common place
On Wed, Jul 9, 2014 at 2:55 PM, Mark Brown wrote: > On Tue, Jul 08, 2014 at 05:57:58PM +0530, Amit Daniel Kachhap wrote: > >> include/linux/mfd/samsung/core.h| 21 >> include/linux/mfd/samsung/s2mpa01.h | 12 - >> include/linux/mfd/samsung/s2mps11.h | 9 --- >> include/linux/mfd/samsung/s2mps14.h | 10 > > You need to send patches to the MFD subsystem to the MFD maintainers as > well. Thanks for the pointer. Will submit to MFD maintainers. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] 3.4.97-rt120
Dear RT Folks, I'm pleased to announce the 3.4.97-rt120 stable release. This release is just an update to the new stable 3.4.97 version and no RT specific changes have been made. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.4-rt Head SHA1: c22c066b1893a3f0204b7a197a04ded6d26aa47b Or to build 3.4.97-rt120 directly, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.4.tar.xz http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.4.97.xz http://www.kernel.org/pub/linux/kernel/projects/rt/3.4/patch-3.4.97-rt120.patch.xz Enjoy, -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] 3.10.47-rt49
Dear RT Folks, I'm pleased to announce the 3.10.47-rt49 stable release. This release is just an update to the new stable 3.10.47 version and no RT specific changes have been made. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.10-rt Head SHA1: 5d7ec7f6ed15e36d123da0c54f7400e7921a8279 Or to build 3.10.47-rt49 directly, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.10.tar.xz http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.10.47.xz http://www.kernel.org/pub/linux/kernel/projects/rt/3.10/patch-3.10.47-rt49.patch.xz Enjoy, -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] 3.12.24-rt37
Dear RT Folks, I'm pleased to announce the 3.12.24-rt37 stable release. This release is just an update to the new stable 3.12.24 version and no RT specific changes have been made. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git branch: v3.12-rt Head SHA1: 09523f99794f9ec158411c6565162d8432303d8a Or to build 3.12.24-rt37 directly, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.12.tar.xz http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.12.24.xz http://www.kernel.org/pub/linux/kernel/projects/rt/3.12/patch-3.12.24-rt37.patch.xz Enjoy, -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the staging tree
On Thu, Jul 10, 2014 at 10:27:00AM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> On Fri, 20 Jun 2014 09:53:53 -0700 Greg KH wrote:
> >
> > On Fri, Jun 20, 2014 at 02:18:07PM +1000, Stephen Rothwell wrote:
> > > Hi Greg,
> > >
> > > After merging the staging tree, today's linux-next build (powerpc
> > > allyesconfig) failed like this:
> > >
> > > drivers/staging/board/board.c: In function 'find_by_address':
> > > drivers/staging/board/board.c:14:3: error: implicit declaration of
> > > function 'of_can_translate_address'
> > > [-Werror=implicit-function-declaration]
> > >if (of_can_translate_address(dn)
> > >^
> > >
> > > Caused by commit 382063d91e15 ("staging: board: Initial board staging
> > > support").
> > >
> > > I have disabled that driver for today.
> > >
> > > From: Stephen Rothwell
> > > Date: Fri, 20 Jun 2014 14:14:17 +1000
> > > Subject: [PATCH] staging: board: disable
> > >
> > > Signed-off-by: Stephen Rothwell
> > > ---
> > > drivers/staging/board/Kconfig | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/staging/board/Kconfig b/drivers/staging/board/Kconfig
> > > index 09d94b48c9c9..7eda0b8b7aab 100644
> > > --- a/drivers/staging/board/Kconfig
> > > +++ b/drivers/staging/board/Kconfig
> > > @@ -1,6 +1,7 @@
> > > config STAGING_BOARD
> > > boolean "Staging Board Support"
> > > depends on OF_ADDRESS
> > > + depends on BROKEN
> > > help
> > > Select to enable per-board staging support code.
> > >
> >
> > Magnus, can you send me a proper patch for this to get the code back to
> > building condition?
>
> Ping?
Magnus went quiet...
Magnus?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next v2] r8152: support jumbo frame for RTL8153
The maximum jumbo frame size for RTL8153 is 9K bytes.
Change the max rx packet size to 9K.
Change the use of the shared fifo from 6K (default) to 12K for tx.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 36
1 file changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index e9685ce..7d2dd80 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -59,6 +59,7 @@
#define PLA_WDT6_CTRL 0xe428
#define PLA_TCR0 0xe610
#define PLA_TCR1 0xe612
+#define PLA_MTPS 0xe615
#define PLA_TXFIFO_CTRL0xe618
#define PLA_RSTTALLY 0xe800
#define PLA_CR 0xe813
@@ -180,6 +181,10 @@
/* PLA_TCR1 */
#define VERSION_MASK 0x7cf0
+/* PLA_MTPS */
+#define MTPS_JUMBO (12 * 1024 / 64)
+#define MTPS_DEFAULT (6 * 1024 / 64)
+
/* PLA_RSTTALLY */
#define TALLY_RESET0x0001
@@ -440,7 +445,10 @@ enum rtl_register_content {
#define BYTE_EN_START_MASK 0x0f
#define BYTE_EN_END_MASK 0xf0
+#define RTL8153_MAX_PACKET 9216 /* 9K */
+#define RTL8153_MAX_MTU(RTL8153_MAX_PACKET - VLAN_ETH_HLEN -
VLAN_HLEN)
#define RTL8152_RMS(VLAN_ETH_FRAME_LEN + VLAN_HLEN)
+#define RTL8153_RMSRTL8153_MAX_PACKET
#define RTL8152_TX_TIMEOUT (5 * HZ)
/* rtl8152 flags */
@@ -2522,7 +2530,8 @@ static void r8153_first_init(struct r8152 *tp)
ocp_data &= ~CPCR_RX_VLAN;
ocp_write_word(tp, MCU_TYPE_PLA, PLA_CPCR, ocp_data);
- ocp_write_word(tp, MCU_TYPE_PLA, PLA_RMS, RTL8152_RMS);
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_RMS, RTL8153_RMS);
+ ocp_write_byte(tp, MCU_TYPE_PLA, PLA_MTPS, MTPS_JUMBO);
ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_TCR0);
ocp_data |= TCR0_AUTO_FIFO;
@@ -2572,7 +2581,7 @@ static void r8153_enter_oob(struct r8152 *tp)
mdelay(1);
}
- ocp_write_word(tp, MCU_TYPE_PLA, PLA_RMS, RTL8152_RMS);
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_RMS, RTL8153_RMS);
ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_TEREDO_CFG);
ocp_data &= ~TEREDO_WAKE_MASK;
@@ -3284,6 +3293,26 @@ out:
return res;
}
+static int rtl8152_change_mtu(struct net_device *dev, int new_mtu)
+{
+ struct r8152 *tp = netdev_priv(dev);
+
+ switch (tp->version) {
+ case RTL_VER_01:
+ case RTL_VER_02:
+ return eth_change_mtu(dev, new_mtu);
+ default:
+ break;
+ }
+
+ if (new_mtu < 68 || new_mtu > RTL8153_MAX_MTU)
+ return -EINVAL;
+
+ dev->mtu = new_mtu;
+
+ return 0;
+}
+
static const struct net_device_ops rtl8152_netdev_ops = {
.ndo_open = rtl8152_open,
.ndo_stop = rtl8152_close,
@@ -3292,8 +3321,7 @@ static const struct net_device_ops rtl8152_netdev_ops = {
.ndo_tx_timeout = rtl8152_tx_timeout,
.ndo_set_rx_mode= rtl8152_set_rx_mode,
.ndo_set_mac_address= rtl8152_set_mac_address,
-
- .ndo_change_mtu = eth_change_mtu,
+ .ndo_change_mtu = rtl8152_change_mtu,
.ndo_validate_addr = eth_validate_addr,
};
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usbnet: smsc95xx: add reset_resume function with reset operation
The smsc95xx needs to resume with reset operation. Otherwise it causes
system hang by network error like below after resume. This case appears
on odroid u3 board.
[9.727600] smsc95xx 1-2:1.0 eth0: kevent 2 may have been dropped
[9.727648] smsc95xx 1-2:1.0 eth0: kevent 2 may have been dropped
[9.727689] smsc95xx 1-2:1.0 eth0: kevent 2 may have been dropped
[9.727728] smsc95xx 1-2:1.0 eth0: kevent 2 may have been dropped
[9.729486] PM: resume of devices complete after 2011.219 msecs
[ 10.117609] Restarting tasks ... done.
[ 11.725099] smsc95xx 1-2:1.0 eth0: kevent 2 may have been dropped
[ 13.480846] smsc95xx 1-2:1.0 eth0: kevent 2 may have been dropped
[ 13.481361] smsc95xx 1-2:1.0 eth0: kevent 2 may have been dropped
...
Signed-off-by: Joonyoung Shim
---
drivers/net/usb/smsc95xx.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
index 424db65e..d07bf4c 100644
--- a/drivers/net/usb/smsc95xx.c
+++ b/drivers/net/usb/smsc95xx.c
@@ -1714,6 +1714,18 @@ static int smsc95xx_resume(struct usb_interface *intf)
return ret;
}
+static int smsc95xx_reset_resume(struct usb_interface *intf)
+{
+ struct usbnet *dev = usb_get_intfdata(intf);
+ int ret;
+
+ ret = smsc95xx_reset(dev);
+ if (ret < 0)
+ return ret;
+
+ return smsc95xx_resume(intf);
+}
+
static void smsc95xx_rx_csum_offload(struct sk_buff *skb)
{
skb->csum = *(u16 *)(skb_tail_pointer(skb) - 2);
@@ -2004,7 +2016,7 @@ static struct usb_driver smsc95xx_driver = {
.probe = usbnet_probe,
.suspend= smsc95xx_suspend,
.resume = smsc95xx_resume,
- .reset_resume = smsc95xx_resume,
+ .reset_resume = smsc95xx_reset_resume,
.disconnect = usbnet_disconnect,
.disable_hub_initiated_lpm = 1,
.supports_autosuspend = 1,
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] sched: Rewrite per entity runnable load average tracking
On Wed, Jul 09, 2014 at 10:08:42AM -0700, bseg...@google.com wrote: > > That I believe is not a problem. It is a matter of when cfs_rq->load.weight > > changes and when we look at it to contribute to the cfs_rq's load_avg. > > Fortunately, we will not miss any change of cfs_rq->load.weight, always > > contributing to the load_avg the right amount. Put another way, we always > > use the right cfs_rq->load.weight. > > You always call __update_load_avg with every needed load.weight, but if > now - sa->last_update_time < 1024, then it will not do anything with > that weight, and the next actual update may be with a different weight. Oh, yes, I finally understand, :) You are right. That is the matter of 1ms period. Within period boundary, everything will be lost. Thanks, Yuyang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend
Preliminary patch. Not tested. Just sending out to give an idea of what I'm
looking to do. Expect a lot more simplification when it's done.
Benefits:
* A lot more simpler code.
* Less stability issues.
* Suspend/resume time would improve.
* Hotplug time would improve.
* Sysfs file permissions would be maintained.
* More policy settings would be maintained across suspend/resume.
* cpufreq stats would be maintained across hotplug for all CPUs.
Change-Id: I39c395e1fee8731880c0fd7c8a9c1d83e2e4b8d0
Signed-off-by: Saravana Kannan
---
drivers/cpufreq/cpufreq.c | 293 +-
1 file changed, 55 insertions(+), 238 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 62259d2..8ca1b6f 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -859,13 +859,13 @@ void cpufreq_sysfs_remove_file(const struct attribute
*attr)
}
EXPORT_SYMBOL(cpufreq_sysfs_remove_file);
-/* symlink affected CPUs */
+/* symlink related CPUs */
static int cpufreq_add_dev_symlink(struct cpufreq_policy *policy)
{
unsigned int j;
int ret = 0;
- for_each_cpu(j, policy->cpus) {
+ for_each_cpu(j, policy->related_cpus) {
struct device *cpu_dev;
if (j == policy->cpu)
@@ -881,12 +881,16 @@ static int cpufreq_add_dev_symlink(struct cpufreq_policy
*policy)
return ret;
}
-static int cpufreq_add_dev_interface(struct cpufreq_policy *policy,
-struct device *dev)
+static int cpufreq_add_dev_interface(struct cpufreq_policy *policy)
{
struct freq_attr **drv_attr;
+ struct device *dev;
int ret = 0;
+ dev = get_cpu_device(policy->cpu);
+ if (!dev)
+ return -EINVAL;
+
/* prepare interface data */
ret = kobject_init_and_add(>kobj, _cpufreq,
>kobj, "cpufreq");
@@ -961,12 +965,13 @@ static void cpufreq_init_policy(struct cpufreq_policy
*policy)
}
#ifdef CONFIG_HOTPLUG_CPU
-static int cpufreq_add_policy_cpu(struct cpufreq_policy *policy,
- unsigned int cpu, struct device *dev)
+static int cpufreq_change_policy_cpus(struct cpufreq_policy *policy,
+ unsigned int cpu, bool add)
{
int ret = 0;
unsigned long flags;
+ /* FIXME: Don't send START/STOP when going from/to 0 cpus */
if (has_target()) {
ret = __cpufreq_governor(policy, CPUFREQ_GOV_STOP);
if (ret) {
@@ -979,7 +984,11 @@ static int cpufreq_add_policy_cpu(struct cpufreq_policy
*policy,
write_lock_irqsave(_driver_lock, flags);
- cpumask_set_cpu(cpu, policy->cpus);
+ if (add)
+ cpumask_set_cpu(cpu, policy->cpus);
+ else
+ cpumask_clear_cpu(cpu, policy->cpus);
+
per_cpu(cpufreq_cpu_data, cpu) = policy;
write_unlock_irqrestore(_driver_lock, flags);
@@ -995,27 +1004,9 @@ static int cpufreq_add_policy_cpu(struct cpufreq_policy
*policy,
return ret;
}
}
-
- return sysfs_create_link(>kobj, >kobj, "cpufreq");
}
#endif
-static struct cpufreq_policy *cpufreq_policy_restore(unsigned int cpu)
-{
- struct cpufreq_policy *policy;
- unsigned long flags;
-
- read_lock_irqsave(_driver_lock, flags);
-
- policy = per_cpu(cpufreq_cpu_data_fallback, cpu);
-
- read_unlock_irqrestore(_driver_lock, flags);
-
- policy->governor = NULL;
-
- return policy;
-}
-
static struct cpufreq_policy *cpufreq_policy_alloc(void)
{
struct cpufreq_policy *policy;
@@ -1076,22 +1067,6 @@ static void cpufreq_policy_free(struct cpufreq_policy
*policy)
kfree(policy);
}
-static void update_policy_cpu(struct cpufreq_policy *policy, unsigned int cpu)
-{
- if (WARN_ON(cpu == policy->cpu))
- return;
-
- down_write(>rwsem);
-
- policy->last_cpu = policy->cpu;
- policy->cpu = cpu;
-
- up_write(>rwsem);
-
- blocking_notifier_call_chain(_policy_notifier_list,
- CPUFREQ_UPDATE_POLICY_CPU, policy);
-}
-
static int __cpufreq_add_dev(struct device *dev, struct subsys_interface *sif)
{
unsigned int j, cpu = dev->id;
@@ -,55 +1086,28 @@ static int __cpufreq_add_dev(struct device *dev, struct
subsys_interface *sif)
#ifdef CONFIG_SMP
/* check whether a different CPU already registered this
* CPU because it is in the same boat. */
+ /* FIXME: This probably needs fixing to avoid "try lock" from
+* returning NULL. Also, change to likely() */
policy = cpufreq_cpu_get(cpu);
if (unlikely(policy)) {
+ cpufreq_change_policy_cpus(policy, cpu, true);
cpufreq_cpu_put(policy);
return 0;
}
#endif
+ /* FIXME: Is returning 0 the right thing to do?! Existing code
[PATCH] ARM: mm: fix the boundary checking on bitmaps
The issue of boundary checking on bitmaps is introduced by this commit
in below.
commit 4d852ef8c2544ce21ae41414099a7504c61164a0
Author: Andreas Herrmann
Date: Tue Feb 25 13:09:53 2014 +0100
arm: dma-mapping: Add support to extend DMA IOMMU mappings
Multiple bitmaps were introduced as extension. If it needs to extend
a bitmap, it still check whether the allocation exceeding the total
size, not current bitmap size. So change the condition from
mapping->bits to PAGE_SIZE.
Signed-off-by: Haojian Zhuang
---
arch/arm/mm/dma-mapping.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 4c88935..d7da5c3 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1089,9 +1089,9 @@ static inline dma_addr_t __alloc_iova(struct
dma_iommu_mapping *mapping,
spin_lock_irqsave(>lock, flags);
for (i = 0; i < mapping->nr_bitmaps; i++) {
start = bitmap_find_next_zero_area(mapping->bitmaps[i],
- mapping->bits, 0, count, align);
+ PAGE_SIZE, 0, count, align);
- if (start > mapping->bits)
+ if (start > PAGE_SIZE)
continue;
bitmap_set(mapping->bitmaps[i], start, count);
@@ -1110,9 +1110,9 @@ static inline dma_addr_t __alloc_iova(struct
dma_iommu_mapping *mapping,
}
start = bitmap_find_next_zero_area(mapping->bitmaps[i],
- mapping->bits, 0, count, align);
+ PAGE_SIZE, 0, count, align);
- if (start > mapping->bits) {
+ if (start > PAGE_SIZE) {
spin_unlock_irqrestore(>lock, flags);
return DMA_ERROR_CODE;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] video: backlight: jornada720_lcd.c: Cleaning up variable that is never used
On Thursday, July 10, 2014 7:08 AM, Rickard Strandqvist wrote:
> 2014-07-09 18:30 GMT+02:00 Lee Jones :
> > On Mon, 07 Jul 2014, Rickard Strandqvist wrote:
> >
> >> Variable ar assigned a value that is never used.
> >> I have also removed all the code that thereby serves no purpose,
> >> and made same change to clarify the similarities in function.
> >>
> >> This was found using a static code analysis program called cppcheck
> >>
> >> Signed-off-by: Rickard Strandqvist
> >> ---
> >> drivers/video/backlight/jornada720_lcd.c | 31
> >> ++
> >> 1 file changed, 14 insertions(+), 17 deletions(-)
> >>
> >> diff --git a/drivers/video/backlight/jornada720_lcd.c
> >> b/drivers/video/backlight/jornada720_lcd.c
> >> index da3876c..d16abcf 100644
> >> --- a/drivers/video/backlight/jornada720_lcd.c
> >> +++ b/drivers/video/backlight/jornada720_lcd.c
> >> @@ -36,44 +36,41 @@ static int jornada_lcd_get_power(struct lcd_device *ld)
> >>
> >> static int jornada_lcd_get_contrast(struct lcd_device *ld)
> >> {
> >> - int ret;
> >> + int ret = -ETIMEDOUT;
> >>
> >> if (jornada_lcd_get_power(ld) != FB_BLANK_UNBLANK)
> >> return 0;
> >>
> >> jornada_ssp_start();
> >>
> >> - if (jornada_ssp_byte(GETCONTRAST) != TXDUMMY) {
> >> + if (jornada_ssp_byte(GETCONTRAST) != TXDUMMY)
> >> dev_err(>dev, "get contrast failed\n");
> >> - jornada_ssp_end();
> >> - return -ETIMEDOUT;
> >> - } else {
> >> + else
> >> ret = jornada_ssp_byte(TXDUMMY);
> >> - jornada_ssp_end();
> >> - return ret;
> >> - }
> >> +
> >> + jornada_ssp_end();
> >> +
> >> + return ret;
> >> }
> >>
> >> static int jornada_lcd_set_contrast(struct lcd_device *ld, int value)
> >> {
> >> - int ret;
> >> + int ret = -ETIMEDOUT;
> >>
> >> jornada_ssp_start();
> >>
> >> /* start by sending our set contrast cmd to mcu */
> >> - ret = jornada_ssp_byte(SETCONTRAST);
> >> -
> >> + if (jornada_ssp_byte(SETCONTRAST) != TXDUMMY)
> >> + dev_err(>dev, "set contrast failed\n");
> >> /* push the new value */
> >> - if (jornada_ssp_byte(value) != TXDUMMY) {
> >> + else if (jornada_ssp_byte(value) != TXDUMMY)
> >> dev_err(>dev, "set contrast failed\n");
> >> - jornada_ssp_end();
> >> - return -ETIMEDOUT;
> >> - }
> >> + else /* if we get here we can assume everything went well */
> >> + ret = 0;
> >>
> >> - /* if we get here we can assume everything went well */
> >> jornada_ssp_end();
> >>
> >> - return 0;
> >> + return ret;
> >> }
> >>
> >> static int jornada_lcd_set_power(struct lcd_device *ld, int power)
> >
> > Counter suggestion.
> >
> > What do you think, I think this looks cleaner:
> >
> > static int jornada_lcd_get_contrast(struct lcd_device *ld)
> > {
> > int ret;
> >
> > if (jornada_lcd_get_power(ld) != FB_BLANK_UNBLANK)
> > return 0;
> >
> > jornada_ssp_start();
> >
> > if (jornada_ssp_byte(GETCONTRAST) == TXDUMMY) {
> > ret = jornada_ssp_byte(TXDUMMY);
> > goto success;
> > }
> >
> > dev_err(>dev, "failed to set contrast\n");
> > ret = -ETIMEDOUT;
> >
> > success:
> > jornada_ssp_end();
> > return ret;
> > }
> >
> > static int jornada_lcd_set_contrast(struct lcd_device *ld, int value)
> > {
> > int ret = 0;
> >
> > jornada_ssp_start();
> >
> > /* start by sending our set contrast cmd to mcu */
> > if (jornada_ssp_byte(SETCONTRAST) == TXDUMMY) {
> > /* if successful, push the new value */
> > if (jornada_ssp_byte(value) == TXDUMMY)
> > goto success;
> > }
> >
> > dev_err(>dev, "failed to set contrast\n");
> > ret = -ETIMEDOUT;
> >
> > success:
> > jornada_ssp_end();
> > return ret;
> > }
>
>
> Hi Lee!
>
> Yes, I agree!
> Both are clean without so much repetition of code, which was what annoyd me.
> But yours is clearer when things go good or bad, nice 1 ;)
Hi Rickard Strandqvist,
I would liked to prefer Lee Jones's code. It looks cleaner.
>
> I do not know what I can/may do, but I'll try. Remove what is not ok :-)
>
> Reviewed-by: Rickard Strandqvist
> Suggested-by: Rickard Strandqvist
I suggest the following.
Suggested-by: Rickard Strandqvist
Signed-off-by: Lee Jones
Acked-by: Jingoo Han
Cc: Bryan Wu
Best regards,
Jingoo Han
>
>
> Kind regards
> Rickard Strandqvist
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] GPIO button wth wakeup attribute is supposed to wake the system up
On 2014/7/9 20:45, Rafael J. Wysocki wrote:
> On Tuesday, July 08, 2014 05:54:35 PM Dmitry Torokhov wrote:
>> On Wed, Jul 09, 2014 at 02:59:33AM +0200, Rafael J. Wysocki wrote:
>>> On Tuesday, July 08, 2014 05:15:06 PM Dmitry Torokhov wrote:
On Wed, Jul 09, 2014 at 01:06:07AM +0200, Rafael J. Wysocki wrote:
>
> [cut]
>
When device driver marks IRQ as a wakeup source I believe it is prepared
to handle it (or it would shut it off explicitly).
>>>
>>> I can agree with that.
>>>
>>> Are you suggesting that __disable_irq() should check irq_data for
>>> IRQD_WAKEUP_STATE and skip the IRQ (in the 'suspend' case) if that is set?
>>
>> Yes, something like that.
>
> OK
Many thanks to you both for the discussion.
>
> Aubrey, can you please check if the appended patch helps on the T100?
I verified this patch on T100, it works as expected, freeze can be waken
up by reverting my patch and applying this one.
Is this a final solution?
Thanks,
-Aubrey
>
> Rafael
>
> ---
> kernel/irq/manage.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> Index: linux-pm/kernel/irq/manage.c
> ===
> --- linux-pm.orig/kernel/irq/manage.c
> +++ linux-pm/kernel/irq/manage.c
> @@ -385,7 +385,8 @@ setup_affinity(unsigned int irq, struct
> void __disable_irq(struct irq_desc *desc, unsigned int irq, bool suspend)
> {
> if (suspend) {
> - if (!desc->action || (desc->action->flags & IRQF_NO_SUSPEND))
> + if (!desc->action || (desc->action->flags & IRQF_NO_SUSPEND)
> + || irqd_has_set(>irq_data, IRQD_WAKEUP_STATE))
> return;
> desc->istate |= IRQS_SUSPENDED;
> }
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] ARM: at91: remove phy fixup for sama5d3xek boards
Hi Boris, On 07/10/2014 12:34 AM, Boris BREZILLON wrote: Hello Bo, I know you're quite busy, but if you have some time could you test this series on both CPU Modules (Embest and Ronetix): I only own the Embest one. Best Regards, Boris On Thu, 26 Jun 2014 12:13:33 +0200 Boris BREZILLON wrote: Hello, This patch removes a board specific hook for sama5d3xek boards from the sama5d3 generic DT board file. This hook (which register a phy fixup configuring board specific delays in the ksz9021 ethernet phy) is now replaced by the appropriate DT properties definitions in the sama5d3xcm.dtsi file. Best Regards, Boris Changes since v1: - fix txc-skew-ps and rxc-skew-ps delays - remove phy address info to handle Ronetix and Embest HW designs Boris BREZILLON (2): ARM: at91/dt: describe rgmii ethernet phy connected to sama5d3xek boards ARM: at91: remove phy fixup for sama5d3xek boards arch/arm/boot/dts/sama5d3xcm.dtsi | 15 +++ arch/arm/mach-at91/board-dt-sama5.c | 22 -- 2 files changed, 15 insertions(+), 22 deletions(-) For this series, test OK on sama5d33ek (Ronetix) and sama5d34ek (Embest). Tested-by: Bo Shen Best Regards, Bo Shen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] staging: rtl8188eu: Remove WEXT_PRIV private ioctl handlers
On Thu, Jul 10, 2014 at 06:56:39AM +0530, navin patidar wrote: > On Thu, Jul 10, 2014 at 6:29 AM, Greg KH wrote: > > On Thu, Jul 10, 2014 at 06:24:21AM +0530, navin patidar wrote: > >> On Thu, Jul 10, 2014 at 12:34 AM, Greg KH > >> wrote: > >> > On Tue, Jul 01, 2014 at 10:35:09PM +0530, navin patidar wrote: > >> >> Remove WEXT_PRIV (non-standard) ioctl handlers. > >> >> > >> >> Signed-off-by: navin patidar > >> >> --- > >> >> drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 6335 > >> >> +++- > >> >> 1 file changed, 744 insertions(+), 5591 deletions(-) > >> > > >> > This patch fails to apply :( > >> > > >> > Can you refresh it, and resend this series? > >> > >> Please apply following patches. > >> > >> [PATCH v2 1/3] staging: rtl8188eu: re-use mac_pton() helper > >> [PATCH v2 2/3] staging: rtl8188eu: substitute custom hex2bin() > >> [PATCH v2 3/3] staging: rtl8188eu: re-use hex_to_bin() instead of custom > >> code > >> > >> Then try again to apply my patches. > > > > I don't have those, sorry, my patch queue for staging patches are now > > empty as of everything sent up to yesterday. Please resend what you > > want me to apply, in the order in which you want me to apply it. > > Is it okay if i send you a single patch set having my three patch set and > Andy Shevchenko's patches ? I don't care :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/7] hrtimer: drop active hrtimer checks after adding it
On Wed, Jul 09, 2014 at 11:30:41PM +0200, Thomas Gleixner wrote:
> On Wed, 9 Jul 2014, Viresh Kumar wrote:
>
> So your patch series drops active hrtimer checks after adding it,
> according to your subject line.
>
> Quite useeul to drop something after adding it, right?
>
> > hrtimer_start*() family never fails to enqueue a hrtimer to a clock-base.
> > The
> > only special case is when the hrtimer was in past. If it is getting
> > enqueued to
> > local CPUs's clock-base, we raise a softirq and exit, else we handle that on
> > next interrupt on remote CPU.
> >
> > At several places in the kernel, we try to make sure if hrtimer was added
> > properly or not by calling hrtimer_active(), like:
> >
> > hrtimer_start(timer, expires, mode);
> > if (hrtimer_active(timer)) {
> > /* Added successfully */
> > } else {
> > /* Was added in the past */
> > }
> >
> > As hrtimer_start*() never fails, hrtimer_active() is guaranteed to return
> > '1'.
> > So, there is no point calling hrtimer_active().
>
> Wrong as usual.
>
> It's a common pattern that short timeouts are given which lead to
> immediate expiry so the extra round through schedule is even more
> pointless than the extra check.
It may be a common pattern but it's not obvious at all as is in the code
except for timers gurus.
It looks like error handling while it's actually an optimization.
Also what about this pattern when it's used in interrupt or interrupt-disabled
code?
In this case the handler is not going to fire right away, unless it's enqueued
on another CPU for unpinned timers.
For example this code in tick_nohz_stop_sched_tick():
hrtimer_start(>sched_timer, expires, HRTIMER_MODE_ABS_PINNED);
/* Check, if the timer was already in the past */
if (hrtimer_active(>sched_timer))
goto out;
It's not clear what this is handling. Concurrent immediate callback expiration
from another CPU?
But the timer is pinned local so it can't execute right away between
hrtimer_start() and hrtimer_active()
check...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH NET-NEXT V2] netxen: fix ethtool rx_dropped information in ethtool get_ethtool_stats()
On 2014/7/9 19:45, vaughan wrote:
On 07/09/2014 07:32 PM, Manish Chopra wrote:
-Original Message-
From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
On Behalf Of ethan zhao
Sent: Wednesday, July 09, 2014 8:11 AM
To: David Miller
Cc: ba...@ti.com; netdev; linux-kernel; sriharsha.dev...@oracle.com;
ethan.ker...@gmail.com; vaughan
Subject: Re: [PATCH NET-NEXT V2] netxen: fix ethtool rx_dropped information in
ethtool get_ethtool_stats()
David,
Please help to review and confirm this patch.
Thanks,
Ethan
On 2014/7/8 21:57, Ethan Zhao wrote:
netxen driver has implemented netxen_nic_get_ethtool_stats()
interface, but it doesn't collect stats.rxdropped in driver, so we
will get different rx_dropped statistic information while using ifconfig and
ethtool.
this patch fills stats.rxdropped field with data from net core with
dev_get_stats() just as ixgbe driver did for some of its stats.
V2: only fix the stats.rxdropped field.
Tested with last netxen 4.0.82
Compiled with net-next branch 3.16-rc2
Signed-off-by: Ethan Zhao
Tested-by: Sriharsha Yadagudde
---
.../ethernet/qlogic/netxen/netxen_nic_ethtool.c| 34 +-
--
1 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
index 4ca2c19..49e6a1b 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_ethtool.c
@@ -33,22 +33,30 @@
#include "netxen_nic.h"
#include "netxen_nic_hw.h"
+enum {NETDEV_STATS, NETXEN_STATS};
+
struct netxen_nic_stats {
char stat_string[ETH_GSTRING_LEN];
+ int type;
int sizeof_stat;
int stat_offset;
};
-#define NETXEN_NIC_STAT(m) sizeof(((struct netxen_adapter *)0)->m), \
+#define NETXEN_NIC_STAT(m) NETXEN_STATS, \
+ sizeof(((struct netxen_adapter *)0)->m), \
offsetof(struct netxen_adapter, m)
+#define NETXEN_NETDEV_STAT(m) NETDEV_STATS, \
+ sizeof(((struct rtnl_link_stats64 *)0)->m), \
+ offsetof(struct rtnl_link_stats64, m)
+
#define NETXEN_NIC_PORT_WINDOW 0x1
#define NETXEN_NIC_INVALID_DATA 0xDEADBEEF
static const struct netxen_nic_stats netxen_nic_gstrings_stats[] = {
{"xmit_called", NETXEN_NIC_STAT(stats.xmitcalled)},
{"xmit_finished", NETXEN_NIC_STAT(stats.xmitfinished)},
- {"rx_dropped", NETXEN_NIC_STAT(stats.rxdropped)},
+ {"rx_dropped", NETXEN_NETDEV_STAT(rx_dropped)},
{"tx_dropped", NETXEN_NIC_STAT(stats.txdropped)},
{"csummed", NETXEN_NIC_STAT(stats.csummed)},
{"rx_pkts", NETXEN_NIC_STAT(stats.rx_pkts)}, @@ -679,11 +687,27 @@
netxen_nic_get_ethtool_stats(struct net_device *dev,
{
struct netxen_adapter *adapter = netdev_priv(dev);
int index;
+ struct rtnl_link_stats64 temp;
+ const struct rtnl_link_stats64 *net_stats;
+ char *p = NULL;
+ net_stats = dev_get_stats(dev, );
for (index = 0; index < NETXEN_NIC_STATS_LEN; index++) {
- char *p =
- (char *)adapter +
- netxen_nic_gstrings_stats[index].stat_offset;
+
+ switch (netxen_nic_gstrings_stats[index].type) {
+ case NETDEV_STATS:
+ p = (char *)net_stats +
+ netxen_nic_gstrings_stats[index].stat_offset;
+ break;
+ case NETXEN_STATS:
+ p = (char *)adapter +
+ netxen_nic_gstrings_stats[index].stat_offset;
+ break;
+ default:
+ data[index] = 0;
+ continue;
+ }
+
data[index] =
(netxen_nic_gstrings_stats[index].sizeof_stat ==
sizeof(u64)) ? *(u64 *) p : *(u32 *) p;
Ethan, I can't download this patch as I don’t see it in netdev patchwork. Just
looking at the diff I think there is style issue with macro definition of
NETXEN_NIC_STAT and NETXEN_NETDEV_STAT.
Enclose macro definition in parentheses as they are containing complex values.
It's not an error as checkpatch.pl indicates. As the definition of
netxen_nic_stats shows,
struct netxen_nic_stats {
char stat_string[ETH_GSTRING_LEN];
+ int type;
int sizeof_stat;
int stat_offset;
};
This macros consists of multiple elements, which shouldn't be enclosed
in parentheses.
Agree, I am sure it is error of checkpatch.pl.
Thanks,
Ethan
Send this patch targeted for net instead of net-next being a bug fix. Please
also run checkpatch.pl to correct any style warning/errors in the patch.
Thanks!!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
Re: [PATCH 1/5] staging: rtl8188eu: Remove WEXT_PRIV private ioctl handlers
On Thu, Jul 10, 2014 at 6:29 AM, Greg KH wrote: > On Thu, Jul 10, 2014 at 06:24:21AM +0530, navin patidar wrote: >> On Thu, Jul 10, 2014 at 12:34 AM, Greg KH wrote: >> > On Tue, Jul 01, 2014 at 10:35:09PM +0530, navin patidar wrote: >> >> Remove WEXT_PRIV (non-standard) ioctl handlers. >> >> >> >> Signed-off-by: navin patidar >> >> --- >> >> drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 6335 >> >> +++- >> >> 1 file changed, 744 insertions(+), 5591 deletions(-) >> > >> > This patch fails to apply :( >> > >> > Can you refresh it, and resend this series? >> >> Please apply following patches. >> >> [PATCH v2 1/3] staging: rtl8188eu: re-use mac_pton() helper >> [PATCH v2 2/3] staging: rtl8188eu: substitute custom hex2bin() >> [PATCH v2 3/3] staging: rtl8188eu: re-use hex_to_bin() instead of custom code >> >> Then try again to apply my patches. > > I don't have those, sorry, my patch queue for staging patches are now > empty as of everything sent up to yesterday. Please resend what you > want me to apply, in the order in which you want me to apply it. Is it okay if i send you a single patch set having my three patch set and Andy Shevchenko's patches ? regards, navin patidar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scripts: modpost: Remove numeric suffix pattern matching
Sam Ravnborg writes: > On Wed, Jul 09, 2014 at 11:41:48AM +0200, Rasmus Villemoes wrote: >> For several years, the pattern "foo$" has effectively been treated as >> equivalent to "foo" due to a bug in the (misnamed) helper >> number_prefix(). This hasn't been observed to cause any problems, so >> remove the broken $ functionality and change all foo$ patterns to foo. >> >> Signed-off-by: Rasmus Villemoes >> --- >> Sam, was this what you meant? Otherwise, I'd be more than happy to >> leave the issue to someone else. > Exactly - thanks. > Acked-by: Sam Ravnborg > > Rusty - I assume you pick this up and channel it through the module tree. > > Sam Done, thanks! Applied, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] xhci: Introduce xhci_init_driver()
Since the struct hc_driver is mostly the same across the xhci-pci,
xhci-plat, and the upcoming xhci-tegra driver, introduce the function
xhci_init_driver() which will populate the hc_driver with the default
xHCI operations. The caller must supply a setup function which will
be used as the hc_driver's reset callback.
Signed-off-by: Andrew Bresticker
---
drivers/usb/host/xhci-pci.c | 69 +---
drivers/usb/host/xhci-plat.c | 60 +++---
drivers/usb/host/xhci.c | 68 +++
drivers/usb/host/xhci.h | 1 +
4 files changed, 80 insertions(+), 118 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index e20520f..97648e4 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -40,6 +40,8 @@
static const char hcd_name[] = "xhci_hcd";
+static struct hc_driver __read_mostly xhci_pci_hc_driver;
+
/* called after powerup, by probe or system-pm "wakeup" */
static int xhci_pci_reinit(struct xhci_hcd *xhci, struct pci_dev *pdev)
{
@@ -313,68 +315,6 @@ static int xhci_pci_resume(struct usb_hcd *hcd, bool
hibernated)
}
#endif /* CONFIG_PM */
-static const struct hc_driver xhci_pci_hc_driver = {
- .description = hcd_name,
- .product_desc = "xHCI Host Controller",
- .hcd_priv_size =sizeof(struct xhci_hcd *),
-
- /*
-* generic hardware linkage
-*/
- .irq = xhci_irq,
- .flags =HCD_MEMORY | HCD_USB3 | HCD_SHARED,
-
- /*
-* basic lifecycle operations
-*/
- .reset =xhci_pci_setup,
- .start =xhci_run,
-#ifdef CONFIG_PM
- .pci_suspend = xhci_pci_suspend,
- .pci_resume = xhci_pci_resume,
-#endif
- .stop = xhci_stop,
- .shutdown = xhci_shutdown,
-
- /*
-* managing i/o requests and associated device resources
-*/
- .urb_enqueue = xhci_urb_enqueue,
- .urb_dequeue = xhci_urb_dequeue,
- .alloc_dev =xhci_alloc_dev,
- .free_dev = xhci_free_dev,
- .alloc_streams =xhci_alloc_streams,
- .free_streams = xhci_free_streams,
- .add_endpoint = xhci_add_endpoint,
- .drop_endpoint =xhci_drop_endpoint,
- .endpoint_reset = xhci_endpoint_reset,
- .check_bandwidth = xhci_check_bandwidth,
- .reset_bandwidth = xhci_reset_bandwidth,
- .address_device = xhci_address_device,
- .enable_device =xhci_enable_device,
- .update_hub_device =xhci_update_hub_device,
- .reset_device = xhci_discover_or_reset_device,
-
- /*
-* scheduling support
-*/
- .get_frame_number = xhci_get_frame,
-
- /* Root hub support */
- .hub_control = xhci_hub_control,
- .hub_status_data = xhci_hub_status_data,
- .bus_suspend = xhci_bus_suspend,
- .bus_resume = xhci_bus_resume,
- /*
-* call back when device connected and addressed
-*/
- .update_device =xhci_update_device,
- .set_usb2_hw_lpm = xhci_set_usb2_hardware_lpm,
- .enable_usb3_lpm_timeout = xhci_enable_usb3_lpm_timeout,
- .disable_usb3_lpm_timeout = xhci_disable_usb3_lpm_timeout,
- .find_raw_port_number = xhci_find_raw_port_number,
-};
-
/*-*/
/* PCI driver selection metadata; PCI hotplugging uses this */
@@ -406,6 +346,11 @@ static struct pci_driver xhci_pci_driver = {
int __init xhci_register_pci(void)
{
+ xhci_init_driver(_pci_hc_driver, xhci_pci_setup);
+#ifdef CONFIG_PM
+ xhci_pci_hc_driver.pci_suspend = xhci_pci_suspend;
+ xhci_pci_hc_driver.pci_resume = xhci_pci_resume;
+#endif
return pci_register_driver(_pci_driver);
}
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 29d8adb..49799db 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -21,6 +21,8 @@
#include "xhci.h"
#include "xhci-mvebu.h"
+static struct hc_driver __read_mostly xhci_plat_hc_driver;
+
static void xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci)
{
/*
@@ -37,61 +39,6 @@ static int xhci_plat_setup(struct usb_hcd *hcd)
return xhci_gen_setup(hcd, xhci_plat_quirks);
}
-static int xhci_plat_start(struct usb_hcd *hcd)
-{
- return xhci_run(hcd);
-}
-
-static const struct hc_driver xhci_plat_xhci_driver = {
- .description = "xhci-hcd",
- .product_desc = "xHCI Host Controller",
- .hcd_priv_size =sizeof(struct xhci_hcd *),
-
- /*
-* generic hardware linkage
-*/
- .irq =
[PATCH 3/4] xhci: Export symbols used by host-controller drivers
In preparation for allowing the xHCI host controller drivers to be built
as separate modules, export symbols from the xHCI core that may be used
by the host controller drivers.
Signed-off-by: Andrew Bresticker
---
drivers/usb/host/xhci-dbg.c | 1 +
drivers/usb/host/xhci.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index eb009a4..bb89175 100644
--- a/drivers/usb/host/xhci-dbg.c
+++ b/drivers/usb/host/xhci-dbg.c
@@ -594,3 +594,4 @@ void xhci_dbg_trace(struct xhci_hcd *xhci, void
(*trace)(struct va_format *),
trace();
va_end(args);
}
+EXPORT_SYMBOL_GPL(xhci_dbg_trace);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index f681087..4958a60 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -927,6 +927,7 @@ int xhci_suspend(struct xhci_hcd *xhci)
return rc;
}
+EXPORT_SYMBOL_GPL(xhci_suspend);
/*
* start xHC (not bus-specific)
@@ -1078,6 +1079,7 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
return retval;
}
+EXPORT_SYMBOL_GPL(xhci_resume);
#endif /* CONFIG_PM */
/*-*/
@@ -4872,6 +4874,7 @@ error:
kfree(xhci);
return retval;
}
+EXPORT_SYMBOL_GPL(xhci_gen_setup);
static const struct hc_driver xhci_hc_driver = {
.description = "xhci-hcd",
--
2.0.0.526.g5318336
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: + shmem-fix-faulting-into-a-hole-while-its-punched-take-2.patch added to -mm tree
On Wed, 9 Jul 2014, Hugh Dickins wrote:
> On Wed, 9 Jul 2014, Vlastimil Babka wrote:
> > On 07/09/2014 06:03 PM, Sasha Levin wrote:
> > >
> > > We can see that it's not blocked since it's in the middle of a spinlock
> > > unlock
> > > call, and we can guess it's been in that function for a while because of
> > > the hung
> > > task timer, and other processes waiting on that i_mmap_mutex:
> >
> > Hm, zap_pte_range has potentially an endless loop due to the 'goto again'
> > path. Could it be a somewhat similar situation to the fallocate problem, but
> > where parallel faulters on shared memory are preventing a process from
> > exiting? Although they don't fault the pages into the same address space,
> > they could maybe somehow interact through the TLB flushing code? And only
> > after fixing the original problem we can observe this one?
>
> That's a good thought. It ought to make forward progress nonetheless,
> but I believe (please check, I'm rushing) that there's an off-by-one in
> that path which could leave us hanging - but only when __tlb_remove_page()
> repeatedly fails, which would only happen if exceptionally low on memory??
>
> Does this patch look good, and does it make any difference to the hang?
I should add that I think that this patch is correct in itself, but
won't actually make any difference to anything. I'm still looking
through Sasha's log for clues (but shall have to give up soon).
Hugh
>
> --- mmotm/mm/memory.c 2014-07-02 15:32:22.212311544 -0700
> +++ linux/mm/memory.c 2014-07-09 09:56:33.724159443 -0700
> @@ -1145,6 +1145,7 @@ again:
> if (unlikely(page_mapcount(page) < 0))
> print_bad_pte(vma, addr, ptent, page);
> if (unlikely(!__tlb_remove_page(tlb, page))) {
> + addr += PAGE_SIZE;
> force_flush = 1;
> break;
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] xhci: Allow xHCI drivers to be built as separate modules
Instead of building all of the xHCI code into a single module, separate
it out into the core (xhci-hcd), PCI (xhci-pci, now selected by the new
config option CONFIG_USB_XHCI_PCI), and platform (xhci-plat) drivers.
Also update the PCI/platform drivers with module descriptions/licenses
and have them register their respective drivers in their initcalls.
Signed-off-by: Andrew Bresticker
---
drivers/usb/host/Kconfig | 5 +
drivers/usb/host/Makefile| 10 +-
drivers/usb/host/xhci-pci.c | 9 +++--
drivers/usb/host/xhci-plat.c | 9 +++--
drivers/usb/host/xhci.c | 22 --
drivers/usb/host/xhci.h | 19 ---
6 files changed, 24 insertions(+), 50 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 03314f8..aea6a13 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -26,6 +26,11 @@ config USB_XHCI_HCD
if USB_XHCI_HCD
+config USB_XHCI_PCI
+ tristate
+ depends on PCI
+ default y
+
config USB_XHCI_PLATFORM
tristate
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index af89a90..bafba71 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -15,19 +15,19 @@ fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o
xhci-hcd-y := xhci.o xhci-mem.o
xhci-hcd-y += xhci-ring.o xhci-hub.o xhci-dbg.o
xhci-hcd-y += xhci-trace.o
-xhci-hcd-$(CONFIG_PCI) += xhci-pci.o
-ifneq ($(CONFIG_USB_XHCI_PLATFORM), )
- xhci-hcd-y += xhci-plat.o
+xhci-plat-hcd-y := xhci-plat.o
ifneq ($(CONFIG_USB_XHCI_MVEBU), )
- xhci-hcd-y += xhci-mvebu.o
-endif
+ xhci-plat-hcd-y += xhci-mvebu.o
endif
obj-$(CONFIG_USB_WHCI_HCD) += whci/
obj-$(CONFIG_PCI) += pci-quirks.o
+obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
+obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o
+
obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o
obj-$(CONFIG_USB_EHCI_HCD_PLATFORM)+= ehci-platform.o
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index d06ffe7..fbfd4a7 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -344,7 +344,7 @@ static struct pci_driver xhci_pci_driver = {
#endif
};
-int __init xhci_register_pci(void)
+static int __init xhci_pci_init(void)
{
xhci_init_driver(_pci_hc_driver, xhci_pci_setup);
#ifdef CONFIG_PM
@@ -353,8 +353,13 @@ int __init xhci_register_pci(void)
#endif
return pci_register_driver(_pci_driver);
}
+module_init(xhci_pci_init);
-void xhci_unregister_pci(void)
+static void __exit xhci_pci_exit(void)
{
pci_unregister_driver(_pci_driver);
}
+module_exit(xhci_pci_exit);
+
+MODULE_DESCRIPTION("xHCI PCI Host Controller Driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 49799db..c324408 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -233,13 +233,18 @@ static struct platform_driver usb_xhci_driver = {
};
MODULE_ALIAS("platform:xhci-hcd");
-int xhci_register_plat(void)
+static int __init xhci_plat_init(void)
{
xhci_init_driver(_plat_hc_driver, xhci_plat_setup);
return platform_driver_register(_xhci_driver);
}
+module_init(xhci_plat_init);
-void xhci_unregister_plat(void)
+static void __exit xhci_plat_exit(void)
{
platform_driver_unregister(_xhci_driver);
}
+module_exit(xhci_plat_exit);
+
+MODULE_DESCRIPTION("xHCI Platform Host Controller Driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 4958a60..3f32b5a 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4951,18 +4951,6 @@ MODULE_LICENSE("GPL");
static int __init xhci_hcd_init(void)
{
- int retval;
-
- retval = xhci_register_pci();
- if (retval < 0) {
- pr_debug("Problem registering PCI driver.\n");
- return retval;
- }
- retval = xhci_register_plat();
- if (retval < 0) {
- pr_debug("Problem registering platform driver.\n");
- goto unreg_pci;
- }
/*
* Check the compiler generated sizes of structures that must be laid
* out in specific ways for hardware access.
@@ -4981,15 +4969,5 @@ static int __init xhci_hcd_init(void)
/* xhci_run_regs has eight fields and embeds 128 xhci_intr_regs */
BUILD_BUG_ON(sizeof(struct xhci_run_regs) != (8+8*128)*32/8);
return 0;
-unreg_pci:
- xhci_unregister_pci();
- return retval;
}
module_init(xhci_hcd_init);
-
-static void __exit xhci_hcd_cleanup(void)
-{
- xhci_unregister_pci();
- xhci_unregister_plat();
-}
-module_exit(xhci_hcd_cleanup);
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 902f55b..ac03d22 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1729,25 +1729,6 @@ void
[PATCH 2/4] xhci: Check for XHCI_COMP_MODE_QUIRK when disabling D3cold
Instead of calling xhci_compliance_mode_recovery_timer_quirk_check() again
in the PCI suspend path, just check for XHCI_COMP_MODE_QUIRK which will
have been set based on xhci_compliance_mode_recovery_timer_quirk_check()
in xhci_init().
Signed-off-by: Andrew Bresticker
---
drivers/usb/host/xhci-pci.c | 2 +-
drivers/usb/host/xhci.c | 3 ++-
drivers/usb/host/xhci.h | 3 ---
3 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 97648e4..d06ffe7 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -277,7 +277,7 @@ static int xhci_pci_suspend(struct usb_hcd *hcd, bool
do_wakeup)
* Systems with the TI redriver that loses port status change events
* need to have the registers polled during D3, so avoid D3cold.
*/
- if (xhci_compliance_mode_recovery_timer_quirk_check())
+ if (xhci->quirks & XHCI_COMP_MODE_QUIRK)
pdev->no_d3cold = true;
return xhci_suspend(xhci);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 8de75b7..f681087 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -491,7 +491,7 @@ static void compliance_mode_recovery_timer_init(struct
xhci_hcd *xhci)
* Systems:
* Vendor: Hewlett-Packard -> System Models: Z420, Z620 and Z820
*/
-bool xhci_compliance_mode_recovery_timer_quirk_check(void)
+static bool xhci_compliance_mode_recovery_timer_quirk_check(void)
{
const char *dmi_product_name, *dmi_sys_vendor;
@@ -4936,6 +4936,7 @@ static const struct hc_driver xhci_hc_driver = {
void xhci_init_driver(struct hc_driver *drv, int (*setup_fn)(struct usb_hcd *))
{
+ BUG_ON(!setup_fn);
*drv = xhci_hc_driver;
drv->reset = setup_fn;
}
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 0d9b2cf..902f55b 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1886,7 +1886,4 @@ struct xhci_input_control_ctx
*xhci_get_input_control_ctx(struct xhci_hcd *xhci,
struct xhci_slot_ctx *xhci_get_slot_ctx(struct xhci_hcd *xhci, struct
xhci_container_ctx *ctx);
struct xhci_ep_ctx *xhci_get_ep_ctx(struct xhci_hcd *xhci, struct
xhci_container_ctx *ctx, unsigned int ep_index);
-/* xHCI quirks */
-bool xhci_compliance_mode_recovery_timer_quirk_check(void);
-
#endif /* __LINUX_XHCI_HCD_H */
--
2.0.0.526.g5318336
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] Allow xHCI drivers to be built as separate modules
It was suggested in the review of the Tegra xHCI driver [1] that we allow xHCI drivers to be built as individual modules (like EHCI) instead of building them all into the single xhci-hcd module as they are today. Patches 1-3 prepare for making the xHCI PCI and platform drivers able to be built as individual modules and patch 4 actually creates the 3 separate modules (core, platform, PCI). Based on 3.16-rc4. [1] http://patchwork.ozlabs.org/patch/361265/ Andrew Bresticker (4): xhci: Introduce xhci_init_driver() xhci: Check for XHCI_COMP_MODE_QUIRK when disabling D3cold xhci: Export symbols used by host-controller drivers xhci: Allow xHCI drivers to be built as separate modules drivers/usb/host/Kconfig | 5 +++ drivers/usb/host/Makefile| 10 ++--- drivers/usb/host/xhci-dbg.c | 1 + drivers/usb/host/xhci-pci.c | 80 +++- drivers/usb/host/xhci-plat.c | 69 +-- drivers/usb/host/xhci.c | 96 +--- drivers/usb/host/xhci.h | 23 +-- 7 files changed, 111 insertions(+), 173 deletions(-) -- 2.0.0.526.g5318336 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] staging: rtl8188eu: Remove WEXT_PRIV private ioctl handlers
On Thu, Jul 10, 2014 at 06:24:21AM +0530, navin patidar wrote: > On Thu, Jul 10, 2014 at 12:34 AM, Greg KH wrote: > > On Tue, Jul 01, 2014 at 10:35:09PM +0530, navin patidar wrote: > >> Remove WEXT_PRIV (non-standard) ioctl handlers. > >> > >> Signed-off-by: navin patidar > >> --- > >> drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 6335 > >> +++- > >> 1 file changed, 744 insertions(+), 5591 deletions(-) > > > > This patch fails to apply :( > > > > Can you refresh it, and resend this series? > > Please apply following patches. > > [PATCH v2 1/3] staging: rtl8188eu: re-use mac_pton() helper > [PATCH v2 2/3] staging: rtl8188eu: substitute custom hex2bin() > [PATCH v2 3/3] staging: rtl8188eu: re-use hex_to_bin() instead of custom code > > Then try again to apply my patches. I don't have those, sorry, my patch queue for staging patches are now empty as of everything sent up to yesterday. Please resend what you want me to apply, in the order in which you want me to apply it. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: scsi-mq V2
> -Original Message- > From: Jens Axboe [mailto:ax...@kernel.dk] > Sent: Wednesday, 09 July, 2014 2:38 PM > To: dgilb...@interlog.com; Christoph Hellwig; James Bottomley; Bart Van > Assche; Elliott, Robert (Server Storage); linux-s...@vger.kernel.org; linux- > ker...@vger.kernel.org > Subject: Re: scsi-mq V2 > > On 2014-07-09 18:39, Douglas Gilbert wrote: > > On 14-07-08 10:48 AM, Christoph Hellwig wrote: > >> On Wed, Jun 25, 2014 at 06:51:47PM +0200, Christoph Hellwig wrote: > >>> Changes from V1: > >>> - rebased on top of the core-for-3.17 branch, most notable the > >>> scsi logging changes > >>> - fixed handling of cmd_list to prevent crashes for some heavy > >>> workloads > >>> - fixed incorrect handling of !target->can_queue > >>> - avoid scheduling a workqueue on I/O completions when no queues > >>> are congested > >>> > >>> In addition to the patches in this thread there also is a git > >>> available at: > >>> > >>> git://git.infradead.org/users/hch/scsi.git scsi-mq.2 > >> > >> > >> I've pushed out a new scsi-mq.3 branch, which has been rebased on the > >> latest core-for-3.17 tree + the "RFC: clean up command setup" series > >> from June 29th. Robert Elliot found a problem with not fully zeroed > >> out UNMAP CDBs, which is fixed by the saner discard handling in that > >> series. > >> > >> There is a new patch to factor the code from the above series for > >> blk-mq use, which I've attached below. Besides that the only changes > >> are minor merge fixups in the main blk-mq usage patch. > > > > Be warned: both Rob Elliott and I can easily break > > the scsi-mq.3 branch. It seems as though a regression > > has slipped in. I notice that Christoph has added a > > new branch called "scsi-mq.3-no-rebase". > > Rob/Doug, those issues look very much like problems in the aio code. Can > either/both of you try with: > > f8567a3845ac05bb28f3c1b478ef752762bd39ef > edfbbf388f293d70bf4b7c0bc38774d05e6f711a > > reverted (in that order) and see if that changes anything. > > > -- > Jens Axboe scsi-mq.3-no-rebase, which has all the scsi updates from scsi-mq.3 but is based on 3.16.0-rc2 rather than 3.16.0-rc4, works fine: * ^C exits fio cleanly with scsi_debug devices * ^C exits fio cleanly with mpt3sas devices * fio hits 1M IOPS with 16 hpsa devices * fio hits 700K IOPS with 6 mpt3sas devices * 38 device test to mpt3sas, hpsa, and scsi_debug devices runs OK With: * scsi-mq-3, which is based on 3.16.0-rc4 * [PATCH] x86-64: fix vDSO build from https://lkml.org/lkml/2014/7/3/738 * those two aio patches reverted the problem still occurs - fio results in low or 0 IOPS, with perf top reporting unusual amounts of time spent in do_io_submit and io_submit. perf top: 14.38% [kernel] [k] do_io_submit 13.71% libaio.so.1.0.1 [.] io_submit 13.32% [kernel] [k] system_call 11.60% [kernel] [k] system_call_after_swapgs 8.88% [kernel] [k] lookup_ioctx 8.78% [kernel] [k] copy_user_generic_string 7.78% [kernel] [k] io_submit_one 5.97% [kernel] [k] blk_flush_plug_list 2.73% fio [.] fio_libaio_commit 2.70% [kernel] [k] sysret_check 2.68% [kernel] [k] blk_finish_plug 1.98% [kernel] [k] blk_start_plug 1.17% [kernel] [k] SyS_io_submit 1.17% [kernel] [k] __get_user_4 0.99% fio [.] io_submit@plt 0.85% [kernel] [k] _copy_from_user 0.79% [kernel] [k] system_call_fastpath Repeating some of last night's investigation details for the lists: ftrace of one of the CPUs for all functions shows these are repeatedly being called: <...>-34508 [004] 6360.790714: io_submit_one <-do_io_submit <...>-34508 [004] 6360.790714: blk_finish_plug <-do_io_submit <...>-34508 [004] 6360.790714: blk_flush_plug_list <-blk_finish_plug <...>-34508 [004] 6360.790714: SyS_io_submit <-system_call_fastpath <...>-34508 [004] 6360.790715: do_io_submit <-SyS_io_submit <...>-34508 [004] 6360.790715: lookup_ioctx <-do_io_submit <...>-34508 [004] 6360.790715: blk_start_plug <-do_io_submit <...>-34508 [004] 6360.790715: io_submit_one <-do_io_submit <...>-34508 [004] 6360.790715: blk_finish_plug <-do_io_submit <...>-34508 [004] 6360.790715: blk_flush_plug_list <-blk_finish_plug <...>-34508 [004] 6360.790715: SyS_io_submit <-system_call_fastpath <...>-34508 [004] 6360.790715: do_io_submit <-SyS_io_submit <...>-34508 [004] 6360.790715: lookup_ioctx <-do_io_submit <...>-34508 [004] 6360.790716: blk_start_plug <-do_io_submit <...>-34508 [004] 6360.790716: io_submit_one <-do_io_submit <...>-34508 [004]
Re: [PATCH] x86: Configure NX support earlier in setup_arch
On 7/8/2014 5:38 PM, H. Peter Anvin wrote: > On 07/08/2014 03:34 PM, Stuart Hayes wrote: >> >> I haven't received any responses... is there a problem with the patch? Also >> CCing a couple people. >> > > I was on vacation last week and am still catching up. > > It would also help if you describe the real-world scenario that made you > trip over this. > > -hpa > Well... I got this issue because a co-worker tripped over it. He had NX disabled in BIOS for some reason, and found that linux wouldn't boot--it hung right after grub2. I guess it took a while to figure out that it was the fact that NX was disabled that caused linux not to come up--and that could happen to other people. I don't know of any real-world scenarios in which someone would actually prefer to run a recent linux kernel with NX disabled, though. It looks like some of the other boot paths into the kernel automatically clear the XD_DISABLE bit in the MISC_ENABLE MSR in the CPU (in verify_cpu), but that doesn't happen when grub2 jumps to startup_64 in arch/x86/boot/compressed/head_64.S. I guess instead of this patch, I could try to make a patch that turns NX back on (somewhere in startup_64), but since the kernel already supports NX being disabled, so I thought maybe just fixing that would be better. I didn't like seeing the kernel just die without giving any indication of what the problem is. Stuart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] staging: rtl8188eu: Remove WEXT_PRIV private ioctl handlers
On Thu, Jul 10, 2014 at 12:34 AM, Greg KH wrote: > On Tue, Jul 01, 2014 at 10:35:09PM +0530, navin patidar wrote: >> Remove WEXT_PRIV (non-standard) ioctl handlers. >> >> Signed-off-by: navin patidar >> --- >> drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 6335 >> +++- >> 1 file changed, 744 insertions(+), 5591 deletions(-) > > This patch fails to apply :( > > Can you refresh it, and resend this series? Please apply following patches. [PATCH v2 1/3] staging: rtl8188eu: re-use mac_pton() helper [PATCH v2 2/3] staging: rtl8188eu: substitute custom hex2bin() [PATCH v2 3/3] staging: rtl8188eu: re-use hex_to_bin() instead of custom code Then try again to apply my patches. regards, navin patidar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mm: shm: hang in shmem_fallocate
On Wed, 9 Jul 2014, Hugh Dickins wrote:
> On Wed, 9 Jul 2014, Johannes Weiner wrote:
> > On Thu, Jun 26, 2014 at 10:36:20PM -0700, Hugh Dickins wrote:
> > > Hannes, a question for you please, I just could not make up my mind.
> > > In mm/truncate.c truncate_inode_pages_range(), what should be done
> > > with a failed clear_exceptional_entry() in the case of hole-punch?
> > > Is that case currently depending on the rescan loop (that I'm about
> > > to revert) to remove a new page, so I would need to add a retry for
> > > that rather like the shmem_free_swap() one? Or is it irrelevant,
> > > and can stay unchanged as below? I've veered back and forth,
> > > thinking first one and then the other.
> >
> > I realize you have given up on changing truncate.c in the meantime,
> > but I'm still asking myself about the swap retry case: why retry for
> > swap-to-page changes, yet not for page-to-page changes?
> >
> > In case faults are disabled through i_size, concurrent swapin could
> > still turn swap entries into pages, so I can see the need to retry.
> > There is no equivalent for shadow entries, though, and they can only
> > be turned through page faults, so no retry necessary in that case.
> >
> > However, you explicitely mentioned the hole-punch case above: if that
> > can't guarantee the hole will be reliably cleared under concurrent
> > faults, I'm not sure why it would put in more effort to free it of
> > swap (or shadow) entries than to free it of pages.
> >
> > What am I missing?
>
> In dropping the pincer effect, I am conceding that data written (via
> mmap) racily into the hole, behind the punching cursor, between the
> starting and the ending of the punch operation, may be allowed to
> remain. It will not often happen (given the two loops), but it might.
>
> But I insist that all data in the hole at the starting of the punch
> operation must be removed by the ending of the punch operation (though
> of course, given the paragraph above, identical data might be written
> in its place concurrently, via mmap, if the application chooses).
>
> I think you probably agree with both of those propositions.
>
> As the punching cursor moves along the radix_tree, it gathers page
> pointers and swap entries (the emply slots are already skipped at
> the level below; and tmpfs takes care that there is no instant in
> switching between page and swap when the slot appears empty).
>
> Dealing with the page pointers is easy: a reference is already held,
> then shmem_undo_range takes the page lock which prevents swizzling
> to swap, then truncates that page out of the tree.
>
> But dealing with swap entries is slippery: there is no reference
> held, and no lock to prevent swizzling to page (outside of the
> tree_lock taken in shmem_free_swap).
>
> So, as I see it, the page lock ensures that any pages present at
> the starting of the punch operation will be removed, without any
> need to go back and retry. But a swap entry present at the starting
> of the punch operation might be swizzled back to page (and, if we
> imagine massive preemption, even back to swap again, and to page
> again, etc) at the wrong moment: so for swap we do need to retry.
>
> (What I said there is not quite correct: that swap would actually
> have to be a locked page at the time when the first loop meets it.)
>
> Does that make sense?
Allow me to disagree with myself: no, I now think you were right
to press me on this, and we need also the patch below. Do you
agree, or do you see something more is needed?
Note to onlookers: this would have no bearing on the shmem_fallocate
hang which Sasha reported seeing on -next yesterday (in another thread),
but is nonetheless a correction to the patch we have there - I think.
Hugh
--- 3.16-rc3-mm1/mm/shmem.c 2014-07-02 15:32:22.220311543 -0700
+++ linux/mm/shmem.c2014-07-09 17:38:49.972818635 -0700
@@ -516,6 +516,11 @@ static void shmem_undo_range(struct inod
if (page->mapping == mapping) {
VM_BUG_ON_PAGE(PageWriteback(page),
page);
truncate_inode_page(mapping, page);
+ } else {
+ /* Page was replaced by swap: retry */
+ unlock_page(page);
+ index--;
+ break;
}
}
unlock_page(page);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH char-misc-next v2 3/8] dma: MIC X100 DMA Driver
On Thu, May 29, 2014 at 02:24:00PM -0700, Sudeep Dutt wrote: > From: Siva Yerramreddy > > This patch implements DMA Engine API for DMA controller on MIC X100 > Coprocessors. DMA h/w is shared between host and card s/w. > Channels 0 to 3 are used by host and 4 to 7 are used by card. > Since the DMA device doesn't show up as PCIe device, a virtual bus called mic > bus is created and virtual devices are added on that bus to follow device > model. > Allowed dma transfer directions are host to card, card to host and card to > card. > > Reviewed-by: Ashutosh Dixit > Reviewed-by: Nikhil Rao > Reviewed-by: Sudeep Dutt > Signed-off-by: Siva Yerramreddy > --- > drivers/dma/Kconfig| 19 ++ > drivers/dma/Makefile | 1 + > drivers/dma/mic_x100_dma.c | 774 > + > drivers/dma/mic_x100_dma.h | 286 + > 4 files changed, 1080 insertions(+) > create mode 100644 drivers/dma/mic_x100_dma.c > create mode 100644 drivers/dma/mic_x100_dma.h I need some drivers/dma/ maintainers to review this one please... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH char-misc-next v2 2/8] misc: mic: add a bus driver for virtual MIC devices
On Thu, May 29, 2014 at 02:23:59PM -0700, Sudeep Dutt wrote:
> +/**
> + * mbus_device - representation of a device using mbus
> + * @priv: private pointer for the driver's use.
> + * @mmio_va: virtual address of mmio space
> + * @hw_ops: the hardware ops supported by this device.
> + * @id: the device type identification (used to match it with a driver).
> + * @dev: underlying device.
> + * be used to communicate with.
> + * @index: unique position on the mbus bus
> + */
> +struct mbus_device {
> + void *priv;
What's wrong with the built-in "private" pointer that struct device has?
That is why it is there...
> + void __iomem *mmio_va;
> + struct mbus_hw_ops *hw_ops;
> + struct mbus_device_id id;
> + struct device dev;
> + int index;
> +};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 REBASED 00/10] Generic earlyconsole for ARC UART Driver
On Fri, Jul 04, 2014 at 12:35:57PM +0530, Vineet Gupta wrote: > Hi Greg, > > On Wednesday 25 June 2014 02:35 AM, Rob Herring wrote: > > On Tue, Jun 24, 2014 at 3:25 AM, Vineet Gupta > > wrote: > >> Hi, > >> > >> This is slightly modified repost of series posted last week > >> http://www.spinics.net/lists/linux-serial/msg12884.html > >> > >> This series switches ARC UART from custom earlyprintk support to generic > >> earlycon (many thanks to Rob for doing that). And also build on Grant's > >> recent > >> work for using DT stdout-path as default console. > >> > >> The motivation is to get rid of the early platform code, which in turn > >> would help consolidate the init code across several ARC platforms. > >> > >> First 3 patches are general cleanup/refactoring, not necesarily related to > >> earlycon. > > > > Other than my comment on patch 6: > > > > Reviewed-by: Rob Herring > > Is something else needed for this to me merged in tty-next for 3.17. > I've had only 1 minor comment from Rob, and my reply to him never reached > completion. I'll look at these in a few days... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] drivers/base/dma-buf.c: replace dma_buf_uninit_debugfs by debugfs_remove_recursive
On Fri, Jun 27, 2014 at 10:32:10PM +0200, Fabian Frederick wrote:
> null test before debugfs_remove_recursive is not needed so one line function
> dma_buf_uninit_debugfs can be removed.
>
> This patch calls debugfs_remove_recursive under CONFIG_DEBUG_FS
>
> Cc: Sumit Semwal
> Cc: Greg Kroah-Hartman
> Cc: linux-me...@vger.kernel.org
> Signed-off-by: Fabian Frederick
> ---
>
> This is untested.
>
> drivers/base/dma-buf.c | 13 +++--
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> index 840c7fa..184c0cb 100644
> --- a/drivers/base/dma-buf.c
> +++ b/drivers/base/dma-buf.c
> @@ -701,12 +701,6 @@ static int dma_buf_init_debugfs(void)
> return err;
> }
>
> -static void dma_buf_uninit_debugfs(void)
> -{
> - if (dma_buf_debugfs_dir)
> - debugfs_remove_recursive(dma_buf_debugfs_dir);
> -}
> -
> int dma_buf_debugfs_create_file(const char *name,
> int (*write)(struct seq_file *))
> {
> @@ -722,9 +716,6 @@ static inline int dma_buf_init_debugfs(void)
> {
> return 0;
> }
> -static inline void dma_buf_uninit_debugfs(void)
> -{
> -}
> #endif
>
> static int __init dma_buf_init(void)
> @@ -738,6 +729,8 @@ subsys_initcall(dma_buf_init);
>
> static void __exit dma_buf_deinit(void)
> {
> - dma_buf_uninit_debugfs();
> +#ifdef CONFIG_DEBUG_FS
> + debugfs_remove_recursive(dma_buf_debugfs_dir);
> +#endif
That ifdef should not be needed at all, right? No ifdefs should be
needed for debugfs code, if it is written correctly :)
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the staging tree
Hi Greg,
On Fri, 20 Jun 2014 09:53:53 -0700 Greg KH wrote:
>
> On Fri, Jun 20, 2014 at 02:18:07PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > After merging the staging tree, today's linux-next build (powerpc
> > allyesconfig) failed like this:
> >
> > drivers/staging/board/board.c: In function 'find_by_address':
> > drivers/staging/board/board.c:14:3: error: implicit declaration of function
> > 'of_can_translate_address' [-Werror=implicit-function-declaration]
> >if (of_can_translate_address(dn)
> >^
> >
> > Caused by commit 382063d91e15 ("staging: board: Initial board staging
> > support").
> >
> > I have disabled that driver for today.
> >
> > From: Stephen Rothwell
> > Date: Fri, 20 Jun 2014 14:14:17 +1000
> > Subject: [PATCH] staging: board: disable
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > drivers/staging/board/Kconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/staging/board/Kconfig b/drivers/staging/board/Kconfig
> > index 09d94b48c9c9..7eda0b8b7aab 100644
> > --- a/drivers/staging/board/Kconfig
> > +++ b/drivers/staging/board/Kconfig
> > @@ -1,6 +1,7 @@
> > config STAGING_BOARD
> > boolean "Staging Board Support"
> > depends on OF_ADDRESS
> > + depends on BROKEN
> > help
> > Select to enable per-board staging support code.
> >
>
> Magnus, can you send me a proper patch for this to get the code back to
> building condition?
Ping?
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCH V8 2/2] serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers
On Fri, May 30, 2014 at 03:16:22PM +0900, Yoshihiro YUNOMAE wrote: > Add tunable RX interrupt trigger I/F of FIFO buffers. > > Serial devices are used as not only message communication devices but control > or sending communication devices. For the latter uses, normally small data > will be exchanged, so user applications want to receive data unit as soon as > possible for real-time tendency. If we have a sensor which sends a 1 byte data > each time and must control a device based on the sensor feedback, the RX > interrupt should be triggered for each data. > > According to HW specification of serial UART devices, RX interrupt trigger > can be changed, but the trigger is hard-coded. For example, RX interrupt > trigger > in 16550A can be set to 1, 4, 8, or 14 bytes for HW, but current driver sets > the trigger to only 8bytes. > > This patch makes some devices change RX interrupt trigger from userland. > > > - Read current setting > # cat /sys/class/tty/ttyS0/rx_trig_bytes > 8 > > - Write user setting > # echo 1 > /sys/class/tty/ttyS0/rx_trig_bytes > # cat /sys/class/tty/ttyS0/rx_trig_bytes > 1 > > > - 16550A and Tegra (1, 4, 8, or 14 bytes) > - 16650V2 (8, 16, 24, or 28 bytes) > - 16654 (8, 16, 56, or 60 bytes) > - 16750 (1, 16, 32, or 56 bytes) > > Changed in V2: > - Use _IOW for TIOCSFIFORTRIG definition > - Pass the interrupt trigger value itself > > Changes in V3: > - Change I/F from ioctl(2) to sysfs(rx_int_trig) > > Changes in V4: > - Introduce fifo_bug flag in uart_8250_port structure >This is enabled only when parity is enabled and UART_BUG_PARITY is enabled >for up->bugs. If this flag is enabled, user cannot set RX trigger. > - Return -EOPNOTSUPP when it does not support device at convert_fcr2val() and >at convert_val2rxtrig() > - Set the nearest lower RX trigger when users input a meaningless value at >convert_val2rxtrig() > - Check whether p->fcr is existing at serial8250_clear_and_reinit_fifos() > - Set fcr = up->fcr in the begging of serial8250_do_set_termios() > > Changes in V5: > - Support Tegra, 16650V2, 16654, and 16750 > - Store default FCR value to up->fcr when the port is first created > - Add rx_trig_byte[] in uart_config[] for each device and use rx_trig_byte[] >in convert_fcr2val() and convert_val2rxtrig() > > Changes in V5.1: > - Fix FCR_RX_TRIG_MAX_STATE definition > > Changes in V6: > - Move FCR_RX_TRIG_* definition in 8250.h to include/uapi/linux/serial_reg.h, >rename those to UART_FCR_R_TRIG_*, and use UART_FCR_TRIGGER_MASK to >UART_FCR_R_TRIG_BITS() > - Change following function names: > convert_fcr2val() => fcr_get_rxtrig_bytes() > convert_val2rxtrig() => bytes_to_fcr_rxtrig() > - Fix typo in serial8250_do_set_termios() > - Delete the verbose error message pr_info() in bytes_to_fcr_rxtrig() > - Rename *rx_int_trig/rx_trig* to *rxtrig* for several functions or variables >(but UI remains rx_int_trig) > - Change the meaningless variable name 'val' to 'bytes' following functions: > fcr_get_rxtrig_bytes(), bytes_to_fcr_rxtrig(), do_set_rxtrig(), > do_serial8250_set_rxtrig(), and serial8250_set_attr_rxtrig() > - Use up->fcr in order to get rxtrig_bytes instead of rx_trig_raw in >fcr_get_rxtrig_bytes() > - Use conf_type->rxtrig_bytes[0] instead of switch statement for support > check >in register_dev_spec_attr_grp() > - Delete the checking whether a user changed FCR or not when minimum buffer >is needed in serial8250_do_set_termios() > > Changes in V7: > - Add Documentation > - Change I/F name from rx_int_trig to rx_trig_bytes because the name >rx_int_trig is hard to understand how users specify the value > > Changes in V8: > - Divide this patch from V7's patch based on Greg's comment > > Signed-off-by: Yoshihiro YUNOMAE > --- > Documentation/ABI/testing/sysfs-tty | 16 +++ > drivers/tty/serial/8250/8250.h |2 > drivers/tty/serial/8250/8250_core.c | 173 > --- > include/linux/serial_8250.h |2 > include/uapi/linux/serial_reg.h |5 + > 5 files changed, 183 insertions(+), 15 deletions(-) > > diff --git a/Documentation/ABI/testing/sysfs-tty > b/Documentation/ABI/testing/sysfs-tty > index ad22fb0..9eb3c2b 100644 > --- a/Documentation/ABI/testing/sysfs-tty > +++ b/Documentation/ABI/testing/sysfs-tty > @@ -138,3 +138,19 @@ Description: > >These sysfs values expose the TIOCGSERIAL interface via >sysfs rather than via ioctls. > + > +What:/sys/class/tty/ttyS0/rx_trig_bytes > +Date:May 2014 > +Contact: Yoshihiro YUNOMAE > +Description: > + Shows current RX interrupt trigger bytes or sets the > + user specified value to change it for the FIFO buffer. > + Users can show or set this value regardless of opening the > + serial device file or not. > + > + The RX trigger can be set one
Re: [PATCH v6] pinctrl: to avoid duplicated calling enable_pinmux_setting for a pin
On Sun, Jun 8, 2014 at 6:37 PM, wrote:
> From: Fan Wu
[...]
> diff --git a/drivers/pinctrl/pinctrl-msm.c b/drivers/pinctrl/pinctrl-msm.c
> index df6dda4c..bdfaba4 100644
> --- a/drivers/pinctrl/pinctrl-msm.c
> +++ b/drivers/pinctrl/pinctrl-msm.c
> @@ -165,36 +165,11 @@ static int msm_pinmux_enable(struct pinctrl_dev
> *pctldev,
> return 0;
> }
>
> -static void msm_pinmux_disable(struct pinctrl_dev *pctldev,
> - unsigned function,
> - unsigned group)
> -{
> - struct msm_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
> - const struct msm_pingroup *g;
> - unsigned long flags;
> - u32 val;
> -
> - g = >soc->groups[group];
> -
> - if (WARN_ON(g->mux_bit < 0))
> - return;
> -
> - spin_lock_irqsave(>lock, flags);
> -
> - /* Clear the mux bits to select gpio mode */
> - val = readl(pctrl->regs + g->ctl_reg);
> - val &= ~(0x7 << g->mux_bit);
> - writel(val, pctrl->regs + g->ctl_reg);
> -
> - spin_unlock_irqrestore(>lock, flags);
> -}
> -
> static const struct pinmux_ops msm_pinmux_ops = {
> .get_functions_count= msm_get_functions_count,
> .get_function_name = msm_get_function_name,
> .get_function_groups= msm_get_function_groups,
> .enable = msm_pinmux_enable,
> - .disable= msm_pinmux_disable,
> };
>
Sorry for being so late to the game. Totally missed when this until Linus today
told me that 'disable' is gone.
Given the following dt snippet:
active: active {
foo {
pins = "pin1";
function = "function";
};
};
sleep: sleep {
foo {
pins = "pin1";
};
};
Calling:
pinctrl_select_state();
pinctrl_select_state();
If I understand the code correctly after your change there will be no pinmux
operations performed during this transition. As you can see from the comment
above the Qualcomm driver relies on this fact to disable muxing; i.e. select
gpio function.
So most likely I have misunderstood what the disable function was supposed to
do, and we would need to add an explicit "gpio" function to all pingroups as
well as explicitly specifying that for every gpio-configured pin in the device
tree.
I.e. the lack of the string 'function = "gpio"' in below example makes the
state incomplete:
foo {
bar {
pins = "pin1";
bias-pull-up;
};
};
Is this assumption correct?
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] ARM: SPEAr1310 PCIe updates
On 9 July 2014 23:39, Olof Johansson wrote: > * Why are you sending a pull request for a repo that is not yours? Because Mohit/Pratyush were facing some issues in pushing patches to the SPEAr public git repo. And so I tried to help them out publicly and nobody objected then: https://lkml.org/lkml/2014/7/8/10 > * Why is Viresh the git committer but hasn't signed off on the patches? I didn't sign-off because I haven't even looked closed at many of the patches around PCI and Acked whatever I could understand. But yeah, this committer thing is what I missed. Because of that I might be required to signoff it. > Are you sharing accounts on kernel.org? (Adding kernel.org admin on cc > just in case). Obviously not. I am alone the user of this account. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Btrfs: use BUG_ON
Hi Himangi,
(2014/07/09 7:21), Himangi Saraogi wrote:
Use BUG_ON(x) rather than if(x) BUG();
The semantic patch that fixes this problem is as follows:
//
@@ identifier x; @@
-if (x) BUG();
+BUG_ON(x);
//
Strictly speaking, BUG_ON() is "if (unlikely(x)) BUG".
Anyway, I consider that put this condition in unlikely()
in this case is good.
BTW, there are many "if BUG()" case under fs/btrfs.
How about fix all of them?
===
$ grep -rnH -B 1 "BUG()" fs/btrfs | grep -A 1 'if.*('
fs/btrfs/inode.c-6318- } else if (create && PageUptodate(page)) {
fs/btrfs/inode.c:6319: BUG();
--
fs/btrfs/volumes.c-2626-else if (ret)
fs/btrfs/volumes.c:2627:BUG(); # <- your patch
fixes it.
--
fs/btrfs/volumes.c-3092-if (ret == 0)
fs/btrfs/volumes.c:3093:BUG(); /* FIXME break ? */
--
fs/btrfs/raid56.c-2048- if (rbio->faila == -1) {
fs/btrfs/raid56.c:2049: BUG();
===
Thanks,
Satoru
Signed-off-by: Himangi Saraogi
Acked-by: Julia Lawall
---
fs/btrfs/volumes.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 6104676..63e746e 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -2623,8 +2623,8 @@ again:
found_key.offset);
if (ret == -ENOSPC)
failed++;
- else if (ret)
- BUG();
+ else
+ BUG_ON(ret);
}
if (found_key.offset == 0)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
mmotm 2014-07-09-17-08 uploaded
The mm-of-the-moment snapshot 2014-07-09-17-08 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (3.x or 3.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A git tree which contains the memory management portion of this tree is maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git by Michal Hocko. It contains the patches which are between the "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series file, http://www.ozlabs.org/~akpm/mmotm/series. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. http://git.cmpxchg.org/?p=linux-mmotm.git;a=summary To develop on top of mmotm git: $ git remote add mmotm git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git $ git remote update mmotm $ git checkout -b topic mmotm/master $ git send-email mmotm/master.. [...] To rebase a branch with older patches to a new mmotm release: $ git remote update mmotm $ git rebase --onto mmotm/master topic The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is available at http://git.cmpxchg.org/?p=linux-mmots.git;a=summary and use of this tree is similar to http://git.cmpxchg.org/?p=linux-mmotm.git, described above. This mmotm tree contains the following patches against 3.16-rc4: (patches marked "*" will be included in linux-next) origin.patch i-need-old-gcc.patch arch-alpha-kernel-systblss-remove-debug-check.patch maintainers-akpm-maintenance.patch * revert-shmem-fix-faulting-into-a-hole-while-its-punched.patch * shmem-fix-faulting-into-a-hole-while-its-punched-take-2.patch * mm-fs-fix-pessimization-in-hole-punching-pagecache.patch * rmap-fix-pgoff-calculation-to-handle-hugepage-correctly.patch * zram-avoid-lockdep-splat-by-revalidate_disk.patch * sh-also-try-passing-m4-nofpu-for-sh2a-builds.patch * revert-fs-seq_file-fallback-to-vmalloc-allocation.patch * x86mem-hotplug-pass-sync_global_pgds-a-correct-argument-in-remove_pagetable.patch * x86mem-hotplug-modify-pgd-entry-when-removing-memory.patch * x86-numa-setup_node_data-drop-dead-code-and-rename-function.patch * x86-numa-setup_node_data-drop-dead-code-and-rename-function-v2.patch * kernel-auditfilterc-replace-countsize-kmalloc-by-kcalloc.patch * fs-cifs-remove-obsolete-__constant.patch * fs-cifs-filec-replace-countsize-kzalloc-by-kcalloc.patch * fs-cifs-smb2filec-replace-countsize-kzalloc-by-kcalloc.patch * input-route-kbd-leds-through-the-generic-leds-layer.patch * input-route-kbd-leds-through-the-generic-leds-layer-fix.patch * kbuild-explain-stack-protector-strong-config-logic.patch * kernfs-kernel-doc-warning-fix.patch * ntfs-kernel-doc-warning-fixes.patch * remove-cpu_subtype_sh7764.patch * arch-sh-mm-asids-debugfsc-use-ptr_err_or_zero.patch * arch-sh-kernel-timec-use-ptr_err_or_zero.patch * fs-squashfs-file_directc-replace-countsize-kmalloc-by-kmalloc_array.patch * fs-squashfs-superc-logging-clean-up.patch * ubifs-kernel-doc-warning-fix.patch * drivers-net-irda-donauboe-convert-to-module_pci_driver.patch * fs-ext4-fsyncc-generic_file_fsync-call-based-on-barrier-flag.patch * ocfs2-correctly-check-the-return-value-of-ocfs2_search_extent_list.patch * ocfs2-remove-convertion-of-total_backoff-in-dlm_join_domain.patch * ocfs2-do-not-write-error-flag-to-user-structure-we-cannot-copy-from-to.patch * ocfs2-free-inode-when-i_count-becomes-zero.patch * ocfs2-free-inode-when-i_count-becomes-zero-checkpatch-fixes.patch * ocfs2-o2net-dont-shutdown-connection-when-idle-timeout.patch * ocfs2-o2net-set-tcp-user-timeout-to-max-value.patch * ocfs2-quorum-add-a-log-for-node-not-fenced.patch * ocfs2-call-ocfs2_journal_access_di-before-ocfs2_journal_dirty-in-ocfs2_write_end_nolock.patch * fs-ocfs2-slot_mapc-replace-countsize-kzalloc-by-kcalloc.patch * ocfs2-dlm-fix-race-between-dispatched_work-and-dlm_lockres_grab_inflight_worker.patch *
Re: [PATCH 5/9] perf, tools: Add perf download to download event files v4
> I guess the other alternative is curl.. could u check for this one as well? I looked at this earlier, but it made a complete mess of the download script to handle both. So right now I stayed with wget only. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/9] perf, tools: Add support for reading JSON event files v3
> what happens if we fail to realloc? Then the field doesn't get added. No problem. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/9] perf, tools: Add support for reading JSON event files v3
On Thu, Jul 10, 2014 at 12:19:58AM +0200, Jiri Olsa wrote: > Im confused, your branch shows v4 in patch Subject, > while this patch has v3... ? Patchkits and patches both have their own numeric version spaces. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/9] drivers: base: support cpu cache information interface to userspace via sysfs
On Wed, Jun 25, 2014 at 06:30:37PM +0100, Sudeep Holla wrote:
> +static const struct device_attribute *cache_optional_attrs[] = {
> + _attr_coherency_line_size,
> + _attr_ways_of_associativity,
> + _attr_number_of_sets,
> + _attr_size,
> + _attr_attributes,
> + _attr_physical_line_partition,
> + NULL
> +};
> +
> +static int device_add_attrs(struct device *dev,
> + const struct device_attribute **dev_attrs)
> +{
> + int i, error = 0;
> + struct device_attribute *dev_attr;
> + char *buf;
> +
> + if (!dev_attrs)
> + return 0;
> +
> + buf = kmalloc(PAGE_SIZE, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + for (i = 0; dev_attrs[i]; i++) {
> + dev_attr = (struct device_attribute *)dev_attrs[i];
> +
> + /* create attributes that provides meaningful value */
> + if (dev_attr->show(dev, dev_attr, buf) < 0)
> + continue;
> +
> + error = device_create_file(dev, dev_attrs[i]);
> + if (error) {
> + while (--i >= 0)
> + device_remove_file(dev, dev_attrs[i]);
> + break;
> + }
> + }
> +
> + kfree(buf);
> + return error;
> +}
Ick, why create your own function for this when the driver core has this
functionality built into it? Look at the is_visible() callback, and how
it is use for an attribute group please.
> +static void device_remove_attrs(struct device *dev,
> + const struct device_attribute **dev_attrs)
> +{
> + int i;
> +
> + if (!dev_attrs)
> + return;
> +
> + for (i = 0; dev_attrs[i]; dev_attrs++, i++)
> + device_remove_file(dev, dev_attrs[i]);
> +}
You should just remove a whole group at once, not individually.
> +
> +const struct device_attribute **
> +__weak cache_get_priv_attr(struct device *cache_idx_dev)
> +{
> + return NULL;
> +}
> +
> +/* Add/Remove cache interface for CPU device */
> +static void cpu_cache_sysfs_exit(unsigned int cpu)
> +{
> + int i;
> + struct device *tmp_dev;
> + const struct device_attribute **ci_priv_attr;
> +
> + if (per_cpu_index_dev(cpu)) {
> + for (i = 0; i < cache_leaves(cpu); i++) {
> + tmp_dev = per_cache_index_dev(cpu, i);
> + if (!tmp_dev)
> + continue;
> + ci_priv_attr = cache_get_priv_attr(tmp_dev);
> + device_remove_attrs(tmp_dev, ci_priv_attr);
> + device_remove_attrs(tmp_dev, cache_optional_attrs);
> + device_unregister(tmp_dev);
> + }
> + kfree(per_cpu_index_dev(cpu));
> + per_cpu_index_dev(cpu) = NULL;
> + }
> + device_unregister(per_cpu_cache_dev(cpu));
> + per_cpu_cache_dev(cpu) = NULL;
> +}
> +
> +static int cpu_cache_sysfs_init(unsigned int cpu)
> +{
> + struct device *dev = get_cpu_device(cpu);
> +
> + if (per_cpu_cacheinfo(cpu) == NULL)
> + return -ENOENT;
> +
> + per_cpu_cache_dev(cpu) = device_create(dev->class, dev, cpu,
> +NULL, "cache");
> + if (IS_ERR_OR_NULL(per_cpu_cache_dev(cpu)))
> + return PTR_ERR(per_cpu_cache_dev(cpu));
> +
> + /* Allocate all required memory */
> + per_cpu_index_dev(cpu) = kzalloc(sizeof(struct device *) *
> + cache_leaves(cpu), GFP_KERNEL);
> + if (unlikely(per_cpu_index_dev(cpu) == NULL))
> + goto err_out;
> +
> + return 0;
> +
> +err_out:
> + cpu_cache_sysfs_exit(cpu);
> + return -ENOMEM;
> +}
> +
> +static int cache_add_dev(unsigned int cpu)
> +{
> + unsigned short i;
> + int rc;
> + struct device *tmp_dev, *parent;
> + struct cacheinfo *this_leaf;
> + const struct device_attribute **ci_priv_attr;
> + struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
> +
> + rc = cpu_cache_sysfs_init(cpu);
> + if (unlikely(rc < 0))
> + return rc;
> +
> + parent = per_cpu_cache_dev(cpu);
> + for (i = 0; i < cache_leaves(cpu); i++) {
> + this_leaf = this_cpu_ci->info_list + i;
> + if (this_leaf->disable_sysfs)
> + continue;
> + tmp_dev = device_create_with_groups(parent->class, parent, i,
> + this_leaf,
> + cache_default_groups,
> + "index%1u", i);
> + if (IS_ERR_OR_NULL(tmp_dev)) {
> + rc = PTR_ERR(tmp_dev);
> + goto err;
> + }
> +
> + rc = device_add_attrs(tmp_dev, cache_optional_attrs);
> + if (unlikely(rc))
> + goto err;
> +
> + ci_priv_attr =
Re: [RFC/PATCH RESEND -next 00/21] Address sanitizer for kernel (kasan) - dynamic memory error detector.
> FWIW, I definitely agree with this -- if KASAN can do everything that > kmemcheck can, it is no doubt the right way forward. Thanks BTW I didn't want to sound like I'm against kmemcheck. It is a very useful tool and was impressive work given the constraints (no help from the compiler) -andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 1/7] hrtimer: Warn if hrtimer_start*() failed to enqueue hrtimer
On Thu, 10 Jul 2014, Frederic Weisbecker wrote: > On Wed, Jul 09, 2014 at 12:25:33PM +0530, Viresh Kumar wrote: > > hrtimer_start*() family never fails to enqueue a hrtimer to a clock-base. > > The > > only special case is when the hrtimer was in past. If it is getting > > enqueued to > > local CPUs's clock-base, we raise a softirq and exit, else we handle that on > > next interrupt on remote CPU. > > > > At several places in kernel we check if hrtimer is enqueued properly with > > hrtimer_active(). This isn't required and can be dropped. > > > > Before fixing that, lets make sure hrtimer is always enqueued properly by > > adding > > > > WARN_ON_ONCE(!hrtimer_active(timer)); > > > > towards the end of __hrtimer_start_range_ns(). > > > > Suggested-by: Frederic Weisbecker > > Signed-off-by: Viresh Kumar > > --- > > kernel/hrtimer.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c > > index 3ab2899..cf40209 100644 > > --- a/kernel/hrtimer.c > > +++ b/kernel/hrtimer.c > > @@ -1037,6 +1037,8 @@ int __hrtimer_start_range_ns(struct hrtimer *timer, > > ktime_t tim, > > > > unlock_hrtimer_base(timer, ); > > > > + /* Make sure timer is enqueued */ > > + WARN_ON_ONCE(!hrtimer_active(timer)); > > Hmm, after reading Thomas reply, I think it's possible that the hrtimer > expires > right after we unlock it and, if we are unlucky enough, before the > hrtimer_active() > check. > > In this case we might hit a false positive. Haha, I didn't even go down to this patch after reading 0/N. I knew right there that it's going to be pointless shite. But now that you point me to it, it's even worse. It's not only pointless shite it's actively wrong and outright stupid for someone who tries to "work" on this code for a couple of month now. Viresh, I'm really tired of this. Stop touching code you do not understand. I warned you more than once and now you really reached the level of complete incompetence. Welcome to my killfile. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] man2: Document constant for only allowing absolute paths
Signed-off-by: Steven Stewart-Gallus --- man2/access.2| 14 +- man2/chmod.2 | 14 +- man2/chown.2 | 14 +- man2/fanotify_mark.2 | 15 ++- man2/futimesat.2 | 14 +- man2/link.2 | 11 ++- man2/mkdir.2 | 14 +- man2/mknod.2 | 14 +- man2/open.2 | 14 +- man2/open_by_handle_at.2 |8 man2/readlink.2 | 14 +- man2/rename.2| 11 ++- man2/stat.2 | 14 +- man2/symlink.2 | 14 +- man2/unlink.2| 14 +- man2/utimensat.2 |8 man3/readdir.3 | 18 ++ 17 files changed, 207 insertions(+), 18 deletions(-) diff --git a/man2/access.2 b/man2/access.2 index cdf2f96..f2a030b 100644 --- a/man2/access.2 +++ b/man2/access.2 @@ -141,6 +141,14 @@ directory of the calling process (like .BR access ()). If +.I dirfd +is the special value +.BR AT_FDABSOLUTE , +then +.I pathname +must be absolute. + +If .I pathname is absolute, then .I dirfd @@ -244,7 +252,11 @@ The following additional errors can occur for .TP .B EBADF .I dirfd -is not a valid file descriptor. +is not a valid file descriptor or +.I dirfd +is AT_FDABSOLUTE and +.I pathname +is relative. .TP .B EINVAL Invalid flag specified in diff --git a/man2/chmod.2 b/man2/chmod.2 index b46c0fa..1cde0f1 100644 --- a/man2/chmod.2 +++ b/man2/chmod.2 @@ -209,6 +209,14 @@ directory of the calling process (like .BR chmod ()). If +.I dirfd +is the special value +.BR AT_FDABSOLUTE , +then +.I pathname +must be absolute. + +If .I pathname is absolute, then .I dirfd @@ -306,7 +314,11 @@ The following additional errors can occur for .TP .B EBADF .I dirfd -is not a valid file descriptor. +is not a valid file descriptor or +.I dirfd +is AT_FDABSOLUTE and +.I pathname +is relative. .TP .B EINVAL Invalid flag specified in diff --git a/man2/chown.2 b/man2/chown.2 index 8f6194e..aafadc5 100644 --- a/man2/chown.2 +++ b/man2/chown.2 @@ -172,6 +172,14 @@ directory of the calling process (like .BR chown ()). If +.I dirfd +is the special value +.BR AT_FDABSOLUTE , +then +.I pathname +must be absolute. + +If .I pathname is absolute, then .I dirfd @@ -295,7 +303,11 @@ The following additional errors can occur for .TP .B EBADF .I dirfd -is not a valid file descriptor. +is not a valid file descriptor or +.I dirfd +is AT_FDABSOLUTE and +.I pathname +is relative. .TP .B EINVAL Invalid flag specified in diff --git a/man2/fanotify_mark.2 b/man2/fanotify_mark.2 index d3c7e7d..13bf51d 100644 --- a/man2/fanotify_mark.2 +++ b/man2/fanotify_mark.2 @@ -214,6 +214,14 @@ is absolute, it defines the filesystem object to be marked, and is ignored. .IP * If +.I dirfd +is the special value +.BR AT_FDABSOLUTE , +then +.I pathname +must be absolute. +.IP * +If .I pathname is relative, and .I dirfd @@ -244,7 +252,12 @@ is set to indicate the error. .TP .B EBADF An invalid file descriptor was passed in -.IR fanotify_fd . +.IR fanotify_fd +or +.I dirfd +is AT_FDABSOLUTE and +.I pathname +is relative. .TP .B EINVAL An invalid value was passed in diff --git a/man2/futimesat.2 b/man2/futimesat.2 index e6e0174..2b9298d 100644 --- a/man2/futimesat.2 +++ b/man2/futimesat.2 @@ -77,6 +77,14 @@ directory of the calling process (like .BR utimes (2)). If +.I dirfd +is the special value +.BR AT_FDABSOLUTE , +then +.I pathname +must be absolute. + +If .I pathname is absolute, then .I dirfd @@ -98,7 +106,11 @@ The following additional errors can occur for .TP .B EBADF .I dirfd -is not a valid file descriptor. +is not a valid file descriptor or +.I dirfd +is AT_FDABSOLUTE and +.I pathname +is relative. .TP .B ENOTDIR .I pathname diff --git a/man2/link.2 b/man2/link.2 index 0725cd2..d340235 100644 --- a/man2/link.2 +++ b/man2/link.2 @@ -107,6 +107,14 @@ directory of the calling process (like .BR link ()). If +.I olddirfd +is the special value +.BR AT_FDABSOLUTE , +then +.I oldpath +must be absolute. + +If .I oldpath is absolute, then .I olddirfd @@ -278,7 +286,8 @@ The following additional errors can occur for .I olddirfd or .I newdirfd -is not a valid file descriptor. +is not a valid file descriptor or one of them is AT_FDABSOLUTE and the +associated path is relative. .TP .B EINVAL An invalid flag value was specified in diff --git a/man2/mkdir.2 b/man2/mkdir.2 index 71f794f..4c18fcb 100644 --- a/man2/mkdir.2 +++ b/man2/mkdir.2 @@ -103,6 +103,14 @@ directory of the calling process (like .BR mkdir ()). If +.I dirfd +is the special value +.BR AT_FDABSOLUTE , +then +.I pathname +must be absolute. + +If .I pathname is absolute, then .I dirfd @@ -190,7 +198,11 @@ The following additional errors can occur for .TP .B EBADF .I dirfd -is not a valid file descriptor.
Re: [PATCH v2] drivers/base: Fix length checks in create_syslog_header()/dev_vprintk_emit()
On Sun, Jun 08, 2014 at 11:51:43PM +0100, Ben Hutchings wrote: > snprintf() returns the number of bytes that could have been written > (excluding the null), not the actual number of bytes written. Given a > long enough subsystem or device name, these functions will advance > beyond the end of the on-stack buffer in dev_vprintk_exit(), resulting > in an information leak or stack corruption. I don't know whether such > a long name is currently possible. > > In case snprintf() returns a value >= the buffer size, do not add > structured logging information. Also WARN if this happens, so we can > fix the driver or increase the buffer size. > > Signed-off-by: Ben Hutchings > --- > v2: use dev_WARN() not dev_WARN_ON() This patch breaks the build in a huge way: drivers/base/core.c: In function ‘create_syslog_header’: drivers/base/core.c:2049:16: error: expected ‘)’ before numeric constant dev_WARN(dev, 1, "device/subsystem name too long"); ^ is the start of it, it goes on for a page or so after that :( greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] hyperv: Add netpoll support
From: Richard Weinberger Date: Wed, 9 Jul 2014 16:23:59 +0200 > In order to have at least a netconsole to debug kernel issues on > Windows Azure this patch implements netpoll support. > Sending packets is easy, netvsc_start_xmit() does already everything > needed. > > Signed-off-by: Richard Weinberger Applied to net-next, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] net: davinci_mdio: reuse for keystone2 arch
From: Grygorii Strashko Date: Wed, 9 Jul 2014 16:10:50 +0300 > Required properties: > -- compatible : Should be "ti,davinci_mdio" > +- compatible : Should be "ti,davinci_mdio" or "ti,keystone-mdio" Why the inconsistency in naming schemes? I don't see any reason to be different wrt. "_" vs. "-" in the name string. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] include/uapi: Define AT_ABSOLUTE to allow only absolute paths
This way people can use existing functionality (passing an invalid value for dirfd to allow only absolute paths in *at style functions) and be compatible for the future if Linux ever adds in new AT_* flags. Signed-off-by: Steven Stewart-Gallus --- include/uapi/linux/fcntl.h | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h index 074b886..c4c5705 100644 --- a/include/uapi/linux/fcntl.h +++ b/include/uapi/linux/fcntl.h @@ -38,9 +38,16 @@ #define DN_ATTRIB 0x0020 /* File changed attibutes */ #define DN_MULTISHOT 0x8000 /* Don't remove notifier */ +#define AT_FDABSOLUTE -1 /* Special value used to indicate + openat should not use any directory + and only accept absolute values. + Currently, other values work for this + but in the future that might + change. */ #define AT_FDCWD -100/* Special value used to indicate - openat should use the current - working directory. */ + openat should use the current + working directory. */ + #define AT_SYMLINK_NOFOLLOW0x100 /* Do not follow symbolic links. */ #define AT_REMOVEDIR 0x200 /* Remove directory instead of unlinking file. */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next] r8152: support jumbo frame for RTL8153
From: Hayes Wang
Date: Wed, 9 Jul 2014 16:07:02 +0800
> +static int rtl8152_change_mtu(struct net_device *dev, int new_mtu)
> +{
> + struct r8152 *tp = netdev_priv(dev);
> +
> + if (dev->mtu == new_mtu)
> + return 0;
This method will never be invoked if the MTU is actually not changing.
Please remove this test.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [net-next PATCH v2 0/3] Broadcast/Multicast rate limit via Ethtool Coalesce
From: Mugunthan V N Date: Wed, 9 Jul 2014 12:44:07 +0530 > A system/cpu can be loaded by a hacker with flooding of broadcast or > multicast packets, to prevent this some Ethernet controllers like CPSW > provide a mechanism to limit the broadcast/multicast packet rate via > hardware limiters. This patch series enables this feature via > Ethtool Coalesce. This is pretty bogus if you ask me. What is the difference from accepting a high rate of unicast packets? I say it is no different. Therefore, this feature makes no sense to me at all. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] include/uapi: Define AT_FDNODIR constant as future guarantee
Thank you for the criticisms Christopher Hellwig. I will edit the commit message to be better and comments in the code to be clearer. I will also document the constant in the manpages. I think I will call the constant AT_FDABSOLUTE though because I want it to be prepended with FD the same way AT_FDCWD is. Thank you, Steven Stewart-Gallus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] autofs4: factor should_expire() out of autofs4_expire_indirect.
Future patch will potentially call this twice, so make it
separate.
Signed-off-by: NeilBrown
---
fs/autofs4/expire.c | 153 ++-
1 file changed, 79 insertions(+), 74 deletions(-)
diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c
index 7e2f22ce6954..fb0b5003353f 100644
--- a/fs/autofs4/expire.c
+++ b/fs/autofs4/expire.c
@@ -345,6 +345,80 @@ out:
return NULL;
}
+static struct dentry *should_expire(struct dentry *dentry,
+ struct vfsmount *mnt,
+ unsigned long timeout,
+ int how)
+{
+ int do_now = how & AUTOFS_EXP_IMMEDIATE;
+ int exp_leaves = how & AUTOFS_EXP_LEAVES;
+ struct autofs_info *ino = autofs4_dentry_ino(dentry);
+ unsigned int ino_count;
+
+ /* No point expiring a pending mount */
+ if (ino->flags & AUTOFS_INF_PENDING)
+ return NULL;
+
+ /*
+* Case 1: (i) indirect mount or top level pseudo direct mount
+* (autofs-4.1).
+* (ii) indirect mount with offset mount, check the "/"
+* offset (autofs-5.0+).
+*/
+ if (d_mountpoint(dentry)) {
+ DPRINTK("checking mountpoint %p %.*s",
+ dentry, (int)dentry->d_name.len, dentry->d_name.name);
+
+ /* Can we umount this guy */
+ if (autofs4_mount_busy(mnt, dentry))
+ return NULL;
+
+ /* Can we expire this guy */
+ if (autofs4_can_expire(dentry, timeout, do_now))
+ return dentry;
+ return NULL;
+ }
+
+ if (dentry->d_inode && S_ISLNK(dentry->d_inode->i_mode)) {
+ DPRINTK("checking symlink %p %.*s",
+ dentry, (int)dentry->d_name.len, dentry->d_name.name);
+ /*
+* A symlink can't be "busy" in the usual sense so
+* just check last used for expire timeout.
+*/
+ if (autofs4_can_expire(dentry, timeout, do_now))
+ return dentry;
+ return NULL;
+ }
+
+ if (simple_empty(dentry))
+ return NULL;
+
+ /* Case 2: tree mount, expire iff entire tree is not busy */
+ if (!exp_leaves) {
+ /* Path walk currently on this dentry? */
+ ino_count = atomic_read(>count) + 1;
+ if (d_count(dentry) > ino_count)
+ return NULL;
+
+ if (!autofs4_tree_busy(mnt, dentry, timeout, do_now))
+ return dentry;
+ /*
+* Case 3: pseudo direct mount, expire individual leaves
+* (autofs-4.1).
+*/
+ } else {
+ /* Path walk currently on this dentry? */
+ ino_count = atomic_read(>count) + 1;
+ if (d_count(dentry) > ino_count)
+ return NULL;
+
+ dentry = autofs4_check_leaves(mnt, dentry, timeout, do_now);
+ if (dentry)
+ return dentry;
+ }
+ return NULL;
+}
/*
* Find an eligible tree to time-out
* A tree is eligible if :-
@@ -359,11 +433,8 @@ struct dentry *autofs4_expire_indirect(struct super_block
*sb,
unsigned long timeout;
struct dentry *root = sb->s_root;
struct dentry *dentry;
- struct dentry *expired = NULL;
- int do_now = how & AUTOFS_EXP_IMMEDIATE;
- int exp_leaves = how & AUTOFS_EXP_LEAVES;
+ struct dentry *expired;
struct autofs_info *ino;
- unsigned int ino_count;
if (!root)
return NULL;
@@ -374,78 +445,12 @@ struct dentry *autofs4_expire_indirect(struct super_block
*sb,
dentry = NULL;
while ((dentry = get_next_positive_subdir(dentry, root))) {
spin_lock(>fs_lock);
- ino = autofs4_dentry_ino(dentry);
- /* No point expiring a pending mount */
- if (ino->flags & AUTOFS_INF_PENDING)
- goto next;
-
- /*
-* Case 1: (i) indirect mount or top level pseudo direct mount
-* (autofs-4.1).
-* (ii) indirect mount with offset mount, check the "/"
-* offset (autofs-5.0+).
-*/
- if (d_mountpoint(dentry)) {
- DPRINTK("checking mountpoint %p %.*s",
- dentry, (int)dentry->d_name.len,
dentry->d_name.name);
-
- /* Can we umount this guy */
- if (autofs4_mount_busy(mnt, dentry))
- goto next;
-
- /* Can we expire this guy */
- if (autofs4_can_expire(dentry, timeout, do_now)) {
-
Re: [PATCH net v2] r8169: disable L23
From: Francois Romieu Date: Thu, 10 Jul 2014 00:09:54 +0200 > Hayes Wang : >> For RTL8411, RTL8111G, RTL8402, RTL8105, and RTL8106, disable the feature >> of entering the L2/L3 link state of the PCIe. When the nic starts the process >> of entering the L2/L3 link state and the PCI reset occurs before the work >> is finished, the work would be queued and continue after the next the PCI >> reset occurs. This causes the device stays in L2/L3 link state, and the >> system >> couldn't find the device. >> >> Signed-off-by: Hayes Wang > > Acked-by: Francois Romieu > > Thanks, the explanation of the race between software induced PCI reset > and transition to PCIe L2/L3 should be clear enough. PM scared me, yet > it got worse. > > Davem, would you mind to s/rtl_l23_enable/rtl_pcie_state_l2l3_enable/ or > do you want a new patch for it ? Applied with the function name adjusted, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] autofs4: allow RCU-walk to walk through autofs4.
Any attempt to look up a pathname that passes though an
autofs4 mount is currently forced out of RCU-walk into
REF-walk.
This can significantly hurt performance of many-thread work
loads on many-core systems, especially if the automounted
filesystem supports RCU-walk but doesn't get to benefit from
it.
So if autofs4_d_manage is called with rcu_walk set, only
fail with -ECHILD if it is necessary to wait longer than
a spinlock, and avoid even the spinlock in one trivial case.
Signed-off-by: NeilBrown
---
fs/autofs4/autofs_i.h |2 +-
fs/autofs4/dev-ioctl.c |2 +-
fs/autofs4/expire.c|4 +++-
fs/autofs4/root.c | 44 +---
4 files changed, 34 insertions(+), 18 deletions(-)
diff --git a/fs/autofs4/autofs_i.h b/fs/autofs4/autofs_i.h
index 22a280151e45..99dbb05d6148 100644
--- a/fs/autofs4/autofs_i.h
+++ b/fs/autofs4/autofs_i.h
@@ -148,7 +148,7 @@ void autofs4_free_ino(struct autofs_info *);
/* Expiration */
int is_autofs4_dentry(struct dentry *);
-int autofs4_expire_wait(struct dentry *dentry);
+int autofs4_expire_wait(struct dentry *dentry, int rcu_walk);
int autofs4_expire_run(struct super_block *, struct vfsmount *,
struct autofs_sb_info *,
struct autofs_packet_expire __user *);
diff --git a/fs/autofs4/dev-ioctl.c b/fs/autofs4/dev-ioctl.c
index 5b570b6efa28..aaf96cb25452 100644
--- a/fs/autofs4/dev-ioctl.c
+++ b/fs/autofs4/dev-ioctl.c
@@ -450,7 +450,7 @@ static int autofs_dev_ioctl_requester(struct file *fp,
ino = autofs4_dentry_ino(path.dentry);
if (ino) {
err = 0;
- autofs4_expire_wait(path.dentry);
+ autofs4_expire_wait(path.dentry, 0);
spin_lock(>fs_lock);
param->requester.uid = from_kuid_munged(current_user_ns(),
ino->uid);
param->requester.gid = from_kgid_munged(current_user_ns(),
ino->gid);
diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c
index a7be57e39be7..7e2f22ce6954 100644
--- a/fs/autofs4/expire.c
+++ b/fs/autofs4/expire.c
@@ -467,7 +467,7 @@ found:
return expired;
}
-int autofs4_expire_wait(struct dentry *dentry)
+int autofs4_expire_wait(struct dentry *dentry, int rcu_walk)
{
struct autofs_sb_info *sbi = autofs4_sbi(dentry->d_sb);
struct autofs_info *ino = autofs4_dentry_ino(dentry);
@@ -477,6 +477,8 @@ int autofs4_expire_wait(struct dentry *dentry)
spin_lock(>fs_lock);
if (ino->flags & AUTOFS_INF_EXPIRING) {
spin_unlock(>fs_lock);
+ if (rcu_walk)
+ return -ECHILD;
DPRINTK("waiting for expire %p name=%.*s",
dentry, dentry->d_name.len, dentry->d_name.name);
diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
index cc87c1abac97..1ad119407e2f 100644
--- a/fs/autofs4/root.c
+++ b/fs/autofs4/root.c
@@ -208,7 +208,8 @@ next:
return NULL;
}
-static struct dentry *autofs4_lookup_expiring(struct dentry *dentry)
+static struct dentry *autofs4_lookup_expiring(struct dentry *dentry,
+ bool rcu_walk)
{
struct autofs_sb_info *sbi = autofs4_sbi(dentry->d_sb);
struct dentry *parent = dentry->d_parent;
@@ -225,6 +226,11 @@ static struct dentry *autofs4_lookup_expiring(struct
dentry *dentry)
struct dentry *expiring;
struct qstr *qstr;
+ if (rcu_walk) {
+ spin_unlock(>lookup_lock);
+ return ERR_PTR(-ECHILD);
+ }
+
ino = list_entry(p, struct autofs_info, expiring);
expiring = ino->dentry;
@@ -260,13 +266,15 @@ next:
return NULL;
}
-static int autofs4_mount_wait(struct dentry *dentry)
+static int autofs4_mount_wait(struct dentry *dentry, bool rcu_walk)
{
struct autofs_sb_info *sbi = autofs4_sbi(dentry->d_sb);
struct autofs_info *ino = autofs4_dentry_ino(dentry);
int status = 0;
if (ino->flags & AUTOFS_INF_PENDING) {
+ if (rcu_walk)
+ return -ECHILD;
DPRINTK("waiting for mount name=%.*s",
dentry->d_name.len, dentry->d_name.name);
status = autofs4_wait(sbi, dentry, NFY_MOUNT);
@@ -276,20 +284,22 @@ static int autofs4_mount_wait(struct dentry *dentry)
return status;
}
-static int do_expire_wait(struct dentry *dentry)
+static int do_expire_wait(struct dentry *dentry, bool rcu_walk)
{
struct dentry *expiring;
- expiring = autofs4_lookup_expiring(dentry);
+ expiring = autofs4_lookup_expiring(dentry, rcu_walk);
+ if (IS_ERR(expiring))
+ return PTR_ERR(expiring);
if (!expiring)
- return autofs4_expire_wait(dentry);
+ return autofs4_expire_wait(dentry, rcu_walk);
else {
/*
* If we are
[PATCH 5/6] autofs4: avoid taking fs_lock during rcu-walk
->fs_lock protects AUTOFS_INF_EXPIRING. We need to be sure
that once the flag is set, no new references beneath the dentry
are taken. So rcu-walk currently needs to take fs_lock before
checking the flag. This hurts performance.
Change the expiry to a two-stage process.
First set AUTHFS_INF_NO_RCU which forces any path walk into
ref-walk mode, then drop the lock and call synchronize_rcu().
Once that returns we can be sure no rcu-walk is active beneath
the dentry and we can check reference counts again.
Now during an RCU-walk we can test AUTHFS_INF_EXPIRING without
taking the lock as along as we test AUTHFS_INF_NO_RCU too.
If either are set, we must abort the RCU-walk
If neither are set, we know that refcounts will be tested again
after we finish the RCU-walk so we are safe to continue.
Signed-off-by: NeilBrown
---
fs/autofs4/autofs_i.h |4
fs/autofs4/expire.c | 46 ++
2 files changed, 42 insertions(+), 8 deletions(-)
diff --git a/fs/autofs4/autofs_i.h b/fs/autofs4/autofs_i.h
index 99dbb05d6148..469724d7568c 100644
--- a/fs/autofs4/autofs_i.h
+++ b/fs/autofs4/autofs_i.h
@@ -79,6 +79,10 @@ struct autofs_info {
};
#define AUTOFS_INF_EXPIRING(1<<0) /* dentry is in the process of expiring
*/
+#define AUTOFS_INF_NO_RCU (1<<1) /* the dentry is being considered
+ * for expiry, so RCU_walk is
+ * not permitted
+ */
#define AUTOFS_INF_PENDING (1<<2) /* dentry pending mount */
struct autofs_wait_queue {
diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c
index fb0b5003353f..98a6fd4957f8 100644
--- a/fs/autofs4/expire.c
+++ b/fs/autofs4/expire.c
@@ -333,10 +333,19 @@ struct dentry *autofs4_expire_direct(struct super_block
*sb,
if (ino->flags & AUTOFS_INF_PENDING)
goto out;
if (!autofs4_direct_busy(mnt, root, timeout, do_now)) {
- ino->flags |= AUTOFS_INF_EXPIRING;
- init_completion(>expire_complete);
+ ino->flags |= AUTOFS_INF_NO_RCU;
spin_unlock(>fs_lock);
- return root;
+ synchronize_rcu();
+ spin_lock(>fs_lock);
+ if (!autofs4_direct_busy(mnt, root, timeout, do_now)) {
+ ino->flags |= AUTOFS_INF_EXPIRING;
+ smp_mb()
+ ino->flags &= ~AUTOFS_INF_NO_RCU;
+ init_completion(>expire_complete);
+ spin_unlock(>fs_lock);
+ return root;
+ }
+ ino->flags &= ~AUTOFS_INF_NO_RCU;
}
out:
spin_unlock(>fs_lock);
@@ -445,12 +454,29 @@ struct dentry *autofs4_expire_indirect(struct super_block
*sb,
dentry = NULL;
while ((dentry = get_next_positive_subdir(dentry, root))) {
spin_lock(>fs_lock);
- expired = should_expire(dentry, mnt, timeout, how);
- if (expired) {
+ ino = autofs4_dentry_ino(dentry);
+ if (ino->flags & AUTOFS_INF_NO_RCU)
+ expired = NULL;
+ else
+ expired = should_expire(dentry, mnt, timeout, how);
+ if (!expired) {
+ spin_unlock(>fs_lock);
+ continue;
+ }
+ ino = autofs4_dentry_ino(expired);
+ ino->flags |= AUTOFS_INF_NO_RCU;
+ spin_unlock(>fs_lock);
+ synchronize_rcu();
+ spin_lock(>fs_lock);
+ if (should_expire(expired, mnt, timeout, how)) {
if (expired != dentry)
dput(dentry);
goto found;
}
+
+ ino->flags &= ~AUTOFS_INF_NO_RCU;
+ if (expired != dentry)
+ dput(expired);
spin_unlock(>fs_lock);
}
return NULL;
@@ -458,8 +484,9 @@ struct dentry *autofs4_expire_indirect(struct super_block
*sb,
found:
DPRINTK("returning %p %.*s",
expired, (int)expired->d_name.len, expired->d_name.name);
- ino = autofs4_dentry_ino(expired);
ino->flags |= AUTOFS_INF_EXPIRING;
+ smp_mb()
+ ino->flags &= ~AUTOFS_INF_NO_RCU;
init_completion(>expire_complete);
spin_unlock(>fs_lock);
spin_lock(>lookup_lock);
@@ -479,11 +506,14 @@ int autofs4_expire_wait(struct dentry *dentry, int
rcu_walk)
int status;
/* Block on any pending expire */
+ if (!(ino->flags & (AUTOFS_INF_EXPIRING | AUTOFS_INF_NO_RCU)))
+ return 0;
+
+ if (rcu_walk)
+ return -ECHILD;
spin_lock(>fs_lock);
if (ino->flags & AUTOFS_INF_EXPIRING) {
spin_unlock(>fs_lock);
- if (rcu_walk)
- return
[PATCH 2/6] autofs4: remove a redundant assignment
The variable 'ino' already exists and already
has the correct value. The d_fsdata of a dentry
is never changed after the d_fsdata is instantiated,
so this new assignment cannot be necessary.
It was introduced in
commit b5b801779d59165c4ecf1009009109545bd1f642
autofs4: Add d_manage() dentry operation
Signed-off-by: NeilBrown
---
fs/autofs4/expire.c |1 -
1 file changed, 1 deletion(-)
diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c
index 394e90b02c5e..a7be57e39be7 100644
--- a/fs/autofs4/expire.c
+++ b/fs/autofs4/expire.c
@@ -333,7 +333,6 @@ struct dentry *autofs4_expire_direct(struct super_block *sb,
if (ino->flags & AUTOFS_INF_PENDING)
goto out;
if (!autofs4_direct_busy(mnt, root, timeout, do_now)) {
- struct autofs_info *ino = autofs4_dentry_ino(root);
ino->flags |= AUTOFS_INF_EXPIRING;
init_completion(>expire_complete);
spin_unlock(>fs_lock);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] autofs4: don't take spinlock when not needed in autofs4_lookup_expiring
If the expiring_list is empty, we can avoid a costly spinlock
in the rcu-walk path through authfs4_d_manage.
Signed-off-by: NeilBrown
---
fs/autofs4/root.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
index 1ad119407e2f..774c2dab331b 100644
--- a/fs/autofs4/root.c
+++ b/fs/autofs4/root.c
@@ -219,6 +219,8 @@ static struct dentry *autofs4_lookup_expiring(struct dentry
*dentry,
const unsigned char *str = name->name;
struct list_head *p, *head;
+ if (list_empty(>expiring_list))
+ return NULL;
spin_lock(>lookup_lock);
head = >expiring_list;
list_for_each(p, head) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/6] autofs4: support RCU-walk
autofs4 currently doesn't support RCU-walk - it immediately aborts any attempt at RCU-walk to force REF-walk for path name lookup. This can cause a significant performance impact on multi-core systems. I have a client with a test case which spends >80% of its time waiting for spinlocks with a "make -j 40" on a 40 core system. This patchset aims to remove most of these spinlocks. To be fully effective in the particular case it needs a second patch set which makes NFS RCU-walk friendly, but one thing at a time. This has only been lightly tested so far so I'm really after feed-back rather than to have the patch set accepted, though the first two patches are trivial and could be taken immediately. The last two patches are the most interesting so review comments on those are particularly welcome. Thanks, NeilBrown --- NeilBrown (6): autofs4: remove unused autofs4_ispending() autofs4: remove a redundant assignment autofs4: allow RCU-walk to walk through autofs4. autofs4: factor should_expire() out of autofs4_expire_indirect. autofs4: avoid taking fs_lock during rcu-walk autofs4: don't take spinlock when not needed in autofs4_lookup_expiring fs/autofs4/autofs_i.h | 20 + fs/autofs4/dev-ioctl.c |2 - fs/autofs4/expire.c| 192 +--- fs/autofs4/root.c | 46 4 files changed, 151 insertions(+), 109 deletions(-) -- Signature -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
