On Mon, Mar 26, 2018 at 2:55 PM, Matthew Wilcox wrote:
> On Mon, Mar 26, 2018 at 10:01:30PM +0200, Arnd Bergmann wrote:
>> I had suggested a more complete helper function at some point,
>> to take care of all combinations of checking/non-checking, 32/64
>> bit, microsecond/nanosecond, and zeroing/
On Mon, Mar 26, 2018 at 10:01:30PM +0200, Arnd Bergmann wrote:
> I had suggested a more complete helper function at some point,
> to take care of all combinations of checking/non-checking, 32/64
> bit, microsecond/nanosecond, and zeroing/checking the upper 32 bits
> of nanoseconds before comparing
On Fri, Jan 12, 2018 at 8:49 PM, Jeff Moyer wrote:
> Matthew Wilcox writes:
>
>> On Thu, Dec 14, 2017 at 11:18:30AM +0800, Leizhen (ThunderTown) wrote:
>>> On 2017/12/14 3:31, Matthew Wilcox wrote:
>>> > On Wed, Dec 13, 2017 at 11:27:00AM -0500, Jeff Moyer wrote:
>>> >> Matthew Wilcox writes:
>>
Matthew Wilcox writes:
> On Thu, Dec 14, 2017 at 11:18:30AM +0800, Leizhen (ThunderTown) wrote:
>> On 2017/12/14 3:31, Matthew Wilcox wrote:
>> > On Wed, Dec 13, 2017 at 11:27:00AM -0500, Jeff Moyer wrote:
>> >> Matthew Wilcox writes:
>> >>
>> >>> On Wed, Dec 13, 2017 at 09:42:52PM +0800, Zhen L
On Thu, Dec 14, 2017 at 11:18:30AM +0800, Leizhen (ThunderTown) wrote:
> On 2017/12/14 3:31, Matthew Wilcox wrote:
> > On Wed, Dec 13, 2017 at 11:27:00AM -0500, Jeff Moyer wrote:
> >> Matthew Wilcox writes:
> >>
> >>> On Wed, Dec 13, 2017 at 09:42:52PM +0800, Zhen Lei wrote:
> Below informati
On 2017/12/14 3:31, Matthew Wilcox wrote:
> On Wed, Dec 13, 2017 at 11:27:00AM -0500, Jeff Moyer wrote:
>> Matthew Wilcox writes:
>>
>>> On Wed, Dec 13, 2017 at 09:42:52PM +0800, Zhen Lei wrote:
Below information is reported by a lower kernel version, and I saw the
problem still exist
On Wed, Dec 13, 2017 at 11:27:00AM -0500, Jeff Moyer wrote:
> Matthew Wilcox writes:
>
> > On Wed, Dec 13, 2017 at 09:42:52PM +0800, Zhen Lei wrote:
> >> Below information is reported by a lower kernel version, and I saw the
> >> problem still exist in current version.
> >
> > I think you're righ
On Wed, Dec 13, 2017 at 06:11:12AM -0800, Matthew Wilcox wrote:
> On Wed, Dec 13, 2017 at 09:42:52PM +0800, Zhen Lei wrote:
> > Below information is reported by a lower kernel version, and I saw the
> > problem still exist in current version.
>
> I think you're right, but what an awful interface w
Matthew Wilcox writes:
> On Wed, Dec 13, 2017 at 09:42:52PM +0800, Zhen Lei wrote:
>> Below information is reported by a lower kernel version, and I saw the
>> problem still exist in current version.
>
> I think you're right, but what an awful interface we have here!
> The user must not only fetc
On Wed, Dec 13, 2017 at 09:42:52PM +0800, Zhen Lei wrote:
> Below information is reported by a lower kernel version, and I saw the
> problem still exist in current version.
I think you're right, but what an awful interface we have here!
The user must not only fetch it, they must validate it separa
Below information is reported by a lower kernel version, and I saw the
problem still exist in current version.
UBSAN: Undefined behaviour in include/linux/ktime.h:55:34
signed integer overflow:
-4971973988617027584 * 10 cannot be represented in type 'long int'
..
[] timespec_to_ktime i
11 matches
Mail list logo
