Attn: Sir/Madam,
Greetings to you. I Got your contact details through a Database. I have an
important business discussion I wish to share with you which I believe will
interest you, because it is in connection with your last name “”, and you are
going to benefit from it. I am a bank officer her
Johannes,
> dxfer_len is an unsigned int and we always assign a value > 0 to it,
> so it doesn't make any sense to check if it is < 0. We can't really
> check dxferp as well as we have both NULL and not NULL cases in the
> possible call paths.
>
> So just return true for SG_DXFER_FROM_DEV transfe
Yadan,
> The hpsa firmware will bypass the cache for any request larger
> than 1MB, so we should cap the request size to avoid any
> performance degradation in kernels later than v4.3
Applied to 4.13/scsi-fixes. Thanks!
--
Martin K. Petersen Oracle Linux Engineering
After updating my tape backup server to 4.12 I found that mtx had issues
controlling the tape library. Good behavior:
[root@backup2 ~]# mtx -f /dev/sg7 next 0
Unloading drive 0 into Storage Element 4...done
Loading media from Storage Element 5 into drive 0...done
Bad behavior:
[root@backup2 ~]#
Arthur Marsh wrote on 14/07/17 04:18:
Alan Stern wrote on 14/07/17 02:30:
All right. In the meantime, changing usb-storage won't hurt.
Arthur, can you test the patch below?
Alan Stern
Index: usb-4.x/drivers/usb/storage/usb.c
===
Dear friend,
I'm sorry but happy to inform you about my success in getting those funds
under the cooperation of a new partner from Vietnam though i tried my best to
involve you in the business but God decided the whole situations. Presently
I'm in Vietnam for investment projects with my own s
dxfer_len is an unsigned int and we always assign a value > 0 to it, so it
doesn't make any sense to check if it is < 0. We can't really check dxferp as
well as we have both NULL and not NULL cases in the possible call paths.
So just return true for SG_DXFER_FROM_DEV transfer in sg_is_valid_dxfer(
On 17/07/17 14:57, Arnd Bergmann wrote:
> On Mon, Jul 17, 2017 at 2:53 PM, Hans Verkuil wrote:
>> On 14/07/17 14:07, Arnd Bergmann wrote:
>>> gcc-7 notices that we copy a fixed length string into another
>>> string of the same size, with additional characters:
>>>
>>> drivers/media/usb/usbvision/u
On Mon, Jul 17, 2017 at 2:53 PM, Hans Verkuil wrote:
> On 14/07/17 14:07, Arnd Bergmann wrote:
>> gcc-7 notices that we copy a fixed length string into another
>> string of the same size, with additional characters:
>>
>> drivers/media/usb/usbvision/usbvision-i2c.c: In function
>> 'usbvision_i2c_
On 14/07/17 14:07, Arnd Bergmann wrote:
> gcc-7 notices that we copy a fixed length string into another
> string of the same size, with additional characters:
>
> drivers/media/usb/usbvision/usbvision-i2c.c: In function
> 'usbvision_i2c_register':
> drivers/media/usb/usbvision/usbvision-i2c.c:190
On Mon, Jul 17, 2017 at 11:17 AM, David Laight wrote:
> From: Arnd Bergmann
>> Sent: 14 July 2017 13:07
>> gcc points out a theorerical string overflow:
>>
>> drivers/message/fusion/mptbase.c: In function 'mpt_detach':
>> drivers/message/fusion/mptbase.c:2103:17: error: '%s' directive writing up
gcc points out a theorerical string overflow:
drivers/message/fusion/mptbase.c: In function 'mpt_detach':
drivers/message/fusion/mptbase.c:2103:17: error: '%s' directive writing up to
31 bytes into a region of size 28 [-Werror=format-overflow=]
sprintf(pname, MPT_PROCFS_MPTBASEDIR "/%s/summary",
From: Arnd Bergmann
> Sent: 14 July 2017 13:07
> gcc points out a theorerical string overflow:
>
> drivers/message/fusion/mptbase.c: In function 'mpt_detach':
> drivers/message/fusion/mptbase.c:2103:17: error: '%s' directive writing up to
> 31 bytes into a region
> of size 28 [-Werror=format-over
13 matches
Mail list logo
